[multiplayer] addon with custom unit => unknown unit type

[Anonymissimus]

Apparently, when joining an addon [multiplayer] scenario with custom units on the server, which one hasn't downloaded too, one gets kicked from the scenario with an error about unknown unit type as soon as such a unit ought to be created. I suppose that if one hasn't the exact same version as the host it could instead lead to OOS. Also, I suppose same problems happens for other top-level tags too (e.g. [terrain_type], not only [unit_type]).
Is there a solution for this ? I'd like to have a key which causes games to be greyed out so that one can't join like it's done for eras (the require_era=) key.
A workaround could be to pack the multiplayer addon's units into an era shipped with the addon, so a knowledgable enough host can choose the appropriate era and thus ensure that only people with the addon join. (I think GEB is doing this, isn't it !?). However, is there a way to force the selection of the correct era ?

The "conquest" mp addons seem to do some intelligent unit-modifying instead of defining own unit types in an era. This seems doable since for units almost all attributes can be modified. However I'm wondering how I could work around the need for a custom terrain_type in SoW...

Are images ([binary_path]) sent over the network to the other clients btw ?

[Anonymissimus]

*BUMP*
Is this too tough a question ?

[Alarantalara]

Terrain graphics tags can be embedded in a scenario.
You can use them to draw over existing terrain values so that they look like what you want.

You would need to find one terrain type for every new terrain you have that isn't already used (Looks like 14 in your terrain file).
You also will have to define your own flags and make sure you redraw everything at a higher layer than the original contents of that terrain because the scenario terrain tags come last so get applied after everything else (which means that the original terrain always gets drawn first and will set its flags). Fortunately, the numbers cover the whole image, so setting their layer to 1 will cover pretty well everything.

Terrain names at the top will be unchanged, but it shouldn't matter for you in this case.

I'd try and give you a demonstration, but the version of SoW on the server currently gives me an error message about an image not on the canvas (y=-127) so I can't play to find out.

(Edit: this of course doesn't solve moving images, but it might deal with your tri-directional roads. I suppose that's what I get for only looking at one part of the problem.)

[zookeeper]

Apparently, when joining an addon [multiplayer] scenario with custom units on the server, which one hasn't downloaded too, one gets kicked from the scenario with an error about unknown unit type as soon as such a unit ought to be created. I suppose that if one hasn't the exact same version as the host it could instead lead to OOS. Also, I suppose same problems happens for other top-level tags too (e.g. [terrain_type], not only [unit_type]).
Is there a solution for this ?

Unfortunately, no.

A workaround could be to pack the multiplayer addon's units into an era shipped with the addon, so a knowledgable enough host can choose the appropriate era and thus ensure that only people with the addon join. (I think GEB is doing this, isn't it !?). However, is there a way to force the selection of the correct era ?

No, but you can make a scenario event which checks which era is used and outputs a warning message if it's something other than the intended era. That should be good enough, I'd think.

The "conquest" mp addons seem to do some intelligent unit-modifying instead of defining own unit types in an era. This seems doable since for units almost all attributes can be modified. However I'm wondering how I could work around the need for a custom terrain_type in SoW...

Are images ([binary_path]) sent over the network to the other clients btw ?

No.

[Anonymissimus]

Terrain graphics tags can be embedded in a scenario.
You can use them to draw over existing terrain values so that they look like what you want.

This doesn't overwrite terrain graphics for the other mp scenarios (same preprocessor scope) ?

I'd try and give you a demonstration, but the version of SoW on the server currently gives me an error message about an image not on the canvas (y=-127) so I can't play to find out.

I don't unerstand how that still happens. It's scaled down so that it should work on most resolutions. Try commenting the
name=sow_menu_help_message
line in that event in sow_scenario.cfg.
Mordante oughta fix it but he refused...

No, but you can make a scenario event which checks which era is used and outputs a warning message if it's something other than the intended era. That should be good enough, I'd think.

How would that work ?
Maybe it works using lua's pcall for wesnoth.put_unit with one of the unit types which is unique for the era which should be used. If another era is used, the unknown unit type exception is catched by pcall and the scenario can be ended conditionally.

[Alarantalara]

Terrain graphics tags can be embedded in a scenario.
You can use them to draw over existing terrain values so that they look like what you want.

This doesn't overwrite terrain graphics for the other mp scenarios (same preprocessor scope) ?

No, it's limited to the scenario scope. See the animated campfire macros used in Thousand Stings Garrison if you want an example (they don't suddenly appear in the innumerable X,Y locations specified in other maps). Tying it to a terrain type instead of a location just lets you place the images in code instead, though the lack of image transfer zookeeper mentioned means this will only help you with the roads.

I'd try and give you a demonstration, but the version of SoW on the server currently gives me an error message about an image not on the canvas (y=-127) so I can't play to find out.

I don't unerstand how that still happens. It's scaled down so that it should work on most resolutions. Try commenting the
name=sow_menu_help_message
line in that event in sow_scenario.cfg.
Mordante oughta fix it but he refused...

That does resolve the issue for me. I would have thought my rather high resolution (~1500x900) would have protected me from such issues.

[zookeeper]

No, but you can make a scenario event which checks which era is used and outputs a warning message if it's something other than the intended era. That should be good enough, I'd think.

How would that work ?
Maybe it works using lua's pcall for wesnoth.put_unit with one of the unit types which is unique for the era which should be used. If another era is used, the unknown unit type exception is catched by pcall and the scenario can be ended conditionally.

Well, you give the era a prestart event which sets a variable, and then you give the scenario a start event which checks the same variable. Of course you might be able to use Lua to check the era more directly somehow.

[SlowThinker]

The "conquest" mp addons seem to do some intelligent unit-modifying instead of defining own unit types in an era. This seems doable since for units almost all attributes can be modified.

It is not very intelligent:

It is done by modifying the mainline units, but there a two problems:

• the picture cannot be modified, so an overlay is used (and so people that misses the add-on sees the original picture, and also the status window shows the original picture)
• the name of the unit type cannot be modified, and so unit name is used for this purpose

[Anonymissimus]

• the picture cannot be modified, so an overlay is used (and so people that misses the add-on sees the original picture, ...)

Doesn't seem quite logical... Take mainline images for the overlays, then it should appear for players who don't have the addon too. (Gwledig's fortification images did, even though I didn't have the addon.)
Also, if the [unit]image= attribute isn't modifyable in 1.9 you may file a feature request.

[SlowThinker]

Doesn't seem quite logical... Take mainline images for the overlays, then it should appear for players who don't have the addon too.

Conquest uses own images of a dhow and caravel, I guess there weren't more mainline boats.

Also, if the [unit]image= attribute isn't modifyable in 1.9 you may file a feature request.

I have no idea how it works with 1.9.
But I think it is not only about modifying the image, but also about distributing the file from the host, and it might not be compatible with the current conception.