Landmines client implementation

[Entropy]

Ok, here are the mine types (to be added at the end of client_server.h)

 

//mine types

#define MINE_TYPE_SMALL_MINE 0

#define MINE_TYPE_MEDIUM_MINE 1

#define MINE_TYPE_HIGH_EXPLOSIVE_MINE 2

#define MINE_TYPE_TRAP 3

#define MINE_TYPE_CALTROP 4

#define MINE_TYPE_POISONED_CALTROP 5

#define MINE_TYPE_BARRICADE 6

#define MINE_TYPE_MANA_DRAINER 7

#define MINE_TYPE_MANA_BURNER 8

#define MINE_TYPE_UNINVIZIBILIZER 9

#define MINE_TYPE_MAGIC_IMMUNITY_REMOVAL 10

 

 

Those are the types the server sends.

Now, on the client, we need a define for each of those mines to denote the 3d object they are going to use, such as:

#define MINE_SMALL_MINE_E3D "some e3d object"

 

and so on.

[Torg]

Ok, CVS has been updated with these details (was last night but I forgot to post. :-S)

[Entropy]

Ok, I gave you 10K mines in your inventory, on the test server.

For the time being, they can be placed anywhere, by using them as with any other object.

 

Keep in mind that they dissapear when you log out or change the map, or in 10 minutes. So you can have another char of yours there and watch them dissapear while the main char logs out.

 

Basically, the server sends the mines EXACTLY like the bags (both the list of mines and a single mine), except that another unsigned char is sent after the object_id thingy. The test mine I am using should have an ID of 0, so test for that.

 

In case you have problems, let me know. I hope the server sends the proper data, I didn't have time to test, since I don't have a mine supporting client.

[Torg]

Ok, this is basically a description of what happens (from what I can see). If its all correct then good, otherwise hopefully it explains enough for you to fix (although random problems are always an issue).

 

Firstly it appears the mines only get sent if you are quite close (within 4 or 5 map squares).

As you walk around, any you don't know of get sent.

There seems to be a bug as some of the mines I could still "see" were rediscovered when I walked away and came back (they were never "removed"). This occured whether I created them or was an observer. This seems to be random, only some mines did it.

Logging on and off, and changing maps sometimes removed mines, and other times did not.

 

Hope that helps.

[Entropy]

Ok, did you log the server messages related to mines? Because it is possible that the client mine code has some problems.

 

In theory, the bugs you reported shouldn't happen, I am using the same code as for the bags on the server (that is, the same range system).

[Torg]

Well I was logging each call to the 2 "get mine info" functions (one is the single, and the other get all), and watching that. I just enabled logging in the multiplayer function, recompiled, logged on and discovered there is a mine still being sent that I created about 6 hours ago.

 

Adding mine: X: 99, Y: 146, Type: 0, ID: 3

Edited June 20, 2007 by Torg

[Entropy]

Ok, I fixed some bugs, please try again.

The fact that their visual range is limited to just a few steps is part of the design. The other things you described aren't, so let me know if they happen again.

[Entropy]

Ok, the mines have been fixed (I think), but not on the test server yet, so do not report any more bugs until I say so.

 

I am working at actually making the mines explode and such, intially via a text only, for testing, then I will update the test server.

[Torg]

Ok, the mines have been fixed (I think), but not on the test server yet, so do not report any more bugs until I say so.

Ahhh ok. I was going to report on one I think I just found, but I'll wait. :-)

[Entropy]

Is it the one where one mine remains when changing maps, unless if there is only one mine on the map?

[Torg]

No, it seems to send the wrong mine ID to remove if there are more than 2. If I add 4 mines, I get the command to remove number 0, then 1, then 0 then 1 again.

[Entropy]

Ok, I updated the test server.

 

Now the mine actually activates when you step away, and explodes when you step on it. The explosion is just a text saying that it exploded (if it did actual damage it would make testing harder), and the mine dissapears.

 

Let me know if there are any other problems.

[trollson]

//mine types
#define MINE_TYPE_SMALL_MINE 0
#define MINE_TYPE_MEDIUM_MINE 1
#define MINE_TYPE_HIGH_EXPLOSIVE_MINE 2
#define MINE_TYPE_TRAP 3
...
#define MINE_SMALL_MINE_E3D "some e3d object"

Okay, this has bugged me for ages now...

 

Far too much information is set out in '#define' in the client, requireing a client update whenever a new item is added. This sort of data could be held perfectly well in configuration files, and changes handled through the autoupdate mechanism.

[Entropy]

It doesn't matter, because the mines have no support on the client anyway for now.

[Entropy]

So, did you test it? Everything works fine?

[Torg]

Far too much information is set out in '#define' in the client, requireing a client update whenever a new item is added. This sort of data could be held perfectly well in configuration files, and changes handled through the autoupdate mechanism.

Given we are closer to this code being released an independent configuration has been implemented so it will now be possible to dynamically update this aspect of the client.

 

The configuration file is placed in the root of the game directory.

 

/edit: New archive containing the mines.xml and mines e3d objects:

http://ian.grug.redirectme.net/el/mines.zip (right mouse click -> Save as)

Edited October 15, 2007 by Torg

[Entropy]

We have some new special effects:

 

#define SMALL_MINE_GOES_BOOM 26

#define MEDIUM_MINES_GOES_BOOM 27

#define HIGH_EXPLOSIVE_MINE_GOES_BOOM 28

#define SNARE_GOES_BOOM 29

#define CALTROP_GOES_BOOM 30

#define POISONED_CALTROP_GOES_BOOM 31

#define MANA_DRAINER_GOES_BOOM 32

#define MANA_BURNER_GOES_BOOM 33

#define UNINVIZIBILIZER_GOES_BOOM 34

#define MAGIC_IMMUNITY_REMOVAL_GOES_BOOM 35

 

All the data sent is just the player name affected by it.

[Torg]

All the data sent is just the player name affected by it.

Player name or actor ID? It would be easier and faster for the client to search on the actor ID.

 

/edit: Also, those defines don't align with the other special effects in client_serv.h. I had assumed these would be implemented in that same code?

Edited October 15, 2007 by Torg

[Torg]

Ok, started work on some Eye Candy effects for them. They are awaiting server support however. Not all are done, and not all have something so I'm not sure what the client will do if you try them! (Sorry, I'll fix it when I get the chance)