Selon "Eric S. Raymond" <[EMAIL PROTECTED]>:
> Nils Kneuper <[EMAIL PROTECTED]>:
> > - - prevent UMC namespace collision
> > Currently it is possible that namespaces of UMC collide. This should
> > be prevented since it can lead to strange bugs. A nice and good way
> > to do so has to be found.
>
> Now *this* one sounds like something I should perhaps take the lead
> on.  I think I was worrying about managing namespaces in the WML &
> resource tree before anyone else realized this might be an issue.
>
> Can you describe the problem more completely?  What collision symptoms
> are you worrying about?

I think this problem is mainly with multiplayer addon who all share the same
namespace (#define MULTIPLAYER).
Single player is usually already in separated namespace using different campaign
#defines so they don't collide, but in multiplayer it is harder to do this since
mixing several content might be desirable (which allows to play a UMC scenario
with a UMC era that comes from another addons).

There is two kind of possible collision between two UMC addons :
- Macros :
  If two addons use the same macros with a different definition they can collide
(except if #undef is used wisely) so one of the two addons will be broken
- WML data :
  If two addons define units with the same ids, races with the same ids,
movement types with the same id,... Then one of the two addons will use the
definitions from the other addon, which might be wrong.

I can see three kind of addons for multiplayer :
1) eras
2) scenarios or campaigns
3) other utility addons (libraries of macros, ect...)

3) would be typically used by explicit inclusion so i don't think there is much
needed to deal with them.
Typically when we start a game we fill two parameters : we choose an era (which
can be any addon of type 1)) and we choose a scenario/campaign (which can be any
addon of type 2)). So typically when we mix addons it's one addon of type 1) +
one addon of type 2).
So we could define two kind of MP addons that could blend together.
We could make a cache for each 1) + 2) combination.
This might however generate a lot of caches (smaller than the current one that
include all MP addons), and cache building takes a lot of ressource especially
under Windows where this operation can really be long.
So we probably need a better way to deal with this.
Maybe having the possibility to use several caches at once would work.

However it's not that simple :
- A addon of type 2) may include 1) (typically RPG scenarios also include an
era)
- type 1) addon are sometime mixed together (for example to make a EE + EoM Era)
- it's probably possible to mixed 2) scenarios together
Btw for all those other mixes, it's an explicit mix. The UMC author that do the
merge usually know what's he's doing and will avoid collision between the two
addons.

So i think we have to find an idea for multiplayer addons namespaces.

Other than that :
- the namespace separation is user defined with #defines which mean :
  - that two addons may still use the same name for the namespace, through
unlikely.
  - some addon-specific stuff might not be isolated if the addon is not done
right
  Having some kind of unique, automatically generated namespace might help here.
- having more separate namespaces probably helps with not loading a lot of
useless scenarios and units.

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev

Reply via email to