- Site Map >
- Modding and Creation >
- Sims 2 Creation >
- Modding Discussion >
- Research & Development >
- Discussion: Lot Size, Orientation, Rotation, etc.
- Site Map >
- Modding and Creation >
- Sims 2 Creation >
- Modding Discussion >
- Research & Development >
- Discussion: Lot Size, Orientation, Rotation, etc.
#1176
16th Nov 2007 at 1:09 PM
Posts: 11,682
Thanks: 9675 in 11 Posts
Quote: Originally posted by Mootilda
"Nummer" is just german for "number". The translation wasn't very helpful when I was trying to figure out this code. I have since changed this to "Reference", which I hope is more understandable. |
It's ok, I wasn't having a problem with the German - it's very similar to English anyway. The questionmark just meant I was querying that I had the right field identified as belonging to that variable.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Advertisement
#1177
16th Nov 2007 at 1:32 PM
Last edited by niol : 19th Nov 2007 at 1:50 PM.
Posts: 4,403
Thanks: 10657 in 115 Posts
[record formats (lots and neighbourhood)]
Quote: Originally posted by Inge Jones
Anyway I have isolated individual records in the MOBJT, and spotted that the final DWORD in each is its fallback GUID. So baasically a record begins with the current GUID and ends with its fallback GUID. I think there is some stuff from the object's OBJD in there too, but to make sure I need to do a test editing the OBJD between runs and see what changes. ...I actually think deciphering file formats is quite fun :D |
This resonates the floor tile references.
Oh well, it's definitely a funny pun game. I'm busy on something ATM, but will be back soon...
Quote: Originally posted by Inge Jones
...At least so far the OBJT lookup is always in the immediately preceding DWORD to the reference#. ... |
That's what I felt too but wouldn't know where it's refered to. But now, I'll co-relate acccordingly.
#1178
16th Nov 2007 at 6:00 PM
Internal data structure: MOBJT, OBJM, XOBJ, OBJT
Quote: Originally posted by Inge Jones
The OBJM records are not consistent with each other, even across 3 instances of exactly the same object in the same OBJM. Sometimes the XOBJ instance ref is 3 DWORDs before the Reference number and sometimes 5. |
The LA has a tight loop (Count times through the loop) which reads exactly 2 DWORDs: the Instance followed by the Reference number. There is nothing else in an entry and there is nothing else in the table. If there is anything else at the end of the table, the LA ignores it.
The LA treats the Instance number as the Instance of both the XOBJ and OBJT records. I do not believe that there is any correlation between different Reference numbers, or between different entires in the OBJM table.
Note that my understanding, based on the LA code, does not match the wiki definition of this record, which says that each entry in the main table contains the Instance followed by a 2 byte count (n), and then n entries of 2 bytes each.
The LA code seems to work, so I trust it. When running automated tests on all Maxis-made lots within all Maxis-made subneighborhoods within all Maxis-made neighborhoods, the LA consistently finds the portals and is able to point me at lots which have non-standard portals (for example, portals which point in the wrong direction). This would not work if the wiki code was correct.
However, I am quite willing to admit that the LA code is incomplete and only works for portals, mailboxes, phonebooths, and trash cans (I haven't tried it with other objects).
Quote: Originally posted by Inge Jones
And there doesn't seem to be a field that holds the number of bytes in the record. If it's there, it's probably a bit value or something. |
Quote: Originally posted by Inge Jones
At least so far the OBJT lookup is always in the immediately preceding DWORD to the reference#. Maybe the sourcecode can reveal an algorithm. After all, it needs to know how big a chunk to read in! |
Quote: Originally posted by Inge Jones
Anyway I have isolated individual records in the MOBJT, and spotted that the final DWORD in each is its fallback GUID. So baasically a record begins with the current GUID and ends with its fallback GUID. |
Quote: Originally posted by Inge Jones
The references you outline in the OBJM do work as far as they go, but it gives 4 DWORDs per record, and that doesn't fit because two of my known objects start 7 DWORDs apart. So, either some records are shorter, or they're all longer or some other variation. |
Each entry in the MOBJT table has the following format:
20 bytes - unknown
2 bytes - Reference number
2 bytes - unknown
7bit string - unknown
4 bytes - unknown
4 bytes - GUID
4 bytes - if zero, no more entries - end of table.
If you need an explanation of 7bit strings: A 7bit string consists of one or more bytes which contain the length of the string, followed by the string. The string is not null terminated. When looking for the string length, only the bottom 7 bits of each (length) byte are used. If the top bit is set, then the current length of the string is shifted 7 bits and the bottom 7 bits of the next byte is added to the length. Very few strings have the top bit of the first byte set, so usually you can just use the first byte of the length as the length of the string.
Quote: Originally posted by Inge Jones
Not to worry, I shall keep cracking away at it. I actually think deciphering file formats is quite fun :D |
One thing that I could try is to change the debug version of the LA to use it's navigation logic for all objects, rather than just the portals, etc. So, I might be able to correlate an MOBJT entry with one or more OBJM entries, then with the corresponding XOBJ and OBJT Instances. Would that be helpful?
#1179
16th Nov 2007 at 7:02 PM
Last edited by Inge Jones : 16th Nov 2007 at 7:13 PM.
Posts: 11,682
Thanks: 9675 in 11 Posts
Quote: Originally posted by Mootilda
The LA has a tight loop (Count times through the loop) which reads exactly 2 DWORDs: the Instance followed by the Reference number. There is nothing else in an entry and there is nothing else in the table. |
I don't see how you say this? There are at least 3 pertinent DWORDs in an object record in OBJM - at least for buyable objects. It may be different for portals but that still leaves the record size variable within the OBJM. The Reference number, the OBJT instance number, and the XOBJ instance number. And then there are some extra ones in some cases. Each object by GUID has just the one reference number, and the OBJM holds one record per *instance* of that object, using the same reference number. So for instance I placed one of my hacked shrubs 3 times on the lot. It was instance 01, and the entries for it looked like this:
0000000A- E3 00 00 00 5F 00 00 00 9E 00 00 00 67 00 00 00
0000000B- 98 00 00 00 01 00 00 00 97 00 00 00 5F 00 00 00
0000000C- 96 00 00 00 67 00 00 00 7F 00 00 00 01 00 00 00
0000000D- 7E 00 00 00 5F 00 00 00 7D 00 00 00 01 00 00 00
The XOBJ instance numbers are in bold, the OBJT numbers are in italic. You will notice the first two occurences for the shrub are 6 DWORDs long, and the third is only 4 DWORDs long. The only other explanation can be that the shrub has two reference numbers in the MOBJT, one for the OBJX instance and one for the OBJT instance. In this example the 2nd reference number would be 5F. But there was no such value in the MOBJT for this object.
Quote:
Are you still talking about the OBJM record, which is a fixed 8 bytes per entry? Or are you talking about the MOBJT record? |
Still talking about the OBJM. I have pretty much cracked the MOBJT. What version are your OBJMs?
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1180
16th Nov 2007 at 7:07 PM
Last edited by Inge Jones : 16th Nov 2007 at 7:17 PM.
Posts: 11,682
Thanks: 9675 in 11 Posts
Come to think of it, where is my MOBJT post I made earlier?? The forum has lost it!
Here it is again...
64 BYTES
*Begin record*
DWORD
*end record*
DWORD
NB I am about 98% certain the UNKs will turn out to be nothing the LA needs to worry about.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Here it is again...
64 BYTES
Zeroes..DWORD
String saying "ojbt" backwardsDWORD
Version number according to Wiki. Mine are version 0x55DWORD
Zeroes
*Begin record*
DWORD
GUID of objectWORD
UnkWORD
UnkWORD
UnkWORD
Unk - I am branding these as WORD because of the pattern the values makeDWORD
Private attributesDWORD
Num object arraysDWORD
Semiglobal attributesWORD
OBJM CrossReferenceWORD
Type (from Object Data 0x0009)BYTE
String LengthVARIABLE STRING
Name of objectDWORD
Unk - usually zeroesDWORD
Fallback GUID of object
*end record*
DWORD
Zeroes
NB I am about 98% certain the UNKs will turn out to be nothing the LA needs to worry about.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1181
16th Nov 2007 at 7:32 PM
Last edited by Mootilda : 16th Nov 2007 at 10:06 PM.
Quote: Originally posted by Inge Jones
I don't see how you say this? |
I would be very happy if you could correct any errors in the way that the LA is parsing the various record structures, or if you could add any information to the very scanty information that the LA has about the record structures.
If it's not helpful for me to post what the LA does, I can stop. I was hoping that this was helpful information for you, since it does seem to work.
Oh, and just a semantic thing: To me, a "Record" is an Instance of a "Record Type", such as MOBJT Instance 0 or OBJM Instance 5. A record may contain one or more "Tables". A table contains zero or more "Entries", which may consist of a number of "Fields", such as a DWORD GUID or a 7bit String.
I'm having some problems following what you're saying because you seem to be using the term "record" for what I would call an "entry" in a "table"... I wonder whether we could agree on some terminology? Perhaps you could tell me what terms you use for the structure that I've described above? I'm just not that familiar with modding and I want to use the standard Sims 2 modding terms so that people can understand me.
Quote: Originally posted by Inge Jones
Each object by GUID has just the one reference number, and the OBJM holds one record per *instance* of that object, using the same reference number. |
Quote: Originally posted by Inge Jones
Still talking about the OBJM. I have pretty much cracked the MOBJT. What version are your OBJMs? |
#1182
16th Nov 2007 at 7:50 PM
Posts: 11,682
Thanks: 9675 in 11 Posts
Quote: Originally posted by Mootilda
If it's not helpful for me to post what the LA does, I can stop. I was hoping that this was helpful information for you, since it does seem to work. |
I've got the source code now, it was supposed to stop you having to take the time to write it all out in posts So I am trying to rely to the source when I simply want to know what the LA does, and assuming when you give me information directly about the format of a file, that is because you agree with that info yourself.
What the LA does may well work, because it may only edit the OBJT - the instance number of which *is* always right next to the reference number. Again I don't need to know that right now, it will all shake out in the wash.
Quote:
Oh, and just a semantic thing: To me, a "Record" is an Instance of a "Record Type", such as MOBJT Instance 0 or OBJM Instance 5. A record may contain one or more "Tables". A table contains zero or more "Entries", which may consist of a number of "Fields", such as a DWORD GUID or a 7bit String. |
We were taught "record", "row" and "entry" are pretty much the same thing. I would not refer to a packed file as a record. I agree with the definition of a field anyway The sims files are pretty much single-table jobbies, with some header and footer info.
Anyway why don't I just try and annotate these filetypes, and when I am done you can take or leave as much of it as is useful to you. We don't have to argue over what we're calling it.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1183
16th Nov 2007 at 10:23 PM
Moved over from the research thread copy. Please post here instead.
The operative phrase is "along the edge". The game requires a road at the front of the lot, along the edge of the lot, in order to move or place the lot in a neighborhood. An "over the road" lot does not meet this requirement. I have not found any way, in-game, to get around this requirement. There are tricks which may or may not work, but as far as I know this cannot be done in-game.
Whether the Sims 2 "should" have this requirement is another matter.
I am talking about running the Sims 2, going into the neighborhood, opening the "Lot & Houses - F2" menu, selecting the "Move or Rotate Lot" tool (which looks like a hand), and then using the tool to pick up the lot. If you do this with an "over the road" lot, the game will attempt to regenerate a new road at the front of the lot. If you've built or placed things in this area, the game may be unable to regenerate the road, and may therefore refuse to place the lot.
Quote: Originally posted by Mutantbunny
Quote: Originally posted by Mootilda
|
Whether the Sims 2 "should" have this requirement is another matter.
Quote: Originally posted by Mutantbunny
Quote: Originally posted by aelflaed
|
#1184
16th Nov 2007 at 11:33 PM
Last edited by Mootilda : 17th Nov 2007 at 4:06 AM.
Shrinking beach lots
I just made a 1x6 beach lot, which is working fine so far. I put it in the lot bin and put a number of them side by side on the unbuildable beach area on Twikki island.There was one spot where a lot wouldn't place (I assume because of a neighborhood terrain change), so I placed a lot next to where I wanted it, then moved it using the LA "Move lot" feature. When I entered the lot the first time, it crashed. The second time, it allowed me to enter the lot without any problem, but the left edge of the lot was raised, especially at the road, creating a blue gap.
So, it appears that the game actually does change the edge vertices on the lot, based on the current location of the lot in the neighborhood. What's more, the game changed the edge so that it wasn't linear between neighborhood vertices.
Running LA 0.1.3 on the lot again with no size change smoothed out the edge, so that there was no longer a blue gap.
Not sure what any of this means, but I wanted to document what happened.
Quote: Originally posted by Mutantbunny
Have you tried to place your lot on a different terrain than the one it was built on? |
It looks like the game is getting confused for some reason and creating these blue gaps, but they are easy to fix with the edge smoothing feature.
Something else odd, though. The beach portals for the lot in Three Lakes seems to have gone underground. The game won't allow me to place new ones, because it says that something is already there.
#1185
17th Nov 2007 at 4:49 AM
Posts: 682
Quote: Originally posted by Mootilda
Took my 1x6 lot and placed a new copy in the Three Lakes neighborhood. It got a blue tear at the end, so I ran LA 0.1.3 on it with no size change - fixed the blue tear. It looks like the game is getting confused for some reason and creating these blue gaps, but they are easy to fix with the edge smoothing feature. |
yay! I had tried running the lot thru 010 twice. Forgot to try it with 013.
The game making the tear: yes, that's the conclusion I came to too. Why/how beats me. But with your implimenting the smoothing feature running the lot twice is no big deal--all good. Small beach lots. I'll make a set tomorrow and play them.
#1186
17th Nov 2007 at 4:56 AM
Quote: Originally posted by Mutantbunny
Small beach lots. I'll make a set tomorrow and play them. |
#1187
17th Nov 2007 at 9:39 AM
Posts: 11,682
Thanks: 9675 in 11 Posts
Quote: Originally posted by Mootilda
Moved over from the research thread copy. Please post here instead. |
I don't think it belongs in this thread at all - that is specifically LA development and testing stuff that is only of interest to LA testers and developers. It'll just end up on the list of posts that are due to be split off from the thread.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1188
17th Nov 2007 at 1:53 PM
Last edited by Mootilda : 17th Nov 2007 at 2:00 PM.
Quote: Originally posted by Inge Jones
I don't think it belongs in this thread at all - that is specifically LA development and testing stuff that is only of interest to LA testers and developers. It'll just end up on the list of posts that are due to be split off from the thread. |
I have made some requests to Delphy to allow me to organize things. If you would prefer, I'm quite willing to have someone else organize things. However, I feel very strongly that discussion needs to remain public.
The reason that I moved the blue gap issue over here, is that it is not an issue specific to the current LA development and testing. Instead, it is about what the game is doing with beach lots, and how an LA feature can help to resolve this issue, both now and in the future.
When deciding what information is to be public and which private, I believe that it is always better to err on the side of caution. If Andi had decided to keep information private, I never would have been able to take over the LotExpander development.
#1189
17th Nov 2007 at 2:07 PM
Posts: 11,682
Thanks: 9675 in 11 Posts
Was the MOBJT file breakdown any help to you Mootilda?
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1190
17th Nov 2007 at 3:14 PM
Quote: Originally posted by Inge Jones
Was the MOBJT file breakdown any help to you Mootilda? |
I think that the OBJM record will require extensive logic changes, based on what you know so far. In fact, it's amazing that it works at all, given what you've found. But, my primary interest is the object data stored in the OBJT and XOBJ records.
Again, if there's anything that I can do to help, please let me know.
#1191
17th Nov 2007 at 3:17 PM
Posts: 11,682
Thanks: 9675 in 11 Posts
I have made a start on OBJT anyway, it seems to be largely about remembering which recolour and material had been chosen for the object (which isn't very interesting to the LA). But I haven't reached the end of the file yet :D
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1192
17th Nov 2007 at 3:21 PM
Posts: 682
I expected my post about beach lots to be moved to the beach lot thread. I think maybe we're unclear about what topic goes where.....not surpirsing for a brand new forum to be a bit confusing/disorganized, I guess.
#1193
17th Nov 2007 at 3:47 PM
Sloping roads
Moved over from the private dangerous downloads forum, since this is actually interesting information about the game:
Quote: Originally posted by Inge Jones
Sloping roads seem to be ok (well I am talking about an earlier version of course but it works in principle) as long as the user ensures there is a straight vector between each of those important 10-tile main vertices along the road. Oh and of course the portal juggling that has to be done to get the pizza delivered :D |
If I were to slope a road from one edge to the other, would the road continue to function? Doesn't the game require flat areas for each portal? Can a road also slope from front to back?
#1194
17th Nov 2007 at 3:51 PM
Quote: Originally posted by Mutantbunny
I expected my post about beach lots to be moved to the beach lot thread. I think maybe we're unclear about what topic goes where.....not surpirsing for a brand new forum to be a bit confusing/disorganized, I guess. |
At this time, we only have one other thread, so it looks like all discussion should go there.
#1195
17th Nov 2007 at 4:18 PM
Posts: 11,682
Thanks: 9675 in 11 Posts
Quote: Originally posted by Mootilda
If I were to slope a road from one edge to the other, would the road continue to function? Doesn't the game require flat areas for each portal? Can a road also slope from front to back? |
Well as I pointed out elsewhere this is only really relevant to lots destined for shrinking, but in principle yes everything works or (like with the pizza delivery) can be made to work with a patch. My hack told the pizza boy never mind what d*mn level you're on just get the pizza lol! And he did.
Or you can for instance slope one end of the road for 10 lot tiles - keeping the gradient constant, and then have the rest of the road flat - move your portals onto the flat part. Taking this lot to the bin and placing several times adjacent would be one way of keeping an interesting existing sloping road sloped, otherwise the road would keep lifting to stay level with each lot you placed, and destroy the geography of the area.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1196
17th Nov 2007 at 6:06 PM
Posts: 682
I have 1xs, perfect 1xs. I'm happy.
Mootilda--I did not find the portals from area deleted. In fact, I had one lot, the 1x5, that had one LESS beach portal than it should have had. Easily replaced...
The new UI takes us back to the hood selection window and this is nice. But I found that I could not change hoods from that spot and had to close the program, reload to get to the other hood package file.
I want to mark these lots as Specialty lots so they show up in their own section of the bin. Is there a way to do this? Can someone point me at the instructions?
Mootilda--I did not find the portals from area deleted. In fact, I had one lot, the 1x5, that had one LESS beach portal than it should have had. Easily replaced...
The new UI takes us back to the hood selection window and this is nice. But I found that I could not change hoods from that spot and had to close the program, reload to get to the other hood package file.
I want to mark these lots as Specialty lots so they show up in their own section of the bin. Is there a way to do this? Can someone point me at the instructions?
#1197
17th Nov 2007 at 6:15 PM
Last edited by Mootilda : 17th Nov 2007 at 7:10 PM.
Quote: Originally posted by Mutantbunny
Mootilda--I did not find the portals from area deleted. In fact, I had one lot, the 1x5, that had one LESS beach portal than it should have had. Easily replaced... |
If anyone had any ideas on how to resolve this issue, I would appreciate it.
Try binning your 1x beach lot and then adding it to the Three Lakes subneighborhood. That's when my portals seemed to disappear. If yours also disappear, then the game is doing something odd and we'll need to find a solution before trying to share beach lots.
Quote: Originally posted by Mutantbunny
The new UI takes us back to the hood selection window and this is nice. But I found that I could not change hoods from that spot and had to close the program, reload to get to the other hood package file. |
[Update:]Fixed. Please download version 0.1.4 for fix.
#1198
17th Nov 2007 at 8:46 PM
Posts: 682
*sigh* Not so perfect after all. The move to Three Lakes again created the blue tear. I placed the 1x4 and the 1x5 and both presented the same. The 1x3 would not be placed (too short.) All my portals were present and in their proper place, but sunken to ground level. This sinking/floating thing I have reported before and is dependent on the slope of the terrain.
I had a dled junk yard lot that had many many buried items not visible at all. If there is anything underground, the hand becomes evident and the item can be grabbed. With the off lot portals in Andi's lots, this is also true: the hand becomes visible and the portal, although way off lot, can be grabbed.
I had a dled junk yard lot that had many many buried items not visible at all. If there is anything underground, the hand becomes evident and the item can be grabbed. With the off lot portals in Andi's lots, this is also true: the hand becomes visible and the portal, although way off lot, can be grabbed.
#1199
17th Nov 2007 at 8:59 PM
Quote: Originally posted by Mutantbunny
The move to Three Lakes again created the blue tear. |
Quote: Originally posted by Mutantbunny
If there is anything underground, the hand becomes evident and the item can be grabbed. |
#1200
17th Nov 2007 at 10:18 PM
Posts: 682
hm. No I don't. I have read that they 'can't' be shared at all. But this may be just a function of 'hard to place'. Haven't read anyone mention the blue tear, haven't seen much posted on them overall.
Oh wait: The blue tear only happens on the 1xs, anyway that's the only place I've seen them. The other lots are fine, all the 2xs and bigger. So I would guess no one else has seen this.
I find it very interesting, wish I knew how to read the code, that the 1xs are ok some of the time, then bam moved and blue tear is there and the bigger lots are ok all of the time (so far).
Portals: Yes, I find it odd that you did and I didn't. But then--remember I had trouble with the EA beach portal being a 'keep buying' item? It's not doing that now. It couldn't have been the LA affecting this either as I tried the portals on a clean, fresh install of an EA lot.
Oh wait: The blue tear only happens on the 1xs, anyway that's the only place I've seen them. The other lots are fine, all the 2xs and bigger. So I would guess no one else has seen this.
I find it very interesting, wish I knew how to read the code, that the 1xs are ok some of the time, then bam moved and blue tear is there and the bigger lots are ok all of the time (so far).
Portals: Yes, I find it odd that you did and I didn't. But then--remember I had trouble with the EA beach portal being a 'keep buying' item? It's not doing that now. It couldn't have been the LA affecting this either as I tried the portals on a clean, fresh install of an EA lot.
Who Posted
|