Does the server support...

[philippeqc]

An extra week might be very convenient for me as I've been robbed of many evening this week. Also, it's my last contract week. And next week, I'm planning to take a well deserved rest, witch will probably include lots of AA coding ;)

-ph

[Luke-Jr]

I suppose adding this feature despite the feature freeze could be justified by claiming it's an existing feature, just lacking a config/map option to enable or use it (which is a bug to be fixed)-- is that what you're getting at?

If we're changing the map format (map/world), I think we should change the version number-- that way existing maps will still validate with 0.1 and the code can continue to load them (if needed, I can write the dual-version-loading code-- it's quite simple) and newer maps will be 0.2 or 0.1.1. For future support, we mainly just need to include all the DTDs supported with the game distribution.

[philippeqc]

Oups, it seems I missed a few post between both documents, sorry to all

How about named spawn points, and respwn at named point? I was already thinking of building a map with three areas and using a teleport mechanism to move players between the areas (essentially what games already do to support multi-floored maps). Anyway, I'm not trying to feature-creep the feature-creep.

the inconvenient of beaming someone over at a spawn point is more dangerous in ArmagetronAd than in say Quake because we leave something behind us.

Otherwise, its the promised eConnector.

As for instantiating a zone multiple times, how about just supporting multiple conditions for both spawning the zone and destroying the zone? Then leave it to the map maker to make sure the conditions are consistent and understandable.

I'll need to revisit the idea to see if multiple condition or additional single condition would be best. I put that in my head and let it simmer.

Combining primitives could be hard, but you could follow the cascading model alredy used in html. Give the last one priority over the one before it, and then reversed through the list. Which means, of course, that you apply the first one listed first, then the second, then the third, ad infinitum. I guess that depends on the parser. If the parser is guaranteed to list the primitives in the order they appear in the file, then no problem. If not, it would probably be easier to leave this as undefined and sort it out later.

I'll need to read alot on this topic first, which will most likely push that possibility to a later release. Again something to keep in mind.

One addition: The action of a zone ... the player needs to be inside the zone for N seconds.

Good, noted. Will be in next draft.

Edit about the dead player respawn: this could be an effect on a Team: spawn one dead player from your team/the enemy team/whatever team the effect targets.

yes, its all in naming the appropriate combinaisons. I prefer this to a model where the possible target depend on the effect. It allows for some crazy combinaisons, such as "give points to dead player of enemy team", but the map creator are in full control of said effect.

-ph

[philippeqc]

I suppose adding this feature despite the feature freeze could be justified by claiming it's an existing feature, just lacking a config/map option to enable or use it (which is a bug to be fixed)-- is that what you're getting at?

You are expressing it with a clarity that I could never have reached. I have to confess that you found a sanctionned way to justify this, and I would never have.

Win and death zone as they work now as for owner, target and user. startTime would probably be "mapInstantiation" only, but I'd like to squeze in "stale mate". endTime would be "round end" as now. trigger would be "on entering", persistence would be permanent, posX, posY, initialRadius, and I'd like to implement growth, mostly so it is possible to specify a growth factor of 0.

So yes, current win and death zone place holder, with a correction (controling the growth) that make them better adapted to map.

-ph

[joda.bot]

Syntax in the map:

A team element may contain player elements and spawn elements.
A player element may contain spawn elements.
The id's need not to follow any rule other than to be unique in
their own series.

Problem/Ideas:

I'd prefer spawn points to be owned by teams ONLY.
Teams can have 1-n spawn points. Perhaps there should be a default constraint that the first spawn point is assigend to the "first" player on the team.
Result: Spawn points are owned by teams which constist of players.

Problems:
1) Without automatically generated spawn points (e.g. wingman configuration) the map might limit the number of teams/players per team. The maximum values are ridiculous for maps with wingman configuration (or other automatic startup formations?) or map scaling.

2) If the map contains game objects which should belong to a certain player P1 of team T1 then the some kind of spawn point ID could be used.
e.g. object's are assigned to a player if the player owns the spawn point (This problem might prevent teams to own spawn points ...)

3) Respawn points can be identified by an attribute. For example respawning inside a fortress zone is pretty dangerous as it's usually crowed, so the designer might add "respawn points" for each team farther away from it.

4) Spawn point assignment depends heavily on the game logic, thus I guess more restrictions inside the map might prevent crazy, scripted concepts. Perhaps it's best just to define named sets of spawn points
and each set of spawn points can contain a list of game objects associated with it. Only a server has to interpret the spawn points and lists of game objects, right? The default engine behaviour would be to assign all game objects to the team which was assigned to the corresponding spawn point set. A script could do other complicated things, for example change their owners (capture the flag).

Concerning XML style: I prefer the hierachical approach.