Yup, I noticed that (button font) as well and already have it on my list for things to do tonight.
While I'm waiting for Shadowrun Returns to load from Steam, here's a harebrained idea (geddit, heh) for you guys to ponder. Just throwing this up in the air (fly, my little one, fly!!), inviting discussion.
The advantage of this would be that the module author could now customize the amount of "equipment slots" his module would use and it wouldn't show empty, unused slots or spaces for them on the inventory screen AND you could have more than the current max. of 8 slots (it's just a list, scrollable one, no UI limitations, etc.). For example, a sci-fi CRPG could only need 2-4 slots while an item-heavy fantasy CRPG could easily use 12 or more. This list of equipped items could show (e.g. in parenthesis after the item) where the item is equipped, but in most cases the location is self-explanatory, so I'm not sure if that would be needed (boots are worn in feet, helmets on head, etc., not much variation in that). The "hidden slots" could be internally numbered and the list would show them in numerical order. So, if I e.g. put slot 1 as torso, slot 2 as main hand and so on all the way to slot 16 as toe ring, the Equipped Items list would show torso item first, main hand item second, and at the end of the list the toe ring. This way the list will retain some organization, what the MM3 list does not (the items appear in the order they are picked up). This system would have two similarly behaving item lists side by side in the Inventory window, one for carried items and other for equipped items, but without overt (and limited to 8) item slots.
Hehe, should start some download for Shadow Run tonight, too.
I am open for different item listings actually. Imho the list should somehow show which locations are already used and therewith witch item will likely be exchanged for a new item. So option 2 seems more favorable to me. I actually also like the "empty slots" shown as those encourage me to go looking for extra items to fill those opportunity placeholders. Also I would quickly understand this way whether my char can equip one, two or four rings at the same time. But I agree that ideally name AND number of slots used for a module would ideally freely definable. So, keep them toe rings as 16th item class coming, I am all for having the flexibility to adjust.
Doing this is not trivial, I fear though, as several parts of the program codes/scripts will of course read out the equipped items and their effects. Trouble will start if scripts/code assume that e.g. only torso armor is able to influence AC. Such assumptions would have to be avoided, theoretically allowing every equipped item to influence every original and derived statistical value.
I'm open to any of the layouts suggested. Coding wise, this could be a challenge, but hey, we usually figure something out code wise to make it work May have to stick with the current system for this Alpha build, but it is something to start thinking about before we go to Beta build. It could be a significant change in the way the system works and we should figure it out before authors get too far along into production and scripting.
Disclaimer: I got less than 5 hours of sleep last night (was up playing Shadowrun Returns until about 1 at night and had to get up around half past 6 in the morning -- Tired as heck now. I'm too old for this...), so I might be even more incoherent than usual. Apologies in advance.
On a purely theoretical note, I would hope the engine code would not assume too much, I mean that, there ought not be inherent assumptions on what each equipment slot does or represents as those can change wildly from module to module. For instance, I might make a module where the PC is a sentient spaceship, which does not even have a torso slot. Instead the equipment slots would represent major pieces of equipment installed in the ship and the ship could e.g. have two shield generators to provide AC (in two separate equipment slots), or something like that. What I'm trying to say, is that in order for the IB engine to be easily customizable to different genres and styles of CRPGs, I can't see how there could be any inherent assumptions on what the equipment slots represent. Allowing every equipped item to influence AC, attributes, and whatnot is (IMHO) crucial for the engine, not just for the basis of having e.g. a variety of stat increasing/decreasing items (not just rings, but all kinds of items, like a Helmet of Might increasing STR, etc.), but also for the engine to be easily usable in wide variety of different genres, which I understand is one of the major principles (and strenghts) of IB.
I fully agree that every item on every slot should be able to do anything. It should be properties (switch to on/off/set to a certain value) on the specifc item, not the item type itself, that decide wether that specific item influences a statistical value. So every item type has the potential to influence anything, like one belt that gives an AC bonus, anaother belt does not, or a ring that adds d6 to damage. It's most likely clean up work that needs to be done (in combat code, in determing derived stats, in script and scripfunctions.dll) and perhaps an adjusment to the item class - but only Jer will truely know what's involved to set such a flexible solution up). Perhaps there is just one single item type for all itmes actually and one of its properties is slotposition, expressed by a simple number? Two handed weapons would e.g. take two slots then, so items generally should be configurable to blcok sevral slot positions.
I wonder how to handle weapons specifically in such a setup. Most simply it will propably be author's responsibibly to have all weapons go inot the same slot (or two slots for off-hand rules). The code will then look for itmes in all slots and take the the one time that has isMeleeWeopaon or isRangedWeapon set to true). Slots in such a system will have no functionality info - it's the item that has all functionality information.
The only feature I would like to keep is some info (name of slot, item in it) visible on the inventory screen about the (empty and already filled) slots available for the character/spaceship/allied Umgak (names and ideally number of the slots could be changed by the module author). As already said this would imho help to get a quick overview about what items could still be used for that char and would e.g. make sense to buy.
Yeah, it's good. Not perfect, but no game is. It is a shining example on how to use dialogue and descriptive text in a CRPG. SR does this magnificiently well, I cannot praise the writing enough, the mood it sets is amazing. The graphics and music are also really good (I like the art style a lot, but some seem to dislike it). Too bad that the game seems to be pretty linear with very little exploration. I was sort of expecting this, though, so I'm not too miffed about it. The biggest flaw, by far, is the dismal autosave system the game has. You cannot save manually and the game only seems to save when you enter an area. Not after a battle, not after completing a quest, not, and this is the stinker, not when you quit. I had to keep on playing for c. 10-15 minutes longer than I wanted yesterday, because I had to reach a new area in order to save my progress. That's just lousy.
As to the inventory revision, I got the impression from Jer that what I proposed would require considerable rewriting of the code and that's really not what I'd want to impose on him. As some form of middle ground in this, maybe increasing the number of equipment slots from 8 to 12 would be enough. Nothing actually changing code-wise, just adding a few more slots (if needed). I don't know if anyone else is really looking for more equipment slots at all, so if this is just me, forget the whole thing. I was just going through my plans for my fantasy module and noticed I ran out of equipment slots when listing equippable gear. Boo-hoo, yeah, I know - deal with it, eh. Yes, I can live with 8 slots, easy. So, this can be chalked up as yet another incoherent rambling post by Yours Truly.
@ Grue: That savegame system of Shadowrun sounds indeed very unfortunate. Also exploration is something I like a lot. But I still hope I will like the game (in any case it will be good for getting inspiring ideas for IB, hehe ).
Back to IB, but again savegames : What keeps me worrying a little right now is the size of savegames for RedCarnival. They are at 30 MB right now (Lanterna is only at 3 MB). If this scales in a linear way to campaign size we talk 300 MB or even 1 GB savegames here later on. Any options to somehow place less data into the savegames themselves (while maintaining the flexibility to gradually update a running campaign with new areas, encounters, classes, feats, etc.)?
Hmmm...well need to closely look at the save gave data and see who the big abusers are (referring to saved objects/classes). I'd like to stay away from binary data files (they are smaller) just to keep things open and transparent.