The client never actually sends its position in the worm hole. Because once the client enters it, it goes to a new location. So you won't get any "hey, I went into a wormhole" announcement. Though, you could guess if they went into one, because if they were near it, and all of a sudden they are somewhere else and their "warp" image flag is toggled, they could have entered it. Or they could have attached, uncloaked, portaled, or hit insert.
As for the programming of find the wormhole coords. What language are you using? If C/C++, I recommend using the following:
Code: Show/Hide struct tilerecord
{ unsigned x : 12; unsigned y : 12; unsigned tile : 8; }; |
Then every 4bytes (or int) you read in, just type it to a struct tilerecord. Example (quick hack, didn't debug/compile):
Code: Show/Hide #pragma pack(1)
struct tilerecord { unsigned int x : 12; unsigned int y : 12; unsigned int tile : 8; }; struct lvlheader { unsigned short type; /* should be 19778, aka 'B' followed by 'M' */ unsigned int lengh; }; #pragma pack() ... stuff goes here, assume now i'm inside a function ready to read the coords off .... char buff[6]; struct tilerecord *tile = (struct tilerecord*)buff; struct lvlheader *header = (struct lvlheader*)buff; /* could use a union, but this is good enough */ FILE *f; f = fopen(LVLFILENAME, "rb"); if (!f) return 0; /* couldn't open file */ if (fread(buff, 6, 1, f)) /* check to see if has bmp data up front */ { if (header->type == 19778) /* yep, has the string "BM" up front */ fseek(f, header->length, SEEK_SET); /* skip forward to end of BMP data */ else /* didn't have header up front, means should be tile info */ fseek(f, 0, SEEK_SET); /* rewind to front again */ } else /* couldn't read 6 bytes, which COULD mean a lvl with only 1 tile, or an empty file */ fseek(f, 0, SEEK_SET); /* We should now be where the tile info is at */ while (fread(buff, 4, 1, f)) { /* keep reading until we cannot read 4 bytes anymore */ if (tile->tile == 220) /* check to see if wormhole */ { /* Do your "found a wormhole" stuff here. * Remember, it only tells the upper-left corner of a wormhole, * so the actual area includes the 4x4 box (i think) to the right/down * of this position. */ } } fclose(f); |
Remember, that is without any debugging, and going by what I remember and what the map file format site said.
50% Packetloss - Tue Oct 07, 2003 4:21 pm
Post subject:
Yep, C++, That code helps out greatly! Actually I would use something like this, in merv
Code: Show/Hide case EVENT_PlayerMove: { Player *p = (Player*)event.p[0]; if ((p->tile.x == blahx) && (p->tile.y == blahy)) //blahs being x and y values of wormhole { sendPublic("Blah"); //command such as *spec } } |
so that once they went over the wormhole that was found in the lvl file, it would spec them. the TM Baw bot does this with coords in a .ini file, what i want is the bot to open a lvl and find the places automaticly, according to a predefined tile. So if it was keyed for a transparent tile, it would have an array of locations to check each time a player moved, once they were over the wormhole for example, it would spec them. My goal is to make a arena that all the ships cloak and you win by not getting repped into the wormhole.
Minegoboom= da man
50% Packetloss - Tue Oct 07, 2003 9:42 pm
Post subject:
LOL, exactly how does that work?
Code: Show/Hide struct tilerecord { unsigned int x : 12; unsigned int y : 12; unsigned int tile : 8; }; struct lvlheader { unsigned short type; /* should be 19778, aka 'B' followed by 'M' */ unsigned int lengh; }; //Simple enough, never seen :12/:8 before but assume they are the number of bits. struct tilerecord *tile = (struct tilerecord*)buff; struct lvlheader *header = (struct lvlheader*)buff; //declare some pointers, typecast them = to the char[6], never typecasted a char to a stuct i made before, but im sure it works //I learned fstream. in school so this stdio.h is new to me but looks about the same idea. if (fread(buff, 6, 1, f)) /* check to see if has bmp data up front */ { if (header->type == 19778) /* yep, has the string "BM" up front */ fseek(f, header->length, SEEK_SET); /* skip forward to end of BMP data */ else /* didn't have header up front, means should be tile info */ fseek(f, 0, SEEK_SET); /* rewind to front again */ } else /* couldn't read 6 bytes, which COULD mean a lvl with only 1 tile, or an empty file */ fseek(f, 0, SEEK_SET); //fread seems to be the same thing as read(), takes in 6 chars, pass it the file, EZ. now the confustion sets in, how did the var header get that info into it? I understand that it points to the char variable that now has the bmp header info in it but its like magic to me that the data hopped into the correct place in the struct variable while (fread(buff, 4, 1, f)) { if (tile->tile == 220) /* check to see if wormhole */ { cout << tile->x << ',' << tile->y; cout << endl; } } fclose(f); //then again its done with the variable tile, how exactly does it take a number such as 251 179 063 220 that would be in buff and magicly turn it into (1019,1019)? |
feel like i need to bitchslap myself, btw is finding the bmp header info as simple with fstream?
Mine GO BOOM - Tue Oct 07, 2003 11:18 pm
Post subject:
According to the standards for all BMP files, the header is static. The first two bytes (this is normal for almost all formats) tell what type of file you can expect. BM tells whatever is reading this that it is probably a BMP file. The next 4 bytes tell the FULL size of the bmp data, including the stuff you just read. Everything after that is all the extra bmp data you don't need to care about.
fstream, in my opinion, sucks MAJOR ass. It isn't as easy to control in detail as stdio. Plus, fstream won't work in C, which is common when you deal with C/C++ programs. (Note: ASSS is almost all C, and 0% C++)
You can typecast anything to anything else. You as the programmer just need to make sure you arn't typecasting something of length 10 to something of length 4, and assuming all 10 bytes are there. Thats how problems happen. Other languages like Java treat the programmer as a child, and checks these problems everytime for you, which is why it is much slower than C. But you actually have to try to fuck it up, where in C you don't have to, it will screw up for you.
Yes, in the structures, the : # tells the bits. You still can only allocate memory in byte size chunks, but you can read certain memory values with ease without having to &'d things. The #pragma pack()'ing tell the compiler to make SURE it doesn't add extra padding inside the structures. If you didn't, it might do some things such as putting data between values when you don't want to. You don't need to understand why or how, but just know that its in there for your safety.
The structures does all the dirty work for you, and if you want to think of it like this, decrypts that ugly ass number into sections. If you want to know more, play around with the data in binary. Actually write it out, and group the 12 and 8 bits, and check those values in there. How I learned how the endiness(sp?) works on x86 computers (PPC, aka Macs, do it opposite, whcih is why ASSS/SS isn't ported yet for that).
But let me warn you, what you are trying to do won't work. I know, I've figured it out before when applying physics to get the acceleration/distance formula for wormholes. Hmm.. now where did that paper go? I should make a FAQ for it.
50% Packetloss - Wed Oct 08, 2003 12:40 am
Post subject:
Makes perfect sence. i need to pick up a book on just C. If the warp thing doesnt work, i can always use a transparent tile to mark the postition and use a lvz file to place a fake wormhole over the area.
Peace
Mine GO BOOM - Wed Oct 08, 2003 11:26 am
Post subject:
Umm.. the client isn't reliable saying when its where, unless you do the physics and figure the in-between steps. I had the same problem when I made the first Warper bot, and you wanted to use a small warping area. Just make it a safety zone, and the client will make sure it sends that packet over (entering safety is an auto-position send, to tell other clients they can remove their weapons from the screen).
Plus you can narrow your position searching down greatly, since you only have to look first if the safety-flag is toggled before comparing positions.
50% Packetloss - Thu Oct 09, 2003 7:00 pm
Post subject:
Actually it worked out just fine, in some cases it doesnt spec when i go into the wormhole but ill attempt to fix that, the angle that i approach the wormhole seems to matter.
New problem is the map download, i need to open the LVL file after the bot has downloaded it, heres where i placed the function
Code: Show/Hide case EVENT_ArenaSettings: { settings = (arenaSettings*)event.p[0]; ReadLvlFile(); // Grabs wormholes from file, stores in array } |
Guess the bot calls that event before it downloads the map, if i have the bot exit and come back in, it works fine after that. Any ideas for how to tell that the bot is done d/l LVL file? could just use a timer. Also is there a way to get the arena name from the bot? so that i could concat that (arenaname here).lvl and it would good to go, ex strcat(what i need, ".lvl");
Mine GO BOOM - Thu Oct 09, 2003 8:43 pm
Post subject:
Depends upon which bot core you are using. I know in my core, which I long since stopped dealing with, I had a full event for when a file finished downloading, and a flag upon that saying if it was the arena map or not.
As for map name, the download packet should tell you that, but it matters which core you are using. You also get the map name in another 'entering arena' packet, which tells the map name and its checksum, so the core should know if to download map or not. Again, different for each core, with some not support it at all.
50% Packetloss - Thu Oct 09, 2003 10:50 pm
Post subject:
oh my bad, should post on the bot section anyway. Its mervbot. Just posting to get the ez answers so i dont have to dig through the source