-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditional Requirement Strings on Wyrmsun #191
Comments
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? |
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).
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. |
@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:
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 😅 |
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.
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?. |
I'm glad you like the idea :)
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:
Yes, I agree.
Yes, the idea is to be able to have multiple ones. The first matching one in the list would then be used. |
I believe the Flying Riders unit class would make the best teaching example, due to the complexity of this particular scenario:
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:
|
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. |
@joaocaju Sorry for the long delay, I added a flying rider stronghold exemption dummy upgrade and its corresponding conditional requirements strings: 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. |
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. |
Faction bonuses can be coded to give certain upgrades, that otherwise would need to be researched or achieved some other way.
Due to this interaction, the default way Requirement Strings work might not be enough. They were programmed to be static and seemingly cannot be modified to change based on certain conditions.
Currently, is there a way to add conditions to change the Requirement Strings to create units and buildings based on the player faction?
The text was updated successfully, but these errors were encountered: