Has Terrain Data Changed? menu

User Tag List

Results 1 to 9 of 9
  1. #1
    natemiddleman's Avatar Member
    Reputation
    3
    Join Date
    Jun 2020
    Posts
    28
    Thanks G/R
    0/2
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Has Terrain Data Changed?

    I have finally gotten around to looking into terrain data and I have run into a problem. Both ExileApi and PoEapi - AHK agree that the following are the terrain offsets

    Terrain = 0x670

    cols = 0x18
    rows = 0x20
    melee_layer = 0xb0
    ranged_layer = 0xc8
    bytes_per_row = 0xe0

    But when I look at 0x670 I see this. I see a struct size of 0x38 and 0x08 points to a native pointer that contains 23x23 blocks of what looks like terrain data. No matter where I look though, I don't see anything matching the above offsets.

    Capture.PNG

    These ads disappear when you log in.

  2. #2
    pushedx's Avatar Contributor
    Reputation
    234
    Join Date
    Nov 2009
    Posts
    128
    Thanks G/R
    5/112
    Trade Feedback
    0 (0%)
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    Terrain data itself hasn't changed recently as far as I'm aware. The last big update was 3.13 itself, but only a few pointers moved around, the terrain system itself is still the same as before.

    Your issue seems just like a case of using the wrong base address to access stuff.

    I have a post here that might help you figure out what you're doing wrong. The offsets are different now, but the idea is still the same: mmo...ml#post4201469

    From that thread:
    - LocalData = now the pointer at "InGameState + 0x30" rather than "InGameState + 0x378"
    - TerrainData = now the struct at "LocalData + 0x648" rather than "LocalData + 0x610 "

    The offsets I've listed are still the same assuming you use the right TerrainData base. If you use a different base, like ExileApi does, your offsets will be shifted.

    Make sure you don't run into the same issue as this poster did due to the difference in offsets: mmo...ml#post4281361

    I have a response to that later in the thread here: https://www.ownedcore.com/forums/mmo...ml#post4281388

  3. #3
    natemiddleman's Avatar Member
    Reputation
    3
    Join Date
    Jun 2020
    Posts
    28
    Thanks G/R
    0/2
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Thanks. It didn't take me long to figure out once I read your reply. One more question though. World position indicates the column width is four times bigger than bytes per row instead of the two I was expecting. Is each column doubled or am I doing something wrong?

  4. #4
    pushedx's Avatar Contributor
    Reputation
    234
    Join Date
    Nov 2009
    Posts
    128
    Thanks G/R
    5/112
    Trade Feedback
    0 (0%)
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    Column data is packed in memory, so you have 2 horizontal values (x-axis) being stored per byte. There's no way to vertically pack an integer this way naturally , so you each byte value represents the vertical value (y-axis)

    So for example, if the terrain was 4x4:

    0 1 1 0
    0 1 1 0
    0 1 1 0
    0 1 1 0

    You don't need 16 bytes, since you can pack it into 8 bytes instead:

    01 10
    01 10
    01 10
    01 10

    This is because each nibble (Nibble - Wikipedia) can represent 16 values (0 - F) and only 6 total values are being used in game (0 - 5)

    In C/C++, 2d arrays are stored as a 1d-contiguous array in memory, so BytesPerRow just helps simplify the math required for when you have an odd or even number of columns due to the packing

    If you had an odd column value, you'd have 1 unused nibble in the last position, and if you had an even column value, all values would be used

    It's much easier to "waste" the extra unused nibble than have to use extra operations and math to fully pack the data into an unaligned array and access it properly each time, but that's just my speculation about it

    In addition, for possible math related optimizations, it could be possible terrain data needs to be aligned to some higher multiple, say 16 bytes for floating point operations, to which you could introduce more "padding bytes" with the BytesPerRow design and not affect anything. This could be due to the runtime terrain data modification that gets done from certain objects or triggerable blockages. Remember the server has to do the same math, and the server handles a lot more than just the client so the design might have originated from optimizations needed on that side

  5. #5
    natemiddleman's Avatar Member
    Reputation
    3
    Join Date
    Jun 2020
    Posts
    28
    Thanks G/R
    0/2
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I understand the first part. Lioneye's Watch has 345 bytes per row so the grid should be 690 (30 * 23) columns wide. My concern is that when I compare my result with the example you gave previously it looks like Attachment 76897 with my result on the right. My grid is 690 wide, but yours has twice the definition which would match up with the player world position.

  6. #6
    pushedx's Avatar Contributor
    Reputation
    234
    Join Date
    Nov 2009
    Posts
    128
    Thanks G/R
    5/112
    Trade Feedback
    0 (0%)
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by natemiddleman View Post
    I understand the first part. Lioneye's Watch has 345 bytes per row so the grid should be 690 (30 * 23) columns wide. My concern is that when I compare my result with the example you gave previously it looks like Attachment 76897 with my result on the right. My grid is 690 wide, but yours has twice the definition which would match up with the player world position.
    Seems your attachment isn't viewable, I get a message: "Invalid Attachment specified. If you followed a valid link, please notify the administrator"

  7. #7
    natemiddleman's Avatar Member
    Reputation
    3
    Join Date
    Jun 2020
    Posts
    28
    Thanks G/R
    0/2
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Weird. I can view it just fine. Try this Imgur: The magic of the Internet
    Attached Thumbnails Attached Thumbnails Has Terrain Data Changed?-capture-png  

  8. #8
    pushedx's Avatar Contributor
    Reputation
    234
    Join Date
    Nov 2009
    Posts
    128
    Thanks G/R
    5/112
    Trade Feedback
    0 (0%)
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    Yes, the right side result is certainly incorrect as it looks like you're skipping over some data

    Your loops to build the terrain should be something like this (where TileCellSizeI = 23)

    Code:
    for (var tileRow = 0; tileRow < tileRows; ++tileRow)
    {
    	for (var tileCol = 0; tileCol < tileCols; ++tileCol)
    	{
    		for (var tileY = 0; tileY < TileCellSizeI; ++tileY)
    		{
    			for (var tileX = 0; tileX < TileCellSizeI; ++tileX)
    			{
    				var val = WalkableValueFor(meleeTerrainData, bpr, tileX + tileCol * TileCellSizeI, tileY + tileRow * TileCellSizeI);
    			}
    		}
    	}
    }
    I'd double check all your code to make sure you've not mixed up rows/cols or x/y or used rows/rows or cols/cols, etc... I've done similar so that's why I've mentioned it as when I first did this stuff in 2012, I ran into the same issue and was only using 1/2 the data and had results like you posted

  9. #9
    natemiddleman's Avatar Member
    Reputation
    3
    Join Date
    Jun 2020
    Posts
    28
    Thanks G/R
    0/2
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Thanks. Found it.

    Code:
    for (int i = 0; i < size; i++)
    {
       int x = rows - (i / bytesPerRow) - 1;
       int y = i % bytesPerRow;
       terrain[x, y] = meleeLayer[i] & 0xF;
       terrain[x, y + 1] = meleeLayer[i] >> 4 & 0xF; 
    }
    Should be

    Code:
    for (int i = 0; i < size; i++)
    {
       int x = rows - (i / bytesPerRow) - 1;
       int y = i % bytesPerRow;
       terrain[x, (y * 2)] = meleeLayer[i] & 0xF;
       terrain[x, (y * 2) + 1] = meleeLayer[i] >> 4 & 0xF;
    }

Similar Threads

  1. With a new beta has come new changes
    By Kenneth in forum Overwatch Chat
    Replies: 1
    Last Post: 02-09-2016, 11:18 PM
  2. With a new beta has come new changes
    By Kenneth in forum Overwatch Exploits|Hacks
    Replies: 1
    Last Post: 02-09-2016, 11:18 PM
  3. Has the Beta Changed Your Opinion?
    By Duplicity in forum Star Wars: The Old Republic
    Replies: 3
    Last Post: 11-14-2011, 11:59 PM
  4. I cant change data !! can u help me plz
    By kelanthang998 in forum World of Warcraft Emulator Servers
    Replies: 0
    Last Post: 09-10-2007, 06:06 AM
  5. Regarding Terrain changing .mpq files
    By Lunarain in forum WoW ME Questions and Requests
    Replies: 0
    Last Post: 07-06-2007, 02:46 PM
All times are GMT -5. The time now is 04:55 PM. Powered by vBulletin® Version 4.2.3
Copyright © 2021 vBulletin Solutions, Inc. All rights reserved. User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Digital Point modules: Sphinx-based search