I noticed that the material component allows for a tags_modified field that is used to prevent changed modified tags from being reset:
function MaterialComponent:restore() if self._sv.tags_modified then self:set_tag_string(self._sv.tags_string) else self:_read_tags_from_json() end end
One issue I noticed was that on initialization, tags_modified is not checked for when the json is read: function MaterialComponent:_read_tags_from_json() local json = radiant.entities.get_json(self) local tags = json and json.tags or '' self:set_tag_string(tags) end
It’d be useful to check for tags_modified = true on intialization because a mod might have modified the tags through a “mixinto.” Currently, if a mod does so, the tags will be reset back to the unmodded tags on reload. Do you think this could be added into the next release (its a quick fix)? I’m currently overriding the material_component.lua to achieve this but I’ve been told to avoid overriding.
Hi,
Tags modified is for material tag syncing between iconic and root entities.
Are you sure the bug you mentioned is actually happening? If a mod modifies the tags, the reload will read in the json, which is still modified by your mod’s mixinto, so the reloaded tags should be correct. What is the use case you are trying to do that is causing a bug?
It must be because the mixinto was is in a deferred_load mod, which is what I use to only load gameplay elements is the player is playing as my modded race.
Hi,
Deferred load is not meant for loading server side mods. It is meant for UI modifications, which is purely Client side. What in particular are you trying to do with the deferred load that cannot always be loaded?
Thanks
-Yang
My modded race, bastioneers, are much shorter than the ascendancy so all the armor and helmet qb’s need to be modified. If I put the override in a separate, deffered_load mod, then I can check if they’re playing as bastioneers and only then override the armors and helmets. I also do this for resource elements, where I modify the tags.
Hi,
For shorter armor, what you need to do is create a new model_variant for your bastioneers. Right now, the way females work is they have a specification in their render info component that says their model variant is female
"components": {
“render_info” : {
“animation_table” : “stonehearth:skeletons:humanoid:female”,
“model_variant”: “female”,
You could make a new model variant that is “male_short” and “female_short” and then mixin-to all the equipment the male_short and female_short versions. Using a deferred load on the models is incorrect because that will change ALL models, which is not what you would want for multiplayer. It should be completely valid for another player to play ascendancy along side the bastioneers, and a deferred load on the server would mean that all equipment will become the short version for all players.
Also, for resource elements, why do you need to have the tags only modified when the active player is playing bastioneers? What resources are you modifying and why can they not always be modified?
Thanks
-Yang
I see how the model variant works, I’ll look into it
As for the resources, I have unique job for my race that refines raw materials (hunks of stone and wood logs, etc.) into refined materials, and then all normal recipes now require the refined resources. To achieve this, I change the material tag for, say, hunk of stone to be “raw_stone resource” instead of “stone resource” and then my refined resource has “stone resource” tag so all recipes now require the refined material without having to override each recipe. This is a gameplay element that I really don’t want to have if the player chooses a different race, but again, I couldn’t figure a better way.
@Wharp,
I think the correct way to do this would be to override all recipes for your specific faction to take a “refined_stone resource” instead of regular stone resource. Again, deferred load would not be the correct thing to do because it would change the material tags on hunks of stone for all players. In multiplayer, if another player is playing ascendancy, and then all stone suddenly became “raw_stone resource” because a bastioneer was player, the ascendancy player would then not be able to craft anything.
Hope this makes sense.
Thanks
-Yang
I see. But one issue I have with the recipe override is that then my mod won’t play nice with, say, settlement decor mod. Could I maybe write an observer that would check each time a resource is generated and modify the tags if the owner is bastioneers race (and watch for change of owners of course) ? Or would that be non-performant?
