Does the server support...

[Lucifer]

Heh, I missed the teleport thing.

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.

I see what you mean about dead players, I'm still inclined to have actions available to act on dead players, but I also see how that could get silly quickly.

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.

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.

[Lucifer]

My current favorite handling of this would be: release 0.2.8 without CTF code and push out the first development release 0.3.0 with basic zone code as Philippe designed shortly afterwards. So shortly after 0.2.8 and with all bugfixes merged back into the trunk, 0.3.0's stability is likely to be extraordinarily high for a development release, so we can recommend it to server admins who want a new game mode without getting bad karma.

I can go with this. I had already figured that if it got struck down, I'd play a wait and see game where as soon as the code appeared (or if I wrote it) then I'd backport it to 0.2.8 and run my server with it anyway, possibly releasing the patch against 0.2.8 so other admins could do it. So long as the client supported the stuff it needed to, anyway. I couldn't very well require a custom client on my server, could I? But if the client didn't support it, then I'd very strongly try to argue in favor of doing it for 0.2.8, knowing how weak is my position with the current study load I have.

[philippeqc]

team spawn specs.

I'm really really sorry, this is quite a crappy document. If there is a point I would like you to put a bit more effort to decypher my meaning is the method to associate a player to some map items such as Zones for ownership purpose based on their spawn point.

-ph

[philippeqc]

The client should support multiple win zones;

Thats a good news! I'll try to have a look at it during the week. And ok for branch-branch.

I've literally spent the day writing specs instead of moving the code for map support for settings. I'll try to squeeze it in on a branch-branch during the week. Its simple enough that it shouldn't cause any problems.

The difficult part about the CTF hack would be to make sure the teams get spawned close to their own flag (actually, the best way probably is to let the flag determine what team it belongs to after it's spawned, this keeps the code nicely local), the flag logic itself is almost trivial. I can take care of it.

check the 2 document I posted today. I sincerely appologyze for Spawn-a.txt.

-ph

[Luke-Jr]

1. Can a map control the winzone?

Useful also for some kind of advanced pac-map, which is what made me think of it originally. We'd want to control not only location and growth, but also movement.
Anyway, this is more of an advanced map thing, along with borders and such...

I dont think this discussion is about who presented the idea first, but about inserting a simple item that will greatly impact gameplay.[/quote]
I was merely putting this point out here to show another possible use (and at the same time, point out that I was well aware of this possibility since before the feature freeze).

While I'm spec'ing the whole shabang, it is to ensure a good transition between versions. The implementation for 2.8 (Arthemis) would be very simple.

And an implementation for 0.4 would not be simple?

2. Can the map control team spawn points?

Don't teams share the same spawn point?

Yes, as long as the map designer want all the players of a team to start together in a wingman configuration. I could imagine a map like HexaTRON where team members are spread in opposite rooms.

Interesting idea... but a possible problem would be that we might end up with all the players spawning in a single room when the usual 1-person-per-team is applied... any way to get around that?

[Luke-Jr]

Luke: without respawning, what we call CTF here is more similar to symmetric counterstrike; the flag zone of the enemy is the place where you have to drop the bomb. This could be a lot of fun,

Hmm... but then at the same time... how hard would "normal" CTF be to support?

won't require too many additions and be compatible with old clients (you're right, the color is transmitted with the zone creation message; I somehow thought it was a setting item).

It was, until I changed that so winzones were green... at the same time, I figured let the server delegate the exact colour so we weren't locked to specific win/death functionality colouring.

My current favorite handling of this would be: release 0.2.8 without CTF code and push out the first development release 0.3.0 with basic zone code as Philippe designed shortly afterwards. So shortly after 0.2.8 and with all bugfixes merged back into the trunk, 0.3.0's stability is likely to be extraordinarily high for a development release, so we can recommend it to server admins who want a new game mode without getting bad karma.

Of course, when I say 0.4, the changes would also be in a 0.3 release (0.3.0 or later, if it turns out to be more complex to implement) since 0.3 leads up to 0.4

[Luke-Jr]

So long as the client supported the stuff it needed to, anyway. I couldn't very well require a custom client on my server, could I? But if the client didn't support it, then I'd very strongly try to argue in favor of doing it for 0.2.8, knowing how weak is my position with the current study load I have.

The 028 client wouldn't be able to handle zone-defining maps, since the parser will error. If the error was ignored (like I was trying to push a while ago), then it should work anyway since it is the server determining zone creation and such. If we keep the map validation, a work around would be for two map files, one without the zone info that is sent to clients and one with it for the server.

[philippeqc]

First mistake revealed from the Zone spec: "match" should be read as "round", ie the smallest of both units. All times are counted from match start. I'm sorry for the confusion.

While I'm spec'ing the whole shabang, it is to ensure a good transition between versions. The implementation for 2.8 (Arthemis) would be very simple.

And an implementation for 0.4 would not be simple?

No, it would be the whole shabang. The phrase could have been constructed like this: "I've spec'ed everything so it is ready for Bacchus (I dont know if that's 0.3 or 0.4). The Zones will be an involving project for that release. Having the complete spec's at hand today, we have the possibility of making a very limited implementation to add much needed functionallity, which would be very simple, and be compatible with the whole shabang, as it follows the specs.

Useful also for some kind of advanced pac-map...
I dont think this discussion is about who presented the idea first, but about inserting a simple item that will greatly impact gameplay.

I was merely putting this point out here to show another possible use (and at the same time, point out that I was well aware of this possibility since before the feature freeze).

Yeah.

Your pac-map had zones moving around the map . For me that was an very advanced feature when you mentionned it, so no I didnt consider it for the current release as at that time. I also had already started to invest myself and my time on the multi-field aspect of comming maps. But I also acknoledge that you presented the idea of locating some win zone on a map.

But because you stated it, it was part of the ideas I tried to encapsulate in the Zones.

I understand your frustration that when you presented the idea, I relinquished it as a Bacchus one. When Lucifer presented his first request, I also processed it in the same fashion. What changed my mind was that he (in my eye) justified that the current map asked for it, and pointed the capacity was already there, and simply needed placeholder in the map.

I needed a way to expose the functionality from the map, and I wanted to ensure that it would be valid for a while, hence the spec.
Now I simply need to code support for win and death zone from the map (most likely locked down capacity such as target=self, owner=none, user=all, startTime=mapInstantiation, endTime=roundEnd).

2. Can the map control team spawn points?

Don't teams share the same spawn point?

Yes, as long as the map designer want all the players of a team to start together in a wingman configuration. I could imagine a map like HexaTRON where team members are spread in opposite rooms.

Interesting idea... but a possible problem would be that we might end up with all the players spawning in a single room when the usual 1-person-per-team is applied... any way to get around that? :/[/quote]
Read the Spawn-a.txt document, where is say that "control between wingman vs spreading on all team owned spawn point is controlled by an external factor" (not an actual quote). This fancy sentence has many extra untold bits of information:
- I recognize that there is a need for a mecanism here, but that said mecanism is not directly related to assignement of spawn points to teams and players, which was the scope of the document,
- I recognize that such a mecanism will rely on policy, and like every other policy encountered, no 2 people will want the same one, and that arguing about policy is not something that I care much about,
- I knew that joda.bot was workign on some code about splitting players in teams and was awayting for my specs of team spawn points. I guessed that he might have an idea how to address this, while I didnt, so I wanted to let it open to him

So overall, the real answer is "I dont know, but joda.bot might". Wow, that was lame after such a text. Sorry about that, it felt necessary to separate the association mechanism and the distribution one.

Luke-Jr and everyone, I hope this helps you understand the scope that I'm planning to insert in the lock-down. In my mind it was obvious from Lucifer 's request, but I understand that you might have read something different in my enthousiasm to spec's the whole shabang.

-ph

[philippeqc]

So long as the client supported the stuff it needed to, anyway. I couldn't very well require a custom client on my server, could I? But if the client didn't support it, then I'd very strongly try to argue in favor of doing it for 0.2.8, knowing how weak is my position with the current study load I have.

The 028 client wouldn't be able to handle zone-defining maps, since the parser will error. If the error was ignored (like I was trying to push a while ago), then it should work anyway since it is the server determining zone creation and such. If we keep the map validation, a work around would be for two map files, one without the zone info that is sent to clients and one with it for the server.

Or we make a last minute change to the DTD (and possibly the code).

On the topic of the DTD, I've noticed an invertion that bothers me a lot. The World and Map should be inverted. The Map should hold one or more World, and not the World holding a map. So either we change it now, break all the map, say "oups, my bad, but its still beta anyway", and eradicate the problem within the week with beta 3, or we have a new version of the DTD in a separate file, carry both in the release, and for months to come, have to repeat that no, its no longer World/map, it now map/world, please get the latest tutorial, yes I know server so and so still use the format and it works great, and la dy la dy da. Guess which one I beleive has the lowest cost.

Luke-Jr, I know that forcing dtd validation brings some problems. But when I think about all the problems that we totally dodge, and I see many of them, and they are each and every one at least twice the monster, all my worries fly away. The devil you know. (*)

-ph

(*) i heard that expression once, and thought it was quite nice. I have no idea if it stops there, but if you are like me at that time, finish it with "... is easier (to deal with) that the one you don't."

[Lucifer]

I'm inclined to go ahead and break existing maps. That's with a server with what, 6, 7 maps to support? I don't really want to have to support legacy stuff that made it past beta if we don't have to.

[Lucifer]

Oh yeah, if you could just increment the dtd, roll in the wall thing you mentioned to 'tard in another thread, and go ahead and support the old dtd through beta3, that would ease migration for those of us who are running maps right now. (Are there any other servers running maps yet? I haven't seen any, but I haven't looked either)

Edit: In case you're interested, I setup the map editor I'm working on to validate also. So if a map is broken when you load it, you'll know. Just one of the reasons I spent 4 hours and only wound up with a basic map presentation....

[philippeqc]

Oh yeah, if you could just increment the dtd, roll in the wall thing you mentioned to 'tard in another thread, and go ahead and support the old dtd through beta3, that would ease migration for those of us who are running maps right now. (Are there any other servers running maps yet? I haven't seen any, but I haven't looked either)

The is one extra mini prob. The parser code need to be changed to reflect the change in the hierarchy of the dtd. while it *COULD* be possible to support both, my time budget this week is quite small. Might i call on the Trineratum (or something relatively close) to green light my decision?

Edit: In case you're interested, I setup the map editor I'm working on to validate also. So if a map is broken when you load it, you'll know. Just one of the reasons I spent 4 hours and only wound up with a basic map presentation....

Rock on! A validating map editor will greatly diminish the number of faulty maps that will reach servers!

A question like that, are you planning to read the DTD to know what keywords are valid, and build the list of said keywords dynamically from the DTD. This would make your editor able to support any new DTD instantly.

-ph

[Lucifer]

No, I just used the xml.sax module in Python, watch for the DTD and then build a path to it. Nothing crazy.

I think it's using expat on the backend, but I could make it use libxml2 if I wanted, I think that's available to python also. Not a big deal, though, because I figure we're going to distribute it in self-installing files for Windows using py2exe, and source for *NIX, and whatever nemo dreams up for os x. That's a ways off, still, and maybe you guys don't want to adopt a pygame-based map editor but would prefer instead to just direct people to it. (I'm not going to deal with that until it's ready for other people to hack on it anyway, at which time I'll be asking what the cvs module should be that includes extra applications)

[Z-Man]

Might i call on the Trineratum (or something relatively close) to green light my decision?

You have my agreement to do anything you deem appropriate here. We can also delay beta3 a week; the bugs have just waited for my announcement again before they came creeping up from under the beds, so I'll have to locate and fix some more and a little extra time for the fixes to settle may be good. It's only a beta, but we should not rush it out with known flaws.

While we're changing the dtd: I'd like to see the resource information about the author and category in a separate tag at the top level, like

Code: Select all

<Resource type="aamap" name="Tzeentch" version="0.1" author="Dave Fancella" category="Breakfast" />

and use it for other xml resources later, too? This would make resource handling generic and easier. Currently only the resource sorting script would benefit (and I'm lazy).

I still need to read the spawnpoint docs...

[Lyx]

I merelly skipped through all posts in this thread but didn't notice anyone mentioning it - if it was, then sorry, ignore this post.

About turning brakes into a mild accelerator: *if* you plan to implement the option of having boosters and brakes simultaneusly in games, then this would mean that you will probably have two seperate keys for them. In this case, turning the brakes into accelerators may be unintuitive in terms of mapped keys.... maybe it would make more sense to do something with the boosters instead, so that the "accelerator" uses the "correct" key.