Server Help

ASSS Questions - map->GetTile

Anonymous - Mon Oct 09, 2006 7:09 pm
Post subject: map->GetTile

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 - Tue Oct 10, 2006 4:19 pm
Post subject:

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.

z.alpha+ - Tue Oct 10, 2006 5:28 pm
Post subject:

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 - Tue Oct 10, 2006 6:09 pm
Post subject:

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 - Tue Oct 10, 2006 7:18 pm
Post subject:

Smong wrote:

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

In the bricks packet, it contains the timestamp for that brick. This is so when a new person enters the zone, they can see the bricks already in game and will have theirs expire at the same time as everyone else. But you can't edit or move a previously dropped brick, as each brick has an ID number, and Continuum will only read the first packet it gets with that ID.

So if you want to shorten a brick's lifespan, just decrease the timestamp by that much. Thus, you can have bricks last 20 seconds, 5 minutes, etc. I'm not sure, but if you send a timestamp in the future, you might even be able to have a brick last longer than the bricktime, because I'm guessing Continuum only looks for when timestamp + bricktime > current time. If so, you can customize your bricks to have whatever time frame you want without effecting the normal user's bricks.

Grelminar - Wed Oct 11, 2006 1:21 am
Post subject:

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 - Wed Oct 11, 2006 7:09 am
Post subject:

drop flags on the bricks then pick them back up

z.alpha+ - Thu Oct 12, 2006 5:23 pm
Post subject:

Mine GO BOOM wrote:

[..]

In the bricks packet, it contains the timestamp for that brick.
[....]
and Continuum will only read the first packet it gets with that ID.

So if you want to shorten a brick's lifespan, just decrease the timestamp by that much.
[...]
you might even be able to have a brick last longer than the bricktime,

it would appear that continuum is not paying attention to the bricktime unless a player re-enters the arena. and in that case only timestamps in the past are accepted (possibly present but not future).

i might be able to delve a little deeper into the asss code and determine if this is because of some kinda packet correction, or if continuum is simply using an interal packet stamp.