The way `SHARED_OBJECT_KILL_TAG` and `SHARED_OBJECT_REPLACE_TAG` match tags are now much more flexible and works exactly as intended. Thanks Milo!
...@IF and !SHARED_OBJECT_DUPLICATE, both performed flawlessly...
!SHARED_OBJECT_DUPLICATE duplicate the code as intended but then it is imposible to use SHARED_OBJECT_REPLACE_TAG or any other over the duplicated object, the reason is that DUPLICATE uses
return "{_INSERT_SHARED_OBJECT;"..nid.."}"
That is what were used before the introduction of hygiene to evite the clash of identifiers of objects, instead of
{!SHARED_OBJECT_CATEGORY;"..v..":%{id};"..v.."}
Or any of its specializations. The duplicated object is even inserted into the rubble registry, but it can not be found because it has been inserted in a place of the hierarchy that does not correspond to the kind (creature, plant, material, ...) of the object.
This can be seen when running this code (working)
[OBJECT:PLANT]
{!SHARED_PLANT;MUSHROOM_HELMET_PLUMP_SPROUTING;
[NAME:plump helmet][NAME_PLURAL:plump helmets][ADJ:plump helmet]
Every plant needs a structural material so that the game knows how it behaves when it's alive.
Here the material is added to the plant, using a template from the material file.
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[MATERIAL_REACTION_PRODUCT:DRINK_MAT:LOCAL_PLANT_MAT:DRINK]
[MATERIAL_REACTION_PRODUCT:SEED_MAT:LOCAL_PLANT_MAT:SEED]
Here the material is marked as the structural material (this could be below the edible tags which come next). In general, you can use LOCAL_PLANT_MAT|<token>, PLANT_MAT|<plant>|<token>, CREATURE_MAT|<creature>|<token> or INORGANIC|IRON (though the game might hiccup for a while specifically on plants that aren't structurally plants).
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]
We also modify it a bit to make the plant edible. Any token material can be used here to modify the material that was created from the template.
[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[USE_MATERIAL_TEMPLATE:MUSHROOM:MUSHROOM_TEMPLATE]
[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PICKED_TILE:6][PICKED_COLOR:5:0:0]
[GROWDUR:300][VALUE:2]
Next we establish an alcohol material in much the same way as the structural material.
[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
The material template is just called "alcohol" so we need to give it a proper name.
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
We also set a few more numbers to distinguish the alcohol from the template.
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]
The seed material and information is established in a similar fashion. Other plants (including trees) add materials in the same way, though trees cannot be used at this time with seeds/thread/drink etc. They just use the TREE tag to obtain a wood material (they also have a structural material for their live form).
[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]
[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:58]
[DEAD_SHRUB_TILE:58]
[SHRUB_COLOR:5:0:0]
[DEAD_SHRUB_COLOR:0:0:1]
}
{SHARED_OBJECT_ADD;PLANT:MUSHROOM_HELMET_PLUMP_SPROUTING;[ALL_NAMES:plump helmet sproutings]}
{SHARED_OBJECT_REPLACE_TAG;PLANT:MUSHROOM_HELMET_PLUMP_SPROUTING;SEED;[SEED:plump helmet sproutings spawn:plump helmet sproutings spawn:4:0:1:LOCAL_PLANT_MAT:SEED]}
{SHARED_OBJECT_REPLACE_TAG;PLANT:MUSHROOM_HELMET_PLUMP_SPROUTING;GROWDUR;[GROWDUR:60]} divide by 5 # divide by 5, good for exp
{SHARED_OBJECT_REPLACE_TAG;PLANT:MUSHROOM_HELMET_PLUMP_SPROUTING;CLUSTERSIZE;[CLUSTERSIZE:1]} divide by 5, yearly output more or less maintained, except for the seeds
and comparing with (half-working)
[OBJECT:PLANT]
{!SHARED_OBJECT_DUPLICATE;PLANT:MUSHROOM_HELMET_PLUMP;MUSHROOM_HELMET_PLUMP_INTENSIVE;false}
{SHARED_OBJECT_REPLACE_TAG;PLANT:MUSHROOM_HELMET_PLUMP_INTENSIVE;GROWDUR;[GROWDUR:3900]} # multiply by 13, good for FPS (bigger stacks)
{SHARED_OBJECT_REPLACE_TAG;PLANT:MUSHROOM_HELMET_PLUMP_INTENSIVE;CLUSTERSIZE;[CLUSTERSIZE:65]} # m
{SHARED_OBJECT_ADD;PLANT:MUSHROOM_HELMET_PLUMP_INTENSIVE;[ALL_NAMES:plump helmet intensive]}
{SHARED_OBJECT_REPLACE_TAG;PLANT:MUSHROOM_HELMET_PLUMP_SPROUTING;SEED;[SEED:plump helmet intensive spawn:plump helmet intensive spawn:4:0:1:LOCAL_PLANT_MAT:SEED]}
That says that it does not find the just duplicated plant where all others are placed.
I can see how dealing with a function (DUPLICATE) that must have the capacity to register
all possible types of SHARED_OBJECT is complicated and error prone (I know, I have tried and the result is not good to look upon...
![Huh ???](http://www.bay12forums.com/smf/Smileys/aaron/huh.gif)
)
So my proposal is: what if DUPLICATE simply returns the PRERAWS(id) of the object
except the first token (the token id) and then we use the SHARED_object that is correct for his kind?
An example of duplicating a plump helmet with this method.
{!SHARED_PLANT;PLANT:MUSHROOM_HELMET_PLUMP_SPROUTING;{!SHARED_OBJECT_DUPLICATE;PLANT:MUSHROOM_HELMET_PLUMP}}
The internal coding is more simple, the object is correctly registered and we can also use DUPLICATE in any place (flexibility of prototypes) where some PRERAWS are expected (there are a lot)
Opinions?