FreeOrion

I'm starting to really want the ability to #include other text files in a text file so we can have a single text file for stuff like [[NON_ORGANIC]], [[ILL_CONDITIONED_SURFACE]], [[UNMANNED]] for ships, [[LOW_STEALTH]], etc. for functionally discretized levels of stealth, [[ORBITAL]] for buildings, etc. Alternatively, or perhaps additionally, it would be nice to just be able to put 'tags = "ILL_CONDITIONED_SURFACE"' in any arbitrary item's description, which would add the tag to itself, or in the case of specials/species and ship parts/hulls, to its planet or ship, in which case the condition HasTag tag = "ILL_CONDITIONED_SURFACE" would match such objects.

On the other hand, something very similar could be done with highly stealthy (or not stealthy?) specials, though that would require additional maintenance, since the conditions for the special removing itself would need to be continuously updated.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

The ability to include one text script file in another is useful independent of whether there is a mechanism for assigning a tag special to objects, isn't it?

I was pondering a tagging mechanism yesterday, but was unsure how it should work in terms of tags being added to objects (ships, buildings, planets, systems, fleets) or rather added to parts and hulls and transferred to the objects, or whether techs would have some sort of tag as well, and whether species or specials would have tags and if those would transfer to planets or other objects. Should there be an effect for adding a tag, or should tags only be present if written into a script file for a particular bit of content?

You also mention that specials could be used to achieve a similar result, but that there would be some complications. Could you elaborate on what you mean by the maintenance that specials would require?

Well, yeah, I suppose this thread is sort of a mush of two independent topics, but which are useful in similar ways.

If there's an effect for adding a tag then presumably there needs to be an effect for removing the tag as well, in which case it doesn't seem to be functionally very different from using specials. I think tags should probably be solely written into particular bits of content, rather than any arbitrary object being able to attach a tag to any other arbitrary object via effects, and also makes more sense with what the tag is supposed to represent, which is a particular feature of the object that's independent of its environment.

It might be useful for techs to have tags which then transfer to every object owned by the empire - for instance, a tech that makes all the empire's objects non-organic, or telepathic, or something like that, though I feel like that contradicts what I just said to some degree...

For example, if there were a "NON_ORGANIC_SPECIAL" that was applied to ships and planets crewed/inhabited by a particular species, then that special would need to be removed whenever the species was removed from the planet. This requires all the conditions for the special to be removed to be in the description of the special, so whenever you add another non-organic species, you have to go edit the activation condition for that special's self-removal effect. In contrast, if the tag is automatically applied to planets inhabited by the species, there's no need to edit anything outside of the species description when adding a new species, or changing an existing species.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

The core thing from my perspective is that a tag allows any arbitrary bit of continent to include itself into a group. Then you can write effects to include/exclude all TELEPATHIC aliens, or BEAM_WEAPONS, without having worrying about updating all the lists when you make new content.

For the question of weather tags should be transferred-- this goes into the territory of stuff i have trouble with-- if you wanted to test to see if a planet had a telepathic alien, wouldn't you leave the tag in the alien and then script:

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

I tried putting
at the start of techs.txt, with the contents of shared_macros.txt being


I got the errors

_________________
Warning: Antarans in dimensional portal are closer than they appear.

I committed some changes to those text files based on what you posted, and things seem to be working as intended for me.

Conditions match objects, which are ships, planets, buildings, fleets, and systems. There's no "Telepathic" condition, and no possible way to make a condition-like means to specify a list of species, so that bit of script doesn't really make sense.

What could be done is to add a HasTag name = "TAG_NAME" condition, which would match any object that has the indicated tag assigned to it.

The question remains: how to assign tags to objects?

It would be relatively easy to set things up so that any bit of content that has a tag defined transfers that tag to an object:
* A building type would have a tags list, and any building of that type would have those tags.
* Species would have tags, and any planet or ship with a species would get the species' tags.
* Ship parts and hulls would have tags, and ships whose design includes a part or a hull would get their tags.
* Specials could have tags, which would be assigned to any object the special is attached to. This would be slightly more complicated than the above cases.
* Techs would not have tags, as there's no reasonable object to assign them to.

*sigh* ...never mind. You'd think I would have remembered to build the solution after updating, considering I spent a good portion of the day making changes to the actual code.

If that's the case, could you add some comments indicating the way in which they're sorted? I spent a few hours today trying to figure out why Farming wasn't being reset every turn, only to find that it was because I had put it somewhere in between METER_POPULATION and METER_TROOPS. I'm guessing now that it goes Target/Max, Active Paired, then Unpaired, is that right?


This sounds fine to me.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

That is the order, but that's not why a meter would not have been reset each turn. The ordering in the enum declaration is just to keep things organized. How the meter values change including whether they are reset each turn has nothing to do with where it is listed, but rather is a result of it being explicitly reset somewhere. In the case of farming, it's presently reset in ResourceCenter::ResourceCenterPopGrowthProductionResearchPhase.

That's not all - I'm not 100% sure that this is the offending code in question, but the code for UniverseObject::ResetPairedActiveMeters() is as follows:


I presume that somewhere along the line, m_initial_value, which is returned by meter->Initial(), gets changed to the current value of the meter, which keeps paired active meters from being set to 0 when this function is called. This would mean that the value of any meters listed between METER_POPULATION and METER_TROOPS would be returned to their current values, regardless of whether or not they were reset elsewhere in the code earlier on.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

Ah, yep; you're right. I elected to loop through the series instead of writing them all out explicitly; I guess there is more rationale for the ordering than being organized.
I think you're looking for UniverseObject::BackPropegateMeters which calls. That function is what marks the transition between turns for meter values; storing the updated value after applying effects as the new initial value at the start of the current turn. (Although I think it's actually called a few times during turn processing in order for things to work properly in various cases...)

Looks like Geoff is giving us both tags and included macros. Tags sound easier to me. Is there a use case where includes are better?

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

While includes can be used for a lot of the same things tags can be used for, I'd be more likely to use them for stuff like constants that are meant to be common throughout all the text files, like the stealth stuff I put in there - uses for which tags aren't really applicable. I can't really think of a reason to use macros instead of tags in any instance where tags would work.

Edit: By the way, can specials have tags as well?

_________________
Warning: Antarans in dimensional portal are closer than they appear.

Not at present. Could be done, but it's a bit annoying to do so.