Redoing Item Definition Handling in flat files

Game Talk The Drawing Board
1

This will probably end up in mods sooner or later, but I would like to get some feedback.

I’m strongly considering jumping back in and redoing the item handling system. I think, right now, it’s rather messy, and getting it working properly for some things can be a bit of a chore.

So what I’d like to do is something along these lines:
Switch to an external text-file - a proper config file, basically
Switch to a tag-based handling system - so order doesn’t matter so much and we don’t need to worry about the stuff we aren’t using
Tieing the spawn conditions to the item itself - This is probably the bit I’ll need some help figuring out. It could be as simple as adding tags for spawngroups, and then its automatically placed wherever that spawngroup is placed. [SPAWN: Domestic:120][SPAWN: Appliance:200][Spawn: Carried:2] and the definitions for those groups are defined as they are now (The second number would be the frequency for that spawn type).

For an example, take this generic GUN

[ITEM:
[NAME: GlyphGryph Brand Gun] #Name field, mandatory
[UNIQID: GGGUN] #UNIQID field, optional, used for code hooks or references from other items
[IS: Gun] #Treated as a gun, which means others will see it as a deadly weapon
[IS: Metal] #Treated as a metal object, so doesn’t erupt into flame with the touch of a lighter
[ACTION: Fire:Shoot] #Add commands/actions to this gun. Some items can have more than one action type.
[SHOOTDAMAGE: 4:10]
[SHOOTTYPE: Semiauto: 9MM]
[SHOOTRECOIL: 5]
[AMMO: 9MM:21]
[VOLUME: 5]
[WEIGHT: 20]
[ACTION: Use:SwitchMode(2)] #When the item is used, it runs the code for the SwitchMode event with a specific target.
[MODE2: ACTION: Fire:Shoot] #If you don’t have a SwitchMode action, this won’t do much, but you don’t have to define it with use.
[MODE2: SHOOTDAMAGE: 8]
[MODE2: SHOOTTYPE: Launch: RPG]
[MODE2: SHOOTRECOIL: 10]
[AMMO: RPG:1] #Ammo can be used across modes and reloaded from any mode, so shouldn’t be mode-specific.

[MODE2: ACTION: Use:SwitchMode(1)] #Sends us back to mode 1 when used.
]

Note that in the actual implementation, there would probably be a [MODES: #] tag, and you’d only have to define one [ACTION: Use:SwitchMode], since it would automatically cycle through the modes (hypothetically). Tags are only overwritten for a specific mode IF you have an action of that type defined for that mode, meaning disabling a behaviour would be done with [MODE2: ACTION: use:NONE] or by making the original behaviour mode specific. You can also have multiple actions tied to a command, so [MODE2: ACTION: Fire:Shoot:SwitchMode(1)] would be possible, if you want it to switch automatically back to bullet mode after firing grenades.

What are the commands we can tie to items right now?
Eat
Drink
Fire
Use
???

2

For implementing this, are you planning on making a config file handler that will recreate the item structures as they exist now, or are you planning on overhauling how items are defined as well as implementing a config file handler? It’s um, painful to do both at the same time.

The way the modes are handled now, it cycles through them in a fixed order, and a given item has a flag set for each supported mode.

3

Honestly, this is part and parcel of the fact that I kind of redo the way items are handled almost from scratch.

So yeah, I kind of want to do both at the same time, but this would be the “front facing” component that people see, and thus the part they are most likely to have an opinion on… or at least that was my thinking.

I was basically replacing all the code-based items with data-based items - everything item is just a generic “item” object, with data reflecting the definitions in these config files. (With the exception of the spawn information, which will probably be added to the spawn areas data pile)

Maybe it’s a stupid idea, but I feel like it would be an improvement over the system we have now, if only organizationally - being able to split items into separate files, easily moving chunks of items in and out of the game without worrying about conflicts, easy defining of items for a layman. I feel like there’s at least a few benefits.

4

The item class definitions could definitely be improved on, and defining the items themselves in config files instead of in code is a clear win too. The only thing I’m worried about is a MASSIVE amount of code churn from refactoring all the code that interacts with items. Anything this big would definitely qualify as a full-fledged fork, it’d probably be impossible* to merge anything back and forth with the original cataclysm codebase.

*more like “prohibitively difficult”, but the point is, it basically wouldn’t happen.

5

I’m not too worried about most of that. There’s never going to really be anything merged back into the original codebase, and we need to be willing to make changes like this to make real progress.

I’m mostly worried about the fact that I spent some time on it today, and it’s a bit beyond me at the moment. I’ll keep hammering away at it until I figure out a decent solution, though.

6

I’m all for it, but as Kevin has already mentioned, there’s an insane amount of item interaction code scattered all over. However some item subsets could be pulled out as their usage is pretty generic, eg clothing, guns (maybe), books.

There are some other places which would similarly benefit from config files:

  • crafting recipes
  • construction recipes
  • terrain types
7

Sounds like a tough task, but also a needed reworking.
Hard-coding items (and most anything else) before a ‘final release’ (if there’s ever such a thing) makes development a lot harder and slower than needed, with no real benefit in an open-source environment.
Hope it goes smoothly for you, and that steam doesn’t run out.

8

[quote=“DinoCat, post:6, topic:50”]There are some other places which would similarly benefit from config files:

  • crafting recipes[/quote]

I’m actually strongly considering just making crafting based on the item flat files. Those with the “craftable” tag and enough info would have an entry stuck into the crafting menu, basically.

It feels more appropriate for crafting and spawn details to be associated with the items definition (at least in the flat file, if not in the code) than the way it exists now… but maybe that’s not the best way to do it.

9

The main reason I can think of to not tie crafting recipes to items is so crafting recipes could have multiple outputs, so for example you could make dissasembly recipes in addition to assembly recipes. (I haven’t looked into how DinoCat’s dissasembly code works yet)

It’d be nice to push that kind of declarative stuff out into config files as well.

10

It’s all in crafting.cpp, merged into main line. Also, get into IRC, I must discuss things with you.

11

While I’m redoing item handling, I could always just include default component definitions and have items track the things they were crafted out of. After everything else, that would be fairly trivial, and “recipes” wouldn’t be needed to disassemble stuff.

12

I’ve started down this path with how skills are handled, you can look into my git repo, on the loadable-skills branch.