Server Help

[z.baron+]

i am trying to use the mapdata interface to retrieve information about tile data on the current arena. .... so i setup a command with the following code:

Code: Show/Hide     int tile =  map->GetTile(p->arena,1,1); chat->SendMessage(p, "tile: %i", tile );

when i issue the command upon first entering the arena i receive the following message

Code: Show/Hide tile: 0

i then drop bricks at coord 1, 1 (the exact refernce of the gettile function above).

then I issue the command again and I get:

Code: Show/Hide tile: 250

egads, that's exactly what I'm suppose to be getting.


I wait around until the brick expires and then issue the command again and i get:

Code: Show/Hide tile: 250

ummmm, shouldn't that have reset to 0. or do i have to do somtehing to update the arena data???

no if i drop a brick someplace else, it appears the tile value is reset properly.


Also, it is possible to retreive the brickdata arena data from the bricks.c module?

ie is there some way to grab the brickkey so that I can loop through a list of all the bricks available as is done in the expire_bricks and SendOldBricks functions.

[Smong]

I suppose for now you could copy bricks.c and modify it to do what you want. Then in modules.conf comment out bricks and add the name of your new version.

Note I don't know what you're trying to do so I'm giving you a general answer here.
_________________
ss news

[z.alpha+]

what i acutally ended up doing was creating a completly new interface for the bricks which i'm calling doorbricks. it operates exactly like bricks but with the extended interface objects i bulid.

however, i hit a bump in the road because i thought the function expire_bricks in the bricks.c module was what made bricks disapper from the screen, but evidently it is done by the client, or has some thing to do with code that is depper into ASSS.

(ie , i removed the function expire_bricks and the bricks would still disappear after the set time limit)

does anyone know how bricks expiration is handled?

[Smong]

It's based on when the brick was dropped and the brick:bricktime setting that is sent to all the clients.

It may be possible to fool a client into removing a brick by resending an old brick with either an earlier start time (probably won't work with cont), or resend it with different coordinates, somewhere off the playable area (although this probably won't work either and may cause memory leaks/side effects).

[Mine GO BOOM]

[Grelminar]

Yes, the client expires bricks all by itself without any further communication from the server. The server-side brick expiry is just to clean up old data and prevent the brick list from growing indefinitely. You shouldn't rely on it happening at any specific time.

As far as getting more information out of the bricks module, I wouldn't be opposed to adding another interface function to copy the list of bricks to a caller-supplied array/list. That function would call expire_bricks before copying the list. Basically, we should enhance bricks to do what you need it to do, not replace it.

As for using bricks as doors, you might be able to make something like this work: have a module keep a list of "permanent" bricks. Every 10 seconds, send new bricks with timestamps of (now - bricktime + 15 seconds), so that they are set to expire 15 seconds in the future. Then when you want to remove a permanent brick, just stop sending updates and it'll disappear some time in the next 15 seconds. If you need better latency for removing, you can decrease those times, but be careful of sending too much data.

You could implement these "permanent" bricks in the core bricks module with new interface functions, or a new module if you want.

[Bak]

drop flags on the bricks then pick them back up
_________________
SubSpace Discretion: A Third Generation SubSpace Client

[z.alpha+]