[engine] A possibility to determine a players mp faction

[Spixi]

Hello,

it would be very helpful if there was a feature to determine the MP faction of a side with Lua and/or WML. This would help MP campaign writers to raise different events depending on the faction (e. g. Loyalists or Undead). Maybe it could be a new properity of the Standard Side Filter.

If so, it would also be nice, if you could catch the played Era, this e. g. allows to reject a specific MP scenario, if not Default is played.

I think this would make the MP scenario development much easier

[em3]

I thought campaigns didn't use external eras?

[Anonymissimus]

/data/multiplayer/scenarios/2p_Hornshark_Island.cfg contains sort of a "faction detection" algorithm in lua.

[Celtic_Minstrel]

On a semi-tangent, I went to take a look at it out of curiosity and found myself wondering why the accompanying lua file is called "2p_Hornshark_Island_lua" instead of "2p_Hornshark_Island.lua". Though, I see it's including the <<>> wrapper characters... so it's not strictly a pure lua file...

[Anonymissimus]

Yes, it is a preprocessor-embedded lua file as opposed to one loaded with wesnoth.dofile or .require. The reason for this was multiplayer-compatibility when I added this file shortly before 1.10 came out.

[Celtic_Minstrel]

When I tried to do that I had problems with table definitions being taken as macros, but I suppose that's what the space after the curly brace fixes. That said, I was only doing that because I hadn't discovered dofile yet, so I probably won't make use of that anytime soon.

[Spixi]

However, it would be much easier than a "faction detect algorithm" if a simple variable could be accessed

[Celtic_Minstrel]

It would, but currently I don't think the faction is stored anywhere; it's just a way to set the recruit list, possible leaders, and some AI parameters.

[SigurdFireDragon]

The idea could be accomplished with something like the following suggested lua tables:

1. A table that contains all of the era & faction information loaded in MP, sort of like wesnoth.unit_types. (ie, wesnoth.eras)

2. A table that contains the era & factions that were chosen for game creation. Some/all of this information could be put in wesnoth.sides
(ie, with an era and a faction field.) or in wesnoth.sides .__cfg

[Celtic_Minstrel]

As I understand, eras are not actually loaded if you're playing a campaign. Doesn't affect your suggestion much, but just saying.

[JaMiT]

it would be very helpful if [...]

Helpful for what? Do you have examples of how this can help? Maybe such things can already be done, or perhaps it would be better to consider other approaches.

For example, if you want to raise an event for the undead faction, do you want it to only occur if the scenario is being played with the default era? Maybe a more suitable trigger for the event would be if the player can recruit skeletons (or ghosts etc.).

If so, it would also be nice, if you could catch the played Era, this e. g. allows to reject a specific MP scenario, if not Default is played.

Filtering events on something less specific than "faction" would allow a scenario to instantly adapt to non-standard eras. Rather than trying to "reject" (whatever that is supposed to mean) a scenario because a different era is played, wouldn't it be better to make the scenario adapt?

Looking at EraWML, it appears a faction is, once a game begins, nothing more than a name and a list of recruits. Might expanding a SSF to (somehow) search a side's recruit list be sufficient for the applications you had in mind?

Maybe not. I am just looking at this from a "don't make things work worse by over-focusing on details" point of view.

[Celtic_Minstrel]

Might expanding a SSF to (somehow) search a side's recruit list be sufficient for the applications you had in mind?

I think this would be a good idea. Maybe also add it to SUF for leaders with extra_recruits (and it'd match if the unit is either on the side's recruit list or the unit's extra_recruit list), but that's probably less useful.

[Exasperation]

As I understand, eras are not actually loaded if you're playing a campaign. Doesn't affect your suggestion much, but just saying.

Multiplayer campaigns do load an era.

Filtering events on something less specific than "faction" would allow a scenario to instantly adapt to non-standard eras. Rather than trying to "reject" (whatever that is supposed to mean) a scenario because a different era is played, wouldn't it be better to make the scenario adapt?

Looking at EraWML, it appears a faction is, once a game begins, nothing more than a name and a list of recruits. Might expanding a SSF to (somehow) search a side's recruit list be sufficient for the applications you had in mind?

Maybe not. I am just looking at this from a "don't make things work worse by over-focusing on details" point of view.

There is at least one use-case where this isn't true. From EraWML:
"any [event]s written inside the [era] tag will get included into scenarios that are played using this era"

In the case where you have a scenario with complicated (or possibly not-so-complicated) events, it may simply be incompatible with eras that include their own events - for example, if the era's events overwrite an important variable. Working with Wesband there were several occasions where a new player would report problems with the scenario, and on further investigation it turned out that the problem was that they were using an era that included events which broke the scenario in some way. It would definitely be useful to be able to detect the era in use at the start of the scenario, and warn the player(s) about the potential for conflicts.

While in theory it might be better to have your scenarios adapt to whatever era they're used with, in practice this means being able to write a scenario that can adapt to coexist with arbitrary code - which just isn't possible (unless you manage to include strong AI in your scenario ).

[Anonymissimus]

JaMiT, or if someone else feels like figuring this out; I think having a wesnoth.sides.faction (string) key like Sigurd says which is filled with the [multiplayer_side]id= in case of a local or networked mp game makes sense. The [era]id= could be accessible as wesnoth.game_config.era (string). In case that we are in a singleplayer campaign, these fields return nil or an empty string. The difficult part here is to keep or hold this data from the point in the engine where it's read and processed so that it can be accessed later, since it seems there are not just some already existing variables that I could just provide a getter for. (And going through all that code was bit too messy when I checked it out the last time. ) If we store the faction id string as a member variable in the team class, it will also be easy to make it available in the SSF.

To add to what Exasperation said; it certainly is already possible to check for whether a certain era is used and then reject the game in case the ones allowed aren't used. To do that, add an era event which sets a variable and check in a scenario event for that variable. Just adapting to arbitrary eras isn't possible in practice, but preparing for some works. And just rejecting everything else.

EDIT
There's also a FR for the era thingy: http://gna.org/bugs/index.php?18954

[JaMiT]

In the case where you have a scenario with complicated (or possibly not-so-complicated) events, it may simply be incompatible with eras that include their own events - for example, if the era's events overwrite an important variable.

That would be rather unlikely if the eras (and/or the scenario) would use a prefix for their variable names, but I suppose that relies on UMC authors knowing about safe programming practices. (In the campaign I've been working on, my variable and macro names start with the campaign's abbreviation. That would be analogous to Heir to the Throne's variables starting with "HttT_".) Since there can be only one era in any given game (right?), maybe a reasonable convention would be for eras to only use variables whose names begins with "ERA_", and scenarios to only use variables whose names begin with "SCN_" (or "SCENARIO_" if that is not too much typing). No naming conflicts if that convention is followed, and there should be few conflicts if even just the era or just the scenario follows that convention. It still requires UMC authors to follow guidelines, though.

It would definitely be useful to be able to detect the era in use at the start of the scenario, and warn the player(s) about the potential for conflicts.

I think it might be nicer if the host could see the "target eras" before selecting the era, but the scenario/era selection window is already overfull at the lowest resolutions. The GUI designers would have my head if I suggested adding something else there.

While in theory it might be better to have your scenarios adapt to whatever era they're used with, in practice this means being able to write a scenario that can adapt to coexist with arbitrary code

There is a middle ground between "adapt to whatever era/coexist with arbitrary code" and "force playing with default". A scenario can be designed to adapt to eras that fall within certain guidelines, without being guaranteed to work flawlessly with arbitrary code. And those guidelines might be rather loose, maybe just a standard to avoid naming conflicts. Or maybe just a disclaimer that some events will only fire if certain mainline units are included in recruit lists. Sometimes it is easier to make code more robust than to try to force certain assumptions (like forcing the era being played). Not always, but sometimes.

Also, it might be nice to work towards greater compatibility than to assume conflicts are inevitable. Try to push the middle ground into the realm of "playable".


I suppose another question is who should be considered "responsible" for conflicts between an era and a scenario. The assumption in this topic seems to be that it is the scenario's author who should warn players that unstable eras exist, rather than the era's author who should warn players that the era might have compatibility problems with scenarios that are more than a straight-up fight.