- Site Map >
- Modding and Creation >
- Sims 3 Creation >
- Create a World >
- Research - Water Levels from Twinbrook and Bridgeport
- Site Map >
- Modding and Creation >
- Sims 3 Creation >
- Create a World >
- Research - Water Levels from Twinbrook and Bridgeport
#76
15th Aug 2011 at 11:08 PM
Posts: 88
Quote: Originally posted by SandrineD
Well you can definitely move them... Circled in red and another circle where it came from. #1 has moved north to join three others. it didn't involve the four slots that appear to define the corners but there is more because it renders wrong and disappears if you zoom in too close. So the other numbers must relate to render "windows". |
(Incidentally, when I created a new world to test something out, I discovered that the 0x90624C1B resource was already in the world; I hadn't needed to add it with s3pe, so perhaps it's not specific to the water planes but more of a general resource.)
If the rendering issue can be solved, I might just have to go back and tweak my world-in-progress by raising the rivers (fortunately, I won't have to do any more terrain painting!)...
Advertisement
#77
15th Aug 2011 at 11:46 PM
Posts: 82
I used a very nice program called HxD it makes cut and paste very easy and I do all kind of non-std things with programs that were never designed to do that.
the 906 doesn't determine position. I experimented using Bridgeport 906 and twinbridge 707's and vice versa. I feel sure all positioning is from 707's.
also the 906 clearly is related as it says how many 707's are used. Even with six 707's in the world file, if you change that byte to 05 it will only show 5 water planes.
what I've found definitely renders the texture of the WP and does it in parts somehow 48 in the case of the smallest one eg WP#1 or WP#3. Other variable obviously effect view windows or whatever you want to call them. eg - the 4 bytes near the start that set the two corners. Also many other unknowns. Also haven't worked out the precise measurements used, so I move it but without the precision I demand.
ps in that 906 in your new world what was the value of byte 12?
the 906 doesn't determine position. I experimented using Bridgeport 906 and twinbridge 707's and vice versa. I feel sure all positioning is from 707's.
also the 906 clearly is related as it says how many 707's are used. Even with six 707's in the world file, if you change that byte to 05 it will only show 5 water planes.
what I've found definitely renders the texture of the WP and does it in parts somehow 48 in the case of the smallest one eg WP#1 or WP#3. Other variable obviously effect view windows or whatever you want to call them. eg - the 4 bytes near the start that set the two corners. Also many other unknowns. Also haven't worked out the precise measurements used, so I move it but without the precision I demand.
ps in that 906 in your new world what was the value of byte 12?
#78
17th Aug 2011 at 2:32 AM
Posts: 88
Quote: Originally posted by SandrineD
I used a very nice program called HxD it makes cut and paste very easy and I do all kind of non-std things with programs that were never designed to do that. |
Quote: Originally posted by SandrineD
the 906 doesn't determine position. I experimented using Bridgeport 906 and twinbridge 707's and vice versa. I feel sure all positioning is from 707's. also the 906 clearly is related as it says how many 707's are used. Even with six 707's in the world file, if you change that byte to 05 it will only show 5 water planes. |
Quote: Originally posted by SandrineD
what I've found definitely renders the texture of the WP and does it in parts somehow 48 in the case of the smallest one eg WP#1 or WP#3. Other variable obviously effect view windows or whatever you want to call them. eg - the 4 bytes near the start that set the two corners. Also many other unknowns. Also haven't worked out the precise measurements used, so I move it but without the precision I demand. |
As for the textures - maybe they're multi-tile textures instead of single tile textures, so the 48 parts of the two small water planes could represent a rectangle that's six texture units deep by eight texture units wide. So if the water texture is an 8 tile x 8 tile unit, then the water plane would be 48 tiles deep by 64 tiles wide. (Just a thought off the top of my head - probably not correct, but who knows!)
Quote: Originally posted by SandrineD
ps in that 906 in your new world what was the value of byte 12? |
#79
17th Aug 2011 at 8:45 AM
Posts: 82
Don't worry I checked myself. The 906 also specifies map size so it has to be there. On a default the 12th byte is 00 as there are no additional Water Planes.
#80
17th Aug 2011 at 1:14 PM
Quote: Originally posted by buxcosim
Hmm, I wonder if when simsample edited the corner coordinates, it only moved the view window but left the actual water plane in the original spot - hence the hole in the terrain since the view window and the water plane didn't match. |
Yes, that sounds likely. I didn't play with it for very long, so didn't get as far as SandrineD! :D
Quote: Originally posted by SandrineD
Don't worry I checked myself. The 906 also specifies map size so it has to be there. On a default the 12th byte is 00 as there are no additional Water Planes. |
That's not all that there is to map size though, as unfortunately importing UNKN 0x90624C1B from a large world into a small world does not change its size!
Great progress, SandrineD! Thanks all for contributing to this thread, it is most interesting!
I will choose a path that's clear- I will choose free will
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
#81
17th Aug 2011 at 9:49 PM
Posts: 82
Spending way too much time on these sidetracks really
I should be focused on my real projects.
However, I have an insatiable curiosity and it has been piqued!
sifted through a few files and earmarked the ones that look like possibilities mostly based upon having 08 in large and 01 in tiny worlds and other things that appear similar.
These texture things are definitely tiled.
See below the final result after loading around 7 files including the 906 thing from before.
This started as a tiny map and the four small pyramids were placed at the corners. Now we see the possible ground extends 8 times more in both directions, far off the view edges.
Just not sure yet, which of the 7 are compulsory!?
I should be focused on my real projects.
However, I have an insatiable curiosity and it has been piqued!
sifted through a few files and earmarked the ones that look like possibilities mostly based upon having 08 in large and 01 in tiny worlds and other things that appear similar.
These texture things are definitely tiled.
See below the final result after loading around 7 files including the 906 thing from before.
This started as a tiny map and the four small pyramids were placed at the corners. Now we see the possible ground extends 8 times more in both directions, far off the view edges.
Just not sure yet, which of the 7 are compulsory!?
#82
17th Aug 2011 at 11:53 PM
Excellent! You made a small world large! :D
You could find out which resources are compulsory by removing them one by one, and testing each time.
You could find out which resources are compulsory by removing them one by one, and testing each time.
I will choose a path that's clear- I will choose free will
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
#83
18th Aug 2011 at 12:53 AM
Posts: 88
Quote: Originally posted by SandrineD
Don't worry I checked myself. The 906 also specifies map size so it has to be there. On a default the 12th byte is 00 as there are no additional Water Planes. |
Quote: Originally posted by SandrineD
sifted through a few files and earmarked the ones that look like possibilities mostly based upon having 08 in large and 01 in tiny worlds and other things that appear similar. |
Quote: Originally posted by SandrineD
These texture things are definitely tiled. |
Looking at simsample's size data, the sizes of all but one of Bridgeport's water planes are multiples of 8, so maybe the tile size for the water plane is 8 squares x 8 squares. (If the corner coordinates represent the viewing window and not the water plane itself, then the one plane that isn't a whole number multiple of 8 could just mean that its viewing window is smaller than the plane.)
Again, just some thoughts, probably off base, but who knows!
Great progress on this! I just wish I spoke hex, so I could help test some of these things myself. (Sometimes I think that people use hex just to be difficult...)
#84
18th Aug 2011 at 1:11 AM
Posts: 82
people use hex because computers like it.Well really they like binary but thats worse. Besides thats why 8 bits make a byte and 2PWR8=256 which is also 16sqrd. Thats why you get all those pairs ranging from 00 to FF.
Now back to the matter... my wish is also to make a bigger map.
Maybe its possible, but even if it worked just by changing these files it would be a lot of work bec of how they are structured. Plus the program appears to have a trap in it that stops you loading a height file greater than 2048x2048. For me that would render the point moot if I can't fix it... but then, thats an assumption!
Maybe I'll look into it!?
Now back to the matter... my wish is also to make a bigger map.
Maybe its possible, but even if it worked just by changing these files it would be a lot of work bec of how they are structured. Plus the program appears to have a trap in it that stops you loading a height file greater than 2048x2048. For me that would render the point moot if I can't fix it... but then, thats an assumption!
Maybe I'll look into it!?
#85
18th Aug 2011 at 8:54 AM
buxcosim, I think you have it exactly right, as if you look at the resources in a world file you'll see many of them are addressing a single chunk.
SandrineD, perhaps you could let us know which resources you imported to change the world size and what you edited to move the water levels? That way, others could test for you and we could make a little tutorial. Great work, although I think you're being very ambitious to attempt to change the maximum world size, I don't think that will be possible. Worth looking at, though!
SandrineD, perhaps you could let us know which resources you imported to change the world size and what you edited to move the water levels? That way, others could test for you and we could make a little tutorial. Great work, although I think you're being very ambitious to attempt to change the maximum world size, I don't think that will be possible. Worth looking at, though!
I will choose a path that's clear- I will choose free will
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
#86
18th Aug 2011 at 9:27 AM
Posts: 82
Agreed, we will probably not be able to change the max size, but definitely worth looking. I'm trying to get my friend to look into it if he ever has time since he has in the past done things like that, finding things people said would never be found.
The files:
As well the one we were looking at before... S3_90624C1B_00000000_0000000000000001%%+UNKN.bnry which frankly only seems to change the 'first viewing position' when you open a world in CAW.
These files all looked like they had the right 'patterns'
S3_2AD195F2_00000000_0000000000000001%%+UNKN.bnry
S3_3D8632D0_00000000_0000000000000001%%+UNKN.bnry
S3_05CD4BB3_00000000_0000000000000001%%+UNKN.bnry
S3_06DC847E_00000000_0000000000000001%%+UNKN.bnry
S3_044735DD_00000000_0000000000000001%%+UNKN.bnry
S3_9063660D_00000000_0000000000000001%%+WTXT.wrldtxtrmap
Files like the BB3 one will be really annoying as it lays out the 64 tiles [256x256] needed for the 2048x2048 world and a section for each [256bytes].
So if you wanted a 4096x4096, you'd have to generate 256 tiles.
It might come down to a case of being able to make it but it still wont load in CAW!?
Who knows.
The files:
As well the one we were looking at before... S3_90624C1B_00000000_0000000000000001%%+UNKN.bnry which frankly only seems to change the 'first viewing position' when you open a world in CAW.
These files all looked like they had the right 'patterns'
S3_2AD195F2_00000000_0000000000000001%%+UNKN.bnry
S3_3D8632D0_00000000_0000000000000001%%+UNKN.bnry
S3_05CD4BB3_00000000_0000000000000001%%+UNKN.bnry
S3_06DC847E_00000000_0000000000000001%%+UNKN.bnry
S3_044735DD_00000000_0000000000000001%%+UNKN.bnry
S3_9063660D_00000000_0000000000000001%%+WTXT.wrldtxtrmap
Files like the BB3 one will be really annoying as it lays out the 64 tiles [256x256] needed for the 2048x2048 world and a section for each [256bytes].
So if you wanted a 4096x4096, you'd have to generate 256 tiles.
It might come down to a case of being able to make it but it still wont load in CAW!?
Who knows.
#87
19th Aug 2011 at 3:24 AM
Posts: 88
Quote: Originally posted by SandrineD
people use hex because computers like it.Well really they like binary but thats worse. Besides thats why 8 bits make a byte and 2PWR8=256 which is also 16sqrd. Thats why you get all those pairs ranging from 00 to FF. |
Quote: Originally posted by SandrineD
Now back to the matter... my wish is also to make a bigger map. Maybe its possible, but even if it worked just by changing these files it would be a lot of work bec of how they are structured. Plus the program appears to have a trap in it that stops you loading a height file greater than 2048x2048. For me that would render the point moot if I can't fix it... but then, thats an assumption! |
Quote: Originally posted by simsample
buxcosim, I think you have it exactly right, as if you look at the resources in a world file you'll see many of them are addressing a single chunk. |
Quote: Originally posted by SandrineD
Files like the BB3 one will be really annoying as it lays out the 64 tiles [256x256] needed for the 2048x2048 world and a section for each [256bytes]. So if you wanted a 4096x4096, you'd have to generate 256 tiles. It might come down to a case of being able to make it but it still wont load in CAW!? |
#88
19th Aug 2011 at 7:10 AM
Posts: 82
I suppose programs for general release have to have safeguards or EA would be even more swamped with complaints.
Its like the people who say they want to have realistic moving hair but expect to run it on a standard computer
ps - I think you'd need a render farm for that!
That's not a maybe, its definitely in tiles or chunks [as you say].
Its even noted in one of the EA documents that tiling takes place and the size is 256x256.
In my last experiment I didn't edit all the files, the ones like BB3 I copied over from a base world of a larger size.
This was just to prove that it worked and to identify which files did it!
If you can use S3PE [not at all hard] you can do some experiments.
.. and don't forget to report back here!
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Its like the people who say they want to have realistic moving hair but expect to run it on a standard computer
ps - I think you'd need a render farm for that!
That's not a maybe, its definitely in tiles or chunks [as you say].
Its even noted in one of the EA documents that tiling takes place and the size is 256x256.
In my last experiment I didn't edit all the files, the ones like BB3 I copied over from a base world of a larger size.
This was just to prove that it worked and to identify which files did it!
If you can use S3PE [not at all hard] you can do some experiments.
.. and don't forget to report back here!
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#89
19th Aug 2011 at 9:09 AM
Posts: 85
Thanks: 22 in 1 Posts
I'm working a world that I would love to have more then one plane of water in it. So I used a hex editer to try and figure out the 707 files and this is what I have came up with:
https://docs.google.com/a/zaidesthi...d=1&output=html
It's not much but maybe it will help someone.
The files have 2 parts that repeat a number of times depending on the DWORD before them. Can't figure out what they are storing maybe someone else can. There is also what looks like a random number of DWORDs with low values at the end of each file that I haven't even tried figuring out.
https://docs.google.com/a/zaidesthi...d=1&output=html
It's not much but maybe it will help someone.
The files have 2 parts that repeat a number of times depending on the DWORD before them. Can't figure out what they are storing maybe someone else can. There is also what looks like a random number of DWORDs with low values at the end of each file that I haven't even tried figuring out.
#90
19th Aug 2011 at 11:13 AM
Posts: 82
Yeah that pretty much agrees with what I've found so far except to note what I've said above.
Y? - you can remove the ? its definitely the altitude of the plane.
The indexes as you call them indicate the number of blocks following of 11 and 39 bytes respectively.
The number of blocks in the first group appear to be the render chunks and are proportional to the size of the water plane area.
The second group appears similar, perhaps render at a diff LOD???
Did you notice the 2nd index is always 1/12 of the first index?
The random data, as you put it, at the end is something like a list of indexes.
The interesting thing is that the size of the range of values is equal to index2 or the number of data sets in the 2nd data block.
eg - #1 the values range from 0-3 and the 2nd index is 4.
It appears that these files are more about rendering than positioning although the alt is determined in here. But, then, from a certain perspective you could think of that as part of the rendering issue.
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Y? - you can remove the ? its definitely the altitude of the plane.
The indexes as you call them indicate the number of blocks following of 11 and 39 bytes respectively.
The number of blocks in the first group appear to be the render chunks and are proportional to the size of the water plane area.
The second group appears similar, perhaps render at a diff LOD???
Did you notice the 2nd index is always 1/12 of the first index?
The random data, as you put it, at the end is something like a list of indexes.
The interesting thing is that the size of the range of values is equal to index2 or the number of data sets in the 2nd data block.
eg - #1 the values range from 0-3 and the 2nd index is 4.
It appears that these files are more about rendering than positioning although the alt is determined in here. But, then, from a certain perspective you could think of that as part of the rendering issue.
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
#91
20th Aug 2011 at 2:52 AM
Posts: 88
Quote: Originally posted by SandrineD
I suppose programs for general release have to have safeguards or EA would be even more swamped with complaints. |
Quote: Originally posted by SandrineD
That's not a maybe, its definitely in tiles or chunks [as you say]. Its even noted in one of the EA documents that tiling takes place and the size is 256x256. |
Quote: Originally posted by SandrineD
In my last experiment I didn't edit all the files, the ones like BB3 I copied over from a base world of a larger size. This was just to prove that it worked and to identify which files did it! |
Quote: Originally posted by SandrineD
If you can use S3PE [not at all hard] you can do some experiments. .. and don't forget to report back here! |
Quote: Originally posted by SandrineD
It appears that these files are more about rendering than positioning although the alt is determined in here. But, then, from a certain perspective you could think of that as part of the rendering issue. |
On second thought, maybe a hex-to-decimal converter might be a better option for me...
Lab Assistant
#92
20th Aug 2011 at 7:31 AM
Last edited by zaide_chris : 20th Aug 2011 at 11:31 AM.
Posts: 85
Thanks: 22 in 1 Posts
OK the number of blocks in the first group is FLOOR(X/32)*FLOOR(Z/32)*12
and number of blocks in the second group is FLOOR(X/32)*FLOOR(Z/32)
For the blocks in the first group
WORD: BLOCK1X divide by 4 to get cord in the same units as X1,X2
WORD: BLOCK1Z divide by 4 to get cord in the same units as Z1,Z2
DWORD: i think this is a floating point number = to 0? have no clue for all the bp files it is allways bc7f0400 but in tb it's 9e430400 or bc7f0400- note tb's water plane is much larger
BYTEs 9-11: Allways 80ff80
Going to start looking at the second group now.
Edit:
For the blocks in second group
DWORD: BLOCK2X1 floating point number in the same units as X1,X2
DWORD: BLOCK2Z1 floating point number in the same units as Z1,Z2
DWORD: BLOCK2X2 floating point number in the same units as X1,X2
DWORD: BLOCK2Z2 floating point number in the same units as Z1,Z2
BYTEs 17-39: Allways 01010000000000ffffffffffff
Edit:
and heres the top part
WORD: Allways 0500
DWORD: Y floating point number
DWORD: X1
DWORD: Z1
DWORD: X2
DWORD: Z2
DWORD: XA floating point number
DWORD: ZA floating point number
DWORD: Allways 03000000
it's all together at
https://docs.google.com/a/zaidesthi...ut=html&ndplr=1
and number of blocks in the second group is FLOOR(X/32)*FLOOR(Z/32)
For the blocks in the first group
WORD: BLOCK1X divide by 4 to get cord in the same units as X1,X2
WORD: BLOCK1Z divide by 4 to get cord in the same units as Z1,Z2
DWORD: i think this is a floating point number = to 0? have no clue for all the bp files it is allways bc7f0400 but in tb it's 9e430400 or bc7f0400- note tb's water plane is much larger
BYTEs 9-11: Allways 80ff80
Going to start looking at the second group now.
Edit:
For the blocks in second group
DWORD: BLOCK2X1 floating point number in the same units as X1,X2
DWORD: BLOCK2Z1 floating point number in the same units as Z1,Z2
DWORD: BLOCK2X2 floating point number in the same units as X1,X2
DWORD: BLOCK2Z2 floating point number in the same units as Z1,Z2
BYTEs 17-39: Allways 01010000000000ffffffffffff
Edit:
and heres the top part
WORD: Allways 0500
DWORD: Y floating point number
DWORD: X1
DWORD: Z1
DWORD: X2
DWORD: Z2
DWORD: XA floating point number
DWORD: ZA floating point number
DWORD: Allways 03000000
it's all together at
https://docs.google.com/a/zaidesthi...ut=html&ndplr=1
#93
20th Aug 2011 at 8:10 PM
Posts: 82
#94
20th Aug 2011 at 8:27 PM
Thanks everyone, lots of great information, please keep the ideas coming!
I will choose a path that's clear- I will choose free will
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
-RUSH- -RADIO- -RADIO- -EON- -ARCHIVES-
Simpeople and Me Archive- 11Dots Archive- My Sims World Archive- Sims 1 Archive
Angel Classic Rock Mix!
#95
20th Aug 2011 at 9:41 PM
Posts: 82
Briefly here's the one for the second set of data, I think you can see what's happening now.
nb - if using excel it can convert 4digit hex using =HEX2DEC but doesn't do 8digit fps so you need to add a fn or two.
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
nb - if using excel it can convert 4digit hex using =HEX2DEC but doesn't do 8digit fps so you need to add a fn or two.
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Lab Assistant
#96
20th Aug 2011 at 9:55 PM
Posts: 85
Thanks: 22 in 1 Posts
=HEX2DEC(RIGHT(E20,2)&MID(E20,5,2)&MID(E20,3,2)&LEFT(E20,2)) should work if your viewing the files as 8bit and you remove the spaces most hex editors add
=IF(LEFT(RIGHT("000000000"&HEX2BIN(MID(E19,7,2)),8))=1,-1,1)*(BIN2DEC("1"&RIGHT("000000000"&HEX2BIN(MID(E19,5,2)),7))/128+BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,3,2)),8))/32768+BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,1,2)),8))/8388608)*POWER(2,BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,7,2)),7)&LEFT(RIGHT("000000000"&HEX2BIN(MID(E19,5,2)),8),1))-127) and that should work for floating point numbers
=IF(LEFT(RIGHT("000000000"&HEX2BIN(MID(E19,7,2)),8))=1,-1,1)*(BIN2DEC("1"&RIGHT("000000000"&HEX2BIN(MID(E19,5,2)),7))/128+BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,3,2)),8))/32768+BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,1,2)),8))/8388608)*POWER(2,BIN2DEC(RIGHT("000000000"&HEX2BIN(MID(E19,7,2)),7)&LEFT(RIGHT("000000000"&HEX2BIN(MID(E19,5,2)),8),1))-127) and that should work for floating point numbers
#97
20th Aug 2011 at 10:33 PM
Posts: 82
by the way the tile size is 32x32.
so #1 which is 64x64 has 2x2 tiles and therefore 4 sets of data in the second set.
I presume also why the word after the x,z averages is always 3 to indicate 3 sets of data perhaps!?
the last set then refers to tiles by order number which is why the range of these values is always equal to the # entries in dataset2
Already had a set of functions like this...
Option Explicit
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
so #1 which is 64x64 has 2x2 tiles and therefore 4 sets of data in the second set.
I presume also why the word after the x,z averages is always 3 to indicate 3 sets of data perhaps!?
the last set then refers to tiles by order number which is why the range of these values is always equal to the # entries in dataset2
Already had a set of functions like this...
Option Explicit
Quote:
' shg 2008-0919, 2009-0517 (minor changes) ' Routine Input Output WF/VBA ' -------- -------------------- -------------------------- ------ ' Byte2Sng ab(0 To 3) Single VBA ' Sng2Byte Single 4-byte array Variant Both ' Sng2Hex Single Hex String Both ' Hex2Sng Hex string Single Both ' Var2Sng 4-byte array Variant Single Both ' Routine Input Output WF/VBA ' -------- -------------------- -------------------------- ------ ' Byte2Dbl ab(0 To 7) Double VBA ' Dbl2Byte Double 8-byte array Variant Both ' Dbl2Hex Double Hex string Both ' Hex2Dbl Hex string Double Both ' Var2Dbl 8-byte array Variant Double Both ' Routine Input Output WF/VBA ' -------- -------------------- -------------------------- ------ ' Flt2Byte Single or Double 4- or 8-byte array Variant VBA ' Byte2Hex Byte array Hex string VBA '=============================================================================== ' User-defined data types ' (Necessary because that's the only way LSET works) '=============================================================================== Type uab4: ab(0 To 3) As Byte: End Type Type uab8: ab(0 To 7) As Byte: End Type Type uFlt: f As Single: End Type Type uDbl: d As Double: End Type '=============================================================================== ' Functions for Singles (church dances) '=============================================================================== Function Byte2Sng(ab() As Byte) As Single ' Returns the conversion of ' the Big-Endian, 0-based, 4-byte array ab to a Single ' SNaN will cause overflow (as it should) ' VBA function only Dim ub As uab4 Dim uf As uFlt ' put the bytes in Little-Endian order ub.ab(3) = ab(0) ub.ab(2) = ab(1) ub.ab(1) = ab(2) ub.ab(0) = ab(3) ' copy the bytes into the float LSet uf = ub Byte2Sng = uf.f End Function Function Sng2Byte(f As Single) As Variant ' Returns the conversion of Single f to ' a Big-Endian, 0-based, 4-byte array in the variant ' Worksheet function or VBA Dim ab(0 To 3) As Byte Dim ub As uab4 Dim uf As uFlt Dim i As Long uf.f = f ' copy the single into the byte array LSet ub = uf ' put the bytes in Big-Endian order For i = 0 To 3 ab(i) = ub.ab(3 - i) Next i Sng2Byte = ab End Function Function Var2Sng(v As Variant) As Single ' Returns the conversion of ' the Big-Endian, 1-based, 4-byte array in v to a Single ' Worksheet function or VBA Dim ub As uab4 Dim uf As uFlt Dim i As Long ' put the bytes in Little-Endian order For i = 0 To 3 ub.ab(i) = v(4 - i) Next i ' copy the bytes into the float LSet uf = ub Var2Sng = CSng(uf.f) End Function Function Sng2Hex(f As Single) As String ' Returns the conversion of float f to a hex string ' Worksheet function or VBA Const sPad As String = "0" Dim uf As uFlt Dim ub As uab4 Dim i As Long uf.f = f LSet ub = uf For i = 0 To 3 Sng2Hex = Right(sPad & Hex(ub.ab(i)), 2) & " " & Sng2Hex Next i Sng2Hex = Left(Sng2Hex, Len(Sng2Hex) - 1) End Function Function Hex2Sng(ByVal s As String) As Single ' Converts hex string s to a Single ' Worksheet function or VBA Const sPad As String = "00000000" Dim i As Long Dim ub As uab4 Dim ab(0 To 3) As Byte s = Replace(s, " ", "") If Len(s) > 8 Then Exit Function If Len(s) < 8 Then s = Right(sPad & s, 8) For i = 0 To 3 ab(i) = CByte("&H" & Mid(s, 2 * i + 1, 2)) Next i Hex2Sng = Byte2Sng(ab) End Function '=============================================================================== ' Functions for Doubles (swap meets) '=============================================================================== Function Byte2Dbl(ab() As Byte) As Double ' Returns the conversion of ' the Big-Endian, 0-based, 8-byte array ab to a Double ' VBA function only Dim ub As uab8 Dim ud As uDbl Dim i As Long ' put the bytes in Little-Endian order For i = 0 To 7 ub.ab(7 - i) = ab(i) Next i ' copy the bytes into the double LSet ud = ub Byte2Dbl = ud.d End Function Function Var2Dbl(v As Variant) As Double ' Returns the conversion of ' the Big-Endian, 1-based, 8-byte array in v to a Double ' Worksheet function or VBA Dim ub As uab8 Dim ud As uDbl Dim i As Long ' put the bytes in Little-Endian order For i = 1 To 8 ub.ab(8 - i) = v(i) Next i ' copy the bytes into the double LSet ud = ub Var2Dbl = ud.d End Function Function Dbl2Byte(d As Double) As Variant ' Returns the conversion of Double d to ' a Big-Endian, 0-based, 8-byte array in the variant ' Worksheet function or VBA Dim ab(0 To 7) As Byte Dim ub As uab8 Dim ud As uDbl Dim i As Long ud.d = d LSet ub = ud ' output the bytes in Big-Endian order For i = 0 To 7 ab(i) = ub.ab(7 - i) Next i Dbl2Byte = ab End Function Function Dbl2Hex(d As Double) As String ' Returns the conversion of Double d to a hex string ' Worksheet function or VBA Const sPad As String = "0" Dim ud As uDbl Dim ub As uab8 Dim i As Long ud.d = d LSet ub = ud For i = 0 To 7 Dbl2Hex = Right(sPad & Hex(ub.ab(i)), 2) & " " & Dbl2Hex Next i Dbl2Hex = Left(Dbl2Hex, Len(Dbl2Hex) - 1) End Function Function Hex2Dbl(ByVal sInp As String) As Double ' Converts hex string sInp to a Double ' Worksheet function or VBA Const sPad As String = "0000000000000000" Dim i As Long Dim ub As uab8 Dim ab(0 To 7) As Byte sInp = Replace(sInp, " ", "") If Len(sInp) > 16 Then Exit Function If Len(sInp) < 16 Then sInp = Right(sPad & sInp, 16) For i = 0 To 7 ab(i) = CByte("&H" & Mid(sInp, 2 * i + 1, 2)) Next i Hex2Dbl = Byte2Dbl(ab) End Function '=============================================================================== ' Functions for Either (metrosexuals) '=============================================================================== Function Flt2Byte(flt As Variant) As Variant ' Returns the conversion of flt to ' a Big-Endian, 0-based, 4- or 8-byte array Variant ' VBA function only Dim ab8(0 To 7) As Byte Dim ub8 As uab8 Dim ud As uDbl Dim ab4(0 To 3) As Byte Dim ub4 As uab4 Dim uf As uFlt Dim i As Long Select Case VarType(flt) Case vbSingle uf.f = flt ' copy the single into the byte array LSet ub4 = uf ' put the bytes in Big-Endian order For i = 0 To 3 ab4(i) = ub4.ab(3 - i) Next i Flt2Byte = ab4 Case vbDouble ud.d = flt ' copy the single into the byte array LSet ub8 = ud ' put the bytes in Big-Endian order For i = 0 To 7 ab8(i) = ub8.ab(7 - i) Next i Flt2Byte = ab8 Case Else Flt2Byte = CVErr(xlErrValue) End Select End Function Function Byte2Hex(ab() As Byte) As String ' Converts ab to a hex string ' VBA function only Dim i As Long For i = LBound(ab) To UBound(ab) Byte2Hex = Byte2Hex & Hex(ab(i)) & " " Next i Byte2Hex = Left(Byte2Hex, Len(Byte2Hex) - 1) End Function |
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
#98
20th Aug 2011 at 11:03 PM
Posts: 82
hmmm, I think I just realized what the last set is but let me check the theory first, it might also mean the 03 isn't sets of data but LODs.... maybe
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
#99
20th Aug 2011 at 11:41 PM
Posts: 82
a slight revision... there isn't a specific tile size
its all determined by the co-ords of the vertices
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
its all determined by the co-ords of the vertices
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
#100
21st Aug 2011 at 12:07 AM
Posts: 82
for a start, forget the LOD thing... more likely the 03 is to indicate the number of vertices in each set.
Looking at #0 #1 #3 the third dataset becomes clear.
Look at the number of tiles in x and z dir, call them xt and zt
the # words in D3 is = xt*(zt+1)+1
D3 solved!
Look...
#1 7 words
02 00 00 00
02 00 00 00
00 00 00 00
01 00 00 00
02 00 00 00
02 00 00 00
03 00 00 00
#0 37 words
06 00 00 00
05 00 00 00
00 00 00 00
01 00 00 00
02 00 00 00
03 00 00 00
04 00 00 00
05 00 00 00
05 00 00 00
06 00 00 00
07 00 00 00
08 00 00 00
09 00 00 00
05 00 00 00
0A 00 00 00
0B 00 00 00
0C 00 00 00
0D 00 00 00
0E 00 00 00
05 00 00 00
0F 00 00 00
10 00 00 00
11 00 00 00
12 00 00 00
13 00 00 00
05 00 00 00
14 00 00 00
15 00 00 00
16 00 00 00
17 00 00 00
18 00 00 00
05 00 00 00
19 00 00 00
1A 00 00 00
1B 00 00 00
1C 00 00 00
1D 00 00 00
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Looking at #0 #1 #3 the third dataset becomes clear.
Look at the number of tiles in x and z dir, call them xt and zt
the # words in D3 is = xt*(zt+1)+1
D3 solved!
Look...
#1 7 words
02 00 00 00
02 00 00 00
00 00 00 00
01 00 00 00
02 00 00 00
02 00 00 00
03 00 00 00
#0 37 words
06 00 00 00
05 00 00 00
00 00 00 00
01 00 00 00
02 00 00 00
03 00 00 00
04 00 00 00
05 00 00 00
05 00 00 00
06 00 00 00
07 00 00 00
08 00 00 00
09 00 00 00
05 00 00 00
0A 00 00 00
0B 00 00 00
0C 00 00 00
0D 00 00 00
0E 00 00 00
05 00 00 00
0F 00 00 00
10 00 00 00
11 00 00 00
12 00 00 00
13 00 00 00
05 00 00 00
14 00 00 00
15 00 00 00
16 00 00 00
17 00 00 00
18 00 00 00
05 00 00 00
19 00 00 00
1A 00 00 00
1B 00 00 00
1C 00 00 00
1D 00 00 00
C'est la vie, they say, because they can't change their world, but, we can! That's why we have CAW! :rolleyes:
Who Posted
|