Forum :: EOSERV :: Hiding tilespecs from player's clients?

matiasmunk posted: (15th Sep 2015, 03:22 pm)

What's so inconvenient about writing a small code that checks if the player does something on a certain tile on a certain map?

It's the exact same thing that Tilespecs does, except it reads the map first and checks if the player does it on a certain tile on the certain map.

Because this tilespec will be used frequently, in many parts of maps, and on large chunks of maps, and that is simply not well-suited for either a hardcoded option or a config option.

I'm writing a system, not a flavor-of-today feature that I'll never touch again after this.

---
Want to learn to pixel?
Pixelsource.org

I see.

When the tile specs are read, store a list of byte offsets that you want to re-write in the Map class, then look at the code in eoclient.cpp at line 75 (just noticed there's a copy-paste bug in there) which over-writes 3 bytes in the map file to enable PK (offset 3 to 0xFF, offset 4 to 0x01, etc.), and change it to also apply your list of byte changes.

Sausage posted: (16th Sep 2015, 02:44 am)

When the tile specs are read, store a list of byte offsets that you want to re-write in the Map class, then look at the code in eoclient.cpp at line 75 (just noticed there's a copy-paste bug in there) which over-writes 3 bytes in the map file to enable PK (offset 3 to 0xFF, offset 4 to 0x01, etc.), and change it to also apply your list of byte changes.

That makes sense to me and was the concept I was going for, I was just unsure of how to grab those byte offsets when reading the map, there's this SAFE_READ function that appears to be grabbing pairs of chars there.

Would you be willing to explain in slightly more detail about those byte offsets? My experience with the technical aspects of map files is a smidge limited and I find this interesting.

---
Want to learn to pixel?
Pixelsource.org

Cirras posted: (16th Sep 2015, 03:09 am)

Sausage posted: (16th Sep 2015, 02:44 am)

When the tile specs are read, store a list of byte offsets that you want to re-write in the Map class, then look at the code in eoclient.cpp at line 75 (just noticed there's a copy-paste bug in there) which over-writes 3 bytes in the map file to enable PK (offset 3 to 0xFF, offset 4 to 0x01, etc.), and change it to also apply your list of byte changes.

That makes sense to me and was the concept I was going for, I was just unsure of how to grab those byte offsets when reading the map, there's this SAFE_READ function that appears to be grabbing pairs of chars there.

Would you be willing to explain in slightly more detail about those byte offsets? My experience with the technical aspects of map files is a smidge limited and I find this interesting.

You'll want to use fgetpos to get the current file position (before the read on line 510 of map.cpp), add 1 to it, and you have the offset of the tile spec value for the current tile spec being read.

Sausage posted: (16th Sep 2015, 03:44 am)

Cirras posted: (16th Sep 2015, 03:09 am)

Sausage posted: (16th Sep 2015, 02:44 am)

When the tile specs are read, store a list of byte offsets that you want to re-write in the Map class, then look at the code in eoclient.cpp at line 75 (just noticed there's a copy-paste bug in there) which over-writes 3 bytes in the map file to enable PK (offset 3 to 0xFF, offset 4 to 0x01, etc.), and change it to also apply your list of byte changes.

That makes sense to me and was the concept I was going for, I was just unsure of how to grab those byte offsets when reading the map, there's this SAFE_READ function that appears to be grabbing pairs of chars there.

Would you be willing to explain in slightly more detail about those byte offsets? My experience with the technical aspects of map files is a smidge limited and I find this interesting.

You'll want to use fgetpos to get the current file position (before the read on line 510 of map.cpp), add 1 to it, and you have the offset of the tile spec value for the current tile spec being read.

Given that I'm presently working off of an old revision (D-don't judge me, plans are currently in the works for a conversion to a modern revision - (Actually, you can judge me)), this is what I'm looking at based off of that.

---

 

                    do {

                        char buf[4096];

                        int len = std::fread(buf, sizeof(char), 4096, fh);

                        if (this->server->world->config["GlobalPK"] && !this->server->world->PKExcept(this->player->character->mapid))

                        {

                            if (p + len >= 0x04 && 0x03 - p > 0) buf[0x03 - p] = 0xFF;

                            if (p + len >= 0x05 && 0x04 - p > 0) buf[0x04 - p] = 0x01;

                            if (p + len >= 0x20 && 0x1F - p > 0) buf[0x1F - p] = 0x04;

                        }

                           //The loop below is the added code.
                           for (int i = 0; i < this->stored_byte_offsets.size(); ++i)

                           {
                                   if (p + len ==this->stored_byte_offsets[i]) buf[this->stored_byte_offsets[i] - p] = -1;
                            }

                        p += len;

                        content.append(buf, len);

                    } while (!std::feof(fh));

---

Now of course, in my head this makes some degree of sense, in that I'm finding the byte offsets for the tilespecs I'm choosing to hide and changing them to -1 for TileSpec::None.

But something tells me that this isn't so simple and that really, this amounts to little more to pseudocode at the moment.

---
Want to learn to pixel?
Pixelsource.org

Cirras posted: (16th Sep 2015, 04:08 am)

Sausage posted: (16th Sep 2015, 03:44 am)

Cirras posted: (16th Sep 2015, 03:09 am)

Sausage posted: (16th Sep 2015, 02:44 am)

When the tile specs are read, store a list of byte offsets that you want to re-write in the Map class, then look at the code in eoclient.cpp at line 75 (just noticed there's a copy-paste bug in there) which over-writes 3 bytes in the map file to enable PK (offset 3 to 0xFF, offset 4 to 0x01, etc.), and change it to also apply your list of byte changes.

That makes sense to me and was the concept I was going for, I was just unsure of how to grab those byte offsets when reading the map, there's this SAFE_READ function that appears to be grabbing pairs of chars there.

Would you be willing to explain in slightly more detail about those byte offsets? My experience with the technical aspects of map files is a smidge limited and I find this interesting.

You'll want to use fgetpos to get the current file position (before the read on line 510 of map.cpp), add 1 to it, and you have the offset of the tile spec value for the current tile spec being read.

Given that I'm presently working off of an old revision (D-don't judge me, plans are currently in the works for a conversion to a modern revision - (Actually, you can judge me)), this is what I'm looking at based off of that.

---

 

                    do {

                        char buf[4096];

                        int len = std::fread(buf, sizeof(char), 4096, fh);

                        if (this->server->world->config["GlobalPK"] && !this->server->world->PKExcept(this->player->character->mapid))

                        {

                            if (p + len >= 0x04 && 0x03 - p > 0) buf[0x03 - p] = 0xFF;

                            if (p + len >= 0x05 && 0x04 - p > 0) buf[0x04 - p] = 0x01;

                            if (p + len >= 0x20 && 0x1F - p > 0) buf[0x1F - p] = 0x04;

                        }

                           //The loop below is the added code.
                           for (int i = 0; i < this->stored_byte_offsets.size(); ++i)

                           {
                                   if (p + len ==this->stored_byte_offsets[i]) buf[this->stored_byte_offsets[i] - p] = -1;
                            }

                        p += len;

                        content.append(buf, len);

                    } while (!std::feof(fh));

---

Now of course, in my head this makes some degree of sense, in that I'm finding the byte offsets for the tilespecs I'm choosing to hide and changing them to -1 for TileSpec::None.

But something tells me that this isn't so simple and that really, this amounts to little more to pseudocode at the moment.

That looks correct in theory (except it would be more like player->character->map->stored_byte_offsets), however, there is no actual TileSpec value of -1 (bytes in the file range from 0 to 255), that's just the value used internally in EOSERV when none is present in the file.

You might want to replace it with the byte value of NPCBoundary instead (which would be 18, or 0x12) which doesn't show up in any special way in the official client.

Sausage posted: (16th Sep 2015, 05:49 am)

Cirras posted: (16th Sep 2015, 04:08 am)

Sausage posted: (16th Sep 2015, 03:44 am)

Cirras posted: (16th Sep 2015, 03:09 am)

Sausage posted: (16th Sep 2015, 02:44 am)

When the tile specs are read, store a list of byte offsets that you want to re-write in the Map class, then look at the code in eoclient.cpp at line 75 (just noticed there's a copy-paste bug in there) which over-writes 3 bytes in the map file to enable PK (offset 3 to 0xFF, offset 4 to 0x01, etc.), and change it to also apply your list of byte changes.

That makes sense to me and was the concept I was going for, I was just unsure of how to grab those byte offsets when reading the map, there's this SAFE_READ function that appears to be grabbing pairs of chars there.

Would you be willing to explain in slightly more detail about those byte offsets? My experience with the technical aspects of map files is a smidge limited and I find this interesting.

You'll want to use fgetpos to get the current file position (before the read on line 510 of map.cpp), add 1 to it, and you have the offset of the tile spec value for the current tile spec being read.

Given that I'm presently working off of an old revision (D-don't judge me, plans are currently in the works for a conversion to a modern revision - (Actually, you can judge me)), this is what I'm looking at based off of that.

---

 

                    do {

                        char buf[4096];

                        int len = std::fread(buf, sizeof(char), 4096, fh);

                        if (this->server->world->config["GlobalPK"] && !this->server->world->PKExcept(this->player->character->mapid))

                        {

                            if (p + len >= 0x04 && 0x03 - p > 0) buf[0x03 - p] = 0xFF;

                            if (p + len >= 0x05 && 0x04 - p > 0) buf[0x04 - p] = 0x01;

                            if (p + len >= 0x20 && 0x1F - p > 0) buf[0x1F - p] = 0x04;

                        }

                           //The loop below is the added code.
                           for (int i = 0; i < this->stored_byte_offsets.size(); ++i)

                           {
                                   if (p + len ==this->stored_byte_offsets[i]) buf[this->stored_byte_offsets[i] - p] = -1;
                            }

                        p += len;

                        content.append(buf, len);

                    } while (!std::feof(fh));

---

Now of course, in my head this makes some degree of sense, in that I'm finding the byte offsets for the tilespecs I'm choosing to hide and changing them to -1 for TileSpec::None.

But something tells me that this isn't so simple and that really, this amounts to little more to pseudocode at the moment.

That looks correct in theory (except it would be more like player->character->map->stored_byte_offsets), however, there is no actual TileSpec value of -1 (bytes in the file range from 0 to 255), that's just the value used internally in EOSERV when none is present in the file.

You might want to replace it with the byte value of NPCBoundary instead (which would be 18, or 0x12) which doesn't show up in any special way in the official client.

Awesome - I'll give it a try after I've finished some minor restructure of the project and let you know how it goes. Thanks!

---
Want to learn to pixel?
Pixelsource.org

open gfx 2 using your resource hacker and simply blacken the question mark part. mhm it may also hide mining / fishing / woodcutting etc icon from the mini map.

---
Extending one hand for helping is important than holding two hands for prayer.
~ Cloud ~

ayush posted: (16th Sep 2015, 04:12 pm)

open gfx 2 using your resource hacker and simply blacken the question mark part. mhm it may also hide mining / fishing / woodcutting etc icon from the mini map.

Wow, nice solution.. Crazy that none of that came up with this hehe.

ayush posted: (16th Sep 2015, 04:12 pm)

open gfx 2 using your resource hacker and simply blacken the question mark part. mhm it may also hide mining / fishing / woodcutting etc icon from the mini map.

I believe this is the same GFX as boards and some other things, I'd prefer not to remove those from the map. Good idea with approaching it graphically, though.

---
Want to learn to pixel?
Pixelsource.org

Might be worth checking if the client has a player and if the player is an admin before removing the bytes, seems like something that might cause hassle if it can only be seen in editors.

callum posted: (16th Sep 2015, 10:55 pm)

Might be worth checking if the client has a player and if the player is an admin before removing the bytes, seems like something that might cause hassle if it can only be seen in editors.

Well, technically by removing the bytes, they can't be seen in editors or anything, since the file they're getting is modified. However, in my mind that wouldn't be a problem since mappers would be working with the original (serverside) map file that still has the tiles on it.

---
Want to learn to pixel?
Pixelsource.org

Cirras posted: (16th Sep 2015, 05:46 pm)

ayush posted: (16th Sep 2015, 04:12 pm)

open gfx 2 using your resource hacker and simply blacken the question mark part. mhm it may also hide mining / fishing / woodcutting etc icon from the mini map.

I believe this is the same GFX as boards and some other things, I'd prefer not to remove those from the map. Good idea with approaching it graphically, though.

ah right, i didnt think about boards and chairs lol

---
Extending one hand for helping is important than holding two hands for prayer.
~ Cloud ~

Cirras posted: (17th Sep 2015, 05:37 am)

callum posted: (16th Sep 2015, 10:55 pm)

Might be worth checking if the client has a player and if the player is an admin before removing the bytes, seems like something that might cause hassle if it can only be seen in editors.

Well, technically by removing the bytes, they can't be seen in editors or anything, since the file they're getting is modified. However, in my mind that wouldn't be a problem since mappers would be working with the original (serverside) map file that still has the tiles on it.

I think you miss understood what I meant, I meant it as in; If you're planning some sort of system using hidden tiles, why make it so it can only be seen outside of the game?

''Might be worth checking if the client has a player and if the player is an admin before removing the bytes, " Admins would be sent the original map, would save time sending out the maps to the admins who need them (multiple mappers).

I think I should have said it differently, I meant it like.. What if something went wrong with the system and your admins couldn't see that there was a tile system in place, it would just cause confusion. Also then only a mapper or level 5 would be able to see that there's a system in place and shed some light on the problem. If all trusty admins were able to see the original maps then I'm sure there's at least 1-2 admins who'd have the sense to check the file.

I might be way off point with this, if I am I apologise, but it just seems more practical to be able to work with this in-game too. Save the hassle of reloading maps every time.