Server Help

[Dr Brain]

Code: Show/Hide 3.2.2. "REGN" chunks these chunks define regions. to recap, a region is a set of tiles, usually but not always contiguous, with certain properties. asss understands regions and can implement some advanced features using them. currently continuum doesn't understand regions, but it would be nice if it did, and we'll be able to do even cooler things when it does. there's a lot of stuff that you might want to say about a region, so to support all the varied uses, and also future uses, we'll use the chunk model again: each region gets its own set of "subchunks" describing its function. to avoid confusion, all sub-chunk types that go inside the "REGN" superchunk start with "r". the data of the big "REGN" chunk is simply a series of subchunks. here are some defined sub-chunk types: "rNAM" - a descriptive name for the region "rTIL" - tile data, the definition of the region "rBSE" - whether the region represents a base in a flag game "rNAW" - no antiwarp "rNWP" - no weapons "rNFL" - no flag drops "rAWP" - auto-warp "rPYC" - code to be executed when a player enters or leaves this region

Does it make sense, at this point, to put region stuff into the player downloaded maps? It makes the downloads longer on an already slower ASSS download.

Code: Show/Hide 3.2.2.2. "rTIL" chunks this is stored as a sequence of 4-byte values that hold tile coordinates. every chunk should have exactly one of these. struct tile {     unsigned x : 12;   // range 0-1023, upper two bits should be 0     unsigned y : 12;     unsigned tile : 8; // unused for this purpose };

So, a region of 100x100 would need 10,000 rTIL entries, no?

I have a map where a single region takes up more than half the map (156 region v1 rectangles). That's more than 524,288 rTIL entries. That would probably double the map size.

Code: Show/Hide 3.2.2.4. "rNAW" chunks this is a 0-byte chunk. if present, antiwarp should be disabled for ships in this region. currently, this disabling happens on the server, and players whose antiwarp is being disabled aren't necessarily aware of it. it would be nice if in the future continuum understood this feature so that it could inform the player that antiwarp is unavailable in this location.

Shouldn't all these region properties really have their own region?

Oh, and the antiwarp module I posted turns the player's antiwarp off in the client. While not as nice as something built straight into Continuum, it certainly lets the player know that his antiwarp isn't getting out.

Code: Show/Hide 3.2.2.5. "rNWP" chunks this is a 0-byte chunk. if present, all weapons are non-functional in this region. the same notes apply to this feature as to the no antiwarp feature.

Again, I would think it's own region would make for easier processing.

Code: Show/Hide 3.2.2.6. "rNFL" chunks this is a 0-byte chunk. if present, any flags dropped in this region are respawned as neutral flags in the center of the map (or wherever the settings indicate they should be spawned).

No flag regions aren't needed by the client, so having it's very own region makes even more sense here.

Code: Show/Hide 3.2.2.7. "rAWP" chunks this chunk, if present, turns on the auto-warping feature. any player entering this region will be immediately warped to the specified destination. the data for this chunk specifies the destination, in this format: struct autowarp_destination {     i16 x;           // the destination x coordinate. 0-1023, or -1 for                      // the player's current x coordinate.     i16 y;           // the destination y coordinate. 0-1023, or -1 for                      // the player's current y coordinate.     char arena[16];  // the destination arena name. null if the warp                      // does not cross arenas. }; as a simple space optimization, if the warp does not cross arenas, you can leave out the 16 bytes of arena name, so that the whole chunk data is 4 bytes long.

I would add a warp type. That way custom modules can use this without breaking things. And perhaps a destination rectangle rather than a destination point. Some warp types could use only the x1,y1 of the rect as a point. Perhaps a callback in ASSS to notify the custom warp handlers.

Code: Show/Hide 3.2.2.8. "rPYC" chunks this chunk lets you embed code in level files. the exact semantics of this data haven't yet been determined, but it'll probably go something like this: this chunk should contain ascii data representing some python code. the code will be executed when the map is loaded, and it may define several functions: a function named "enter", if it exists, will be call each time a player enters this region. it will be called with one argument, which is the player who entered the region. a function named "exit" works similarly, except of course it gets called when someone leaves.

I assume that this is server side. Again, this has to be downloaded by the player. It might also pose security problems (though I don't know how).



That all being said, I do like the other new map stuff.

My suggestion is to make a map format that the server seperates out. It keeps one half, and sends the other half to the client. This keeps everything together like you want, but doesn't unnessicarily increase downloading times. This could be as simple as a .zip file with a .elvl and a .rgn2 in it.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[CypherJF]

I don't really care what you do, as long as you do not modify the structure of the LVL, to a specific server software. (and continue calling it a LVL file)
_________________
Performance is often the art of cheating carefully. - James Gosling

[Grelminar]

[Dr Brain]

I meant that it's simpler to have one noanti region than to have a noanti flag in several regions.

[Grelminar]

oh, i see what you mean. effectively, that's like having the noanti (etc.) flag forced on in one specifically-named region, and off in all the others. i think having separate flags makes things more flexible. e.g., a map maker could set up a bunch of noanti regions, and turn on and off different combinations of them easily, rather than editing the region tiles themselves. or you could play with the noanti flag at runtime to grow and shrink the noanti area depending on player count. or something like that.

anyway, the flags are only 8 bytes per region they're on in, probably compressed down to 5. the only good reason i can think of to have a dedicated noanti region is efficiency, but i don't think that'll be a big deal.

[Grelminar]

ok, i wrote up something should be much more efficient for reasonable regions. the spec is updated. the modified section is:

Code: Show/Hide 3.2.2.2. "rTIL" chunks this subchunk describes the tiles that make up the region. it's stored in a compact rle-ish representation. conceptually, a region is some subset of the 1024x1024 tiles in the map. to encode a region, encode it row by row, left to right, top to bottom. for each row, split it into runs of empty tiles and present tiles. for each run, output one of these bit sequences:     000nnnnn          - n+1 (1-32) empty tiles in a row     001000nn nnnnnnnn - n+1 (1-1024) empty tiles in a row     010nnnnn          - n+1 (1-32) present tiles in a row     011000nn nnnnnnnn - n+1 (1-1024) present tiles in a row for the two-byte sequences, the bits in the second byte are the low bits, and the two bits at the end of the first byte are the high bits. for example, if you have a run of 10 present tiles, you'd output the byte 01001001, or 73 decimal. if you have a run of 300 empty tiles, you'd output 00100001 00101011, or 33 43. for each row, you must output a sequence of runs that sum to exactly 1024 tiles. anything else (missing tiles at the end of a row, or a run that extends past the end of the line) is an error. there are two exceptions to the above rule: first, rows that contain no tiles at all can (optionally) be encoded specially:     100nnnnn          - n+1 (1-32) rows of all empty     101000nn nnnnnnnn - n+1 (1-1024) rows of all empty second, if the same pattern of tiles appears in more than one consecutive row, you can use these special codes to save more space:     110nnnnn          - repeat last row n+1 (1-32) times     111000nn nnnnnnnn - repeat last row n+1 (1-1024) times the rTIL chunk must describe exactly 1024 rows. this might require only two bytes (163 255 for the totally empty region), or it might require much more. note: several bit patterns don't correspond to any of the above codings. that's deliberate. don't use them.

comments?

[Cyan~Fire]

Individual tile positions to some kind of bit list? I think that's taking it a bit too far. What about a list of rectangle structures (like MS' RECT) or something vaguely similar? It would even be more effecient than the bit thing if your region was somewhat rectangular.

Or maybe even define a bunch of different shapes (or at least a circle as well) with their own different structs.

Sorry if this is somehow newbish in a way I don't see... I haven't had too much experience with asss myself. Yeah, that was a double meaning.
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Grelminar]

[Solo Ace]

[D1st0rt]

In being an ass or getting some?
_________________

[Smong]

OK, I've been away from the scene for a while due to the nations telco being pretty naff so I haven't read the docs yet, but here is something I saw while skimming through this thread:

[Grelminar]

the idea of the chunk types is that data for different modules and different purposes won't get confused. you're encouraged to create chunk types besides the predefined ones. so rAWP chunks would be for the built-in antiwarper to use, if you want extra data in chunks that have something to do with warping, it would be another type. that's much easier than doing some weird hack with the arena name field.

forgive my ignorance regarding lvz stuff: using tiles.bm2, is it possible to have different tilesets for different maps in a single zone? and is it possible to share one tileset between a bunch of different maps in the same zone?

[Mine GO BOOM]

[Grelminar]

well, then i guess that does eliminate the need for a tileset filename in the lvl. i'll remove that stuff from the spec.

[-Smong-]

When creating custom chunks, how are we supposed to know that the name/id we choose doesn't conflict with someone elses? The persist module has the same problem.

[Bak]

Do region subchunks have the same chunk-header as regular chunks? Furthermore, must region subchunks also be padded up to 4 byte boundries?

[Grelminar]

Yes, and yes. My code uses the same function to parse the whole metadata section and to parse region subchunks, and I suggest you do too.