Conditional Requirement Strings on Wyrmsun about wyrmgus HOT 10 CLOSED

Hello @joaocaju ! Long time no see :)

The requirement strings are currently static, yes, and there is no way at present to show dynamic requirements. The engine would have to be changed.

It would be relatively simple to change the requirements string to support displaying conditions dynamically (i.e. writing what the conditions laid out in the database are), since there is already support in the engine to convert sets of conditions to a string. I don't think that would solve your problem though...

What exactly is the situation? The faction provides an upgrade, and the unit requires the upgrade? What do you want to write for the requirements string that is faction-specific?

from wyrmgus.

@joaocaju I see, thanks for the clarification! Having faction-specific requirements strings would be an improvement, but we could in principle face the same issue if the requirement exemption depended on something else (e.g. civilization or deity). So it would be better if this were more generic.

One idea is then for us to instead have conditional requirements strings. I mean something like this:

unit_dwarven_gryphon_rider += {
    conditional_requirements_strings = {
        {
            text = "Lumber Mill" #the "text" field is special, but otherwise this scope is like any other scripted condition scope, and can include any condition
            upgrade = upgrade_dummy_stronghold_exemption
        }
    }
}

If the conditions for any of the listed conditional requirements strings are fulfilled, the default requirements string is overridden.

What do you think?

Another thing is that it could be a good idea to have requirements string fields for unit classes, not just unit types, as this could help reducing the amount of code. And it also makes intuitive sense, since the conditions themselves can be in the unit class. But maybe that's out of scope for this issue 😅

from wyrmgus.

It's implemented now :)

a32ca7e
d3a148f

The only thing missing is to add an example conditional requirements string in the Wyrmsun repository. But I can't recall any existing unit type that would benefit from conditional requirements strings.

from wyrmgus.

@joaocaju Sorry for the long delay, I added a flying rider stronghold exemption dummy upgrade and its corresponding conditional requirements strings:
Andrettin/Wyrmsun@f08dbf8

About what you mentioned regarding the deities, that would have to be implemented separately (but possibly in a similar way). Maybe it would be better to remove personal deities from the game and just always apply the "global" deities instead, as the personal deities add substantial complication for (IMO) not so much gain.

from wyrmgus.

Hey @Andrettin! Yeah, was busy with work and World of Warcraft for the last months haha

In short, I would like a faction-specific requirements strings for Gryphon Riders.

Last time we spoke, you teached me how to create a "dummy" upgrade that would mimic another one. More specifically, it could satisfy the Flying Units' need for a Stronghold (leaving them to require only a Lumber Mill).

flying_rider += { #Graciously coded by Andrettin (2022)
    conditions = {
        or = {
            and = {
                or = {
                    unit_class = stronghold
                    upgrade = upgrade_dummy_stronghold_exemption 
                }
                unit_class = lumber_mill
            }
            upgrade = upgrade_mercenary_company
        }
    }
}

upgrade_faction_custom_thunderheart_clan = { #Made by João Caju (2021-2023)
	name = "Thunderheart Clan"
	effects_string = "Gryphon Riders only require a Lumber Mill to be trained and have +2 Speed and -1 Food Cost" 
	[...]
	modifier = {
		free_upgrades = {
			upgrade_dummy_stronghold_exemption 
	[...]
}

The problem is that - when playing with the Thunderheart Clan - the button to train Gryphon Riders still mentions Lumber Mill and Stronghold as requirements.

Since it is a minor detail, I was thinking about releasing the mod with a big errata and even a custom loading screen tip correcting it.

from wyrmgus.

You nailed it!

I couldn't quite put it into words, but I didn't mean for new strings to be only faction specific. A system with more conditions, as you suggested, would be much better.

It would be really elegant to have conditional strings be on the Unit Classes. Just need to make sure to add more than one conditional string when necessary, since there are civs with specific variants names for buildings.

Ex.: A dummy upgrade is added to remove the Lumber Mill requirement for Flying Riders, making them require only a Stronghold. Two new conditional strings are must be made to reflect this: one for non-dwarven civs and another for dwarves (which use "Bastion" instead of Stronghold).

But, I don't feel it is necessary to preventively add many possible conditional strings to unit classes. Just add one, because (even if it is left unused in the game) at least it serves as an example for future ideas.

Btw, it would be possible to add more than 1 Conditional Requirement. String, right?.

from wyrmgus.

I couldn't quite put it into words, but I didn't mean for new strings to be only faction specific. A system with more conditions, as you suggested, would be much better.

I'm glad you like the idea :)

It would be really elegant to have conditional strings be on the Unit Classes. Just need to make sure to add more than one conditional string when necessary, since there are civs with specific variants names for buildings.

I think a good way to go is to make the conditional strings in the unit classes be used only if there are no matching conditional requirements strings or a static requirements string for the unit type. So basically the priority order would be:
unit type conditional strings -> unit type static string -> unit class conditional strings -> unit class static string

But, I don't feel it is necessary to preventively add many possible conditional strings to unit classes. Just add one, because (even if it is left unused in the game) at least it serves as an example for future ideas.

Yes, I agree.

Btw, it would be possible to add more than 1 Conditional Requirement. String, right?.

Yes, the idea is to be able to have multiple ones. The first matching one in the list would then be used.

from wyrmgus.

I believe the Flying Riders unit class would make the best teaching example, due to the complexity of this particular scenario:

Ex.: A dummy upgrade is added to remove the Lumber Mill requirement for Flying Riders, making them require only a Stronghold. Two new conditional strings are must be made to reflect this: one for non-dwarven civs and another for dwarves (which use "Bastion" instead of Stronghold).

You could also try units with multiple tech requirements, like Siege Engines and Siege Warships.

Maybe a hypothetical seafaring faction doesn't need Engineering to sail big boats, but rather having the "Sea God" workshipped?

Just for curiosity, how exactly would the code for C.R.S look like? I am thinking on this:

unit_dwarven_gryphon_rider += {
    conditional_requirements_strings = {
        {
            text = "Lumber Mill"
                        conditions = {
                                    upgrade = upgrade_dummy_stronghold_exemption
                                            }
            text = "Cool GOBLIN Lumber Mill"
                        conditions = {
                                    and = {
                                                upgrade = upgrade_dummy_stronghold_exemption
                                                civilization = goblin
                                            }
                                                        }
                                                                    }
                                                                                } [...]```

from wyrmgus.

I was thinking, can these C.R.S affect how the Deities' thumbnails are previewed to the player, based on the unit that is currently selected?

For instance, when you try to select a deity to workship as a Axefighter, the thumbnail will needlessly mention what effects that god would have on other unrelated units (such as casters etc.).

That wouldn't be a problem when you are "globally" workshipping a deity at a Temple, but on an individual character that information is confusing because the Axefighter will never be able to transform into a caster, for instance.

from wyrmgus.

NP @Andrettin, take your time!

I believe the build with the changes isn't up yet, right? I just released On Thunderous Wings with the dummy upgrade, but will remove that line once it enters the base game.

About the deities thingy, it can be discussed later, but there is a cool flair for characters having their personal worships.

from wyrmgus.