Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes

No

[Avelon]

Feel free to add small modding-related ideas to this thread.

Original concept:

Spoiler (click to show/hide)

1.) Customized tokens. custom_token.txt is created in the raw/objects folder.

Code: [Select]

custom_token

[OBJECT:CUSTOM_TOKEN]

[TOKEN:TOADY] this is an example of a custom token
[TYPE:ITEM] arguments are: ITEM ENTITY MATERIAL PLANT CREATURE BODY

Tokens defined in this file can be added to any of the things that correspond to the argument used in their type. Each token must be unique in name.

Can be used in reactions in 2 ways:

As a reagent, two modifiers exist: HAS_TOKEN and NOT_TOKEN

For instance:

Code: [Select]

[REACTION:SMELT_METAL_ITEM_AVE]
[NAME:Melt metal item]
[REAGENT:A:1:NONE:NONE:NONE:NONE][REACTION_CLASS:METAL][NOT_TOKEN:INGOT]
[REAGENT:D:1:TOOL:ITEM_TOOL_SMELTER_AVE:NONE:NONE][PRESERVE_REAGENT]
[PRODUCT:100:1:TOOL:ITEM_TOOL_INGOT_AVE:GET_MATERIAL_FROM_REAGENT:A:NONE]
[PRODUCT:100:1:TOOL:ITEM_TOOL_INGOT_AVE:GET_MATERIAL_FROM_REAGENT:A:NONE]
[SKILL:SMELT]
[ADVENTURE_MODE_ENABLED]
This takes any metal item and converts it into a (metal type) ingot, which will have the TOKEN:INGOT token included in its definition, so the reaction WILL NOT accept the ingot itself. If it did, then you would be duplicating the ingot endlessly.

In a broader sense, what this would do is allow modders to group items together. As more options become available to players, these custom tokens would ease some areas of implementation on the design side as well as allowing user content to define tool knives and daggers as being in the same category, lets a player modify building reactions so dwarves will use certain groups of items, etc.

Tokens could even be used for civilization factioning (a separate implementation/idea in and of itself that I won't get into too deeply) by defining tendencies with tokens that would make some civilizations more prone to treating others in a particular way. In a basic sense, civilizations that share tokens will have more tolerance for one another. If a feature like this were to be implemented it would be a simple enough matter to add another definition to tokens such as alignment that you can optionally define under the token.

Refined concept:

1.) Simply put, the addition of ITEM_REACTION_CLASS with companion modifiers HAS_ITEM_CLASS and HAS_NOT_ITEM_CLASS.

[ITEM_REACTION_CLASS:X] is added to any object of type item (everything you can put into your inventory) and can be defined as anything. In reactions, the two modifiers can be used to include or disallow items sharing a reaction class. As an example:

Code: [Select]

[REACTION:SMELT_METAL_ITEM_AVE]
[NAME:Melt metal item]
[REAGENT:A:1:NONE:NONE:NONE:NONE][REACTION_CLASS:METAL][HAS_NOT_ITEM_CLASS:INGOT]
[REAGENT:D:1:TOOL:ITEM_TOOL_SMELTER_AVE:NONE:NONE][PRESERVE_REAGENT]
[PRODUCT:100:1:TOOL:ITEM_TOOL_INGOT_AVE:GET_MATERIAL_FROM_REAGENT:A:NONE]
[PRODUCT:100:1:TOOL:ITEM_TOOL_INGOT_AVE:GET_MATERIAL_FROM_REAGENT:A:NONE]
[SKILL:SMELT]
[ADVENTURE_MODE_ENABLED]

The item entry:
[ITEM_TOOL:ITEM_TOOL_INGOT_AVE]
[NAME:ingot:ingots]
[VALUE:10]
[SIZE:200]
[TILE:'=']
[MATERIAL_SIZE:1]
[HARD_MAT]
[ITEM_REACTION_CLASS:INGOT]
This reaction will not show ingots in the crafting menu when melting down metal items although they ARE metal items. This allows 1 reaction to do what normally would take 13 (12 if you don't include the item type that INGOT belongs to, in this case tools) reactions.

------------------

2.) Expand 'DIMENSION' to encompass all items, taking over SIZE/WEIGHT where applicable (these could be analogous terms as they already are for one another). Reactions can interact with DIMENSION but not SIZE/WEIGHT as things currently are. Going again by the above example of my own script (yes I have an ulterior motive here), were it possible to endow, say, tools with DIMENSION:50 or something, that script could then demand a reagent have MIN_DIMENSION:100 and disallow the ingot from melting into 2 of itself that way.

------------------

3.) Variable output for PRODUCTs: MATERIAL_SIZE of reagent or DIMENSION (if above is implemented) can affect PRODUCTs like so:

Code: [Select]

[PRODUCT:100:1:TOOL:ITEM_TOOL_INGOT_AVE:INORGANIC:STEEL][INPUT_REAGENT_SIZE:A:50]INPUT_MAT_SIZE means that for each time REAGENT:A matches the input size of '50' it produces 1. So if you use, say, a war hammer (SIZE of 400), you would get 8 steel ingots. Or if you use material size (3), the output could look like this:

Code: [Select]

[PRODUCT:100:1:TOOL:ITEM_TOOL_INGOT_AVE:INORGANIC:STEEL][USE_MATERIAL_SIZE:1]That is, use material size / 1, in this case giving you 3. USE_MATERIAL_SIZE:2 would give you just 1, but if you were using a Battle Axe (MS 4), USE_MATERIAL_SIZE:2 would give you 2.

[Putnam]

Tokens already refer to all of the whosits in the raws, so it should have a better name.

Maybe something like an [ITEM_REACTION_CLASS:X], to keep it consistent.

[Avelon]

ITEM_REACTION_CLASS would be specific to objects of 'item' types and thus not eligible for entities or creatures - rather, Toady can name it FARGLEBYTES_PIECE_OF_EIGHT if he wants to but it would be confusing to have ITEM_REACTION_CLASS:HUMANOID in your entities file, for instance.

How about 'grouping' or 'class'? We have 'castes', but grouping is self-explanatory and 'class' is universal in object definitions.

Also added 2 more related minor suggestions, would you be so kind as to give feedback on those also?

EDIT: And I realize ITEM_REACTION_CLASS has class right in it but I mean more like 'CUSTOM_CLASS'. GROUPING could run solo.

[Putnam]

Not sure why you would put entities in this? Since we already have reaction classes for reactions, creature classes for creatures and syndrome classes for syndromes, it stands to reason that we would have item (reaction) classes for items etc.

[Avelon]

Those could be assimilated into the wider grouping to make the RAW files more modular I guess, but CREATURE_CLASS isn't the same thing as the proposed 'freeform custom tag you can put on anything', particularly since it's only used for GENERAL_POISON.

To be honest, as it stands, there is no REASON to add the entity, creature, or syndrome arguments, as there is nothing that can be done with them via reactions anyway (that I know of?). But the classes you mentioned don't do what this would do, and adding them now as opposed to later would make future developments in that direction easier.

I guess item_reaction_class would work for a current implementation since reactions can't react with the environment other than using things on the same tile. Maybe when we can cut trees down and dig.

I do still like the idea of having groupings for anything that you can define with more universality however.

[Putnam]

 

Those could be assimilated into the wider grouping to make the RAW files more modular I guess, but CREATURE_CLASS isn't the same thing as the proposed 'freeform custom tag you can put on anything', particularly since it's only used for GENERAL_POISON.

Yes it is. You can define anything under CREATURE_CLASS and use that in syndromes. For example, in my DBZ mod, I have [CREATURE_CLASS:NATURAL_KI], which disallows saiyans, namekians and frieza goons from learning anything from the turtle or crane schools.

[Avelon]

In that case I stand corrected. There isn't anything like that for entities though, is there? Eventually world gen will be sophisticated enough that such a thing might come in handy - and it certainly will through the coming stages before it gains the level of sophistication that would render such a tag obsolete.

The main core of the idea though, that it should be available for items, remains. I'll update the first post to reflect your input - thanks!

[WillowLuman]

Also, probably change tokens to classes in thread title.

[Putnam]

I'd say that an arbitrary class for entities would be useful for, say, ALWAYS_WAR:(class) or something like that.

[Avelon]

Done and done, and yes! That's exactly what I was thinking for entity classes.

ALWAYS_WAR:X
ALWAYS_PEACE:X
COEXIST:X (shares settlements and considers one another to be the same civ when deciding where to go while moving to another town or searching for a mate; this already happens sometimes as I have had a Draconian city with dwarves, humans, goblins, and draconians coexisting)

And such.