- 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.
#1151
15th Nov 2007 at 1:48 AM
Last edited by Mootilda : 15th Nov 2007 at 4:15 AM.
Reason: Add title
Non-standard roads
Quote: Originally posted by Mutantbunny
Just interested in what everyone had to say about the subject. I have made a few successfully, but ofc ourse, can't bin and move them successfully, looking for some possible ways to get around this. |
Do you understand what I mean when I say that you replace the lot file? You need to create a dummy lot in the neighborhood with the correct U11 (in-game), then exit the game and delete the dummy lot file in the Lots directory and copy the real lot into the Lots directory with the file name of the dummy lot. I just don't know whether this technique will work for binned lots, though.
If this works well, then perhaps you'd consider writing a tutorial?
For small movements in the neighborhood, you can use the "Move lot" feature of the LA.
Advertisement
Alchemist
#1152
15th Nov 2007 at 2:31 AM
Posts: 2,894
Thanks: 17927 in 66 Posts
I've done one 'over the road' lot yesterday. Don't know that I have anything helpful to add about it.
I haven't tried that function before, and now that I have, I think it has a very limited usuefulness. The lot snaps to the road again if moved, so it works the same as just expanding at the front. The game also would not allow building on the space on the far side of the road, so all I gained was the ability to block traffic, or to build my house in mid-air above the road. Not enough gain to justify building lots that cannot be moved or shared, for me.
I haven't tried that function before, and now that I have, I think it has a very limited usuefulness. The lot snaps to the road again if moved, so it works the same as just expanding at the front. The game also would not allow building on the space on the far side of the road, so all I gained was the ability to block traffic, or to build my house in mid-air above the road. Not enough gain to justify building lots that cannot be moved or shared, for me.
#1153
15th Nov 2007 at 2:46 AM
Posts: 682
I built across the street... ok I placed a few walls but it seemed to be fine. But just having the lot is not what I want--I want the lot to be a template, to be at my beck and call when and where I want it.
#1154
15th Nov 2007 at 3:57 AM
Last edited by Mootilda : 15th Nov 2007 at 4:21 AM.
Reason: Typo
Non-standard roads
Quote: Originally posted by Mutantbunny
I built across the street... ok I placed a few walls but it seemed to be fine. But just having the lot is not what I want--I want the lot to be a template, to be at my beck and call when and where I want it. |
Perhaps you're not aware that the game requires a road at the front of the lot, along the edge, in order to place a lot. Over-the-road lots are non-standard lots and the game is not willing to place them while maintaining the road location. There are tricks that may or may not work for moving and placing these lots in your game, but you will never be able to treat these lots as standard lots.
I'd like to add that the same comments apply for no-road lots.
Quote: Originally posted by aelflaed
The game also would not allow building on the space on the far side of the road, so all I gained was the ability to block traffic, or to build my house in mid-air above the road. |
#1155
15th Nov 2007 at 8:11 AM
Posts: 11,682
Thanks: 9680 in 11 Posts
I have managed to build on the road. I can't remember exactly how, but a combination of move_objects and the locktiles cheat (is it boolProp locktiles false?) should do it.
"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)
#1156
15th Nov 2007 at 1:46 PM
Posts: 682
I did have moveobjects on --always play with it on-- and I may have had the constraint floor elevation cheat on. I know I did not have the lock tiles cheat active.
I have to admit: I do not fully understand the 'unlock tiles' feature. I have tried it on several occassions, attempting to build in unbuildable areas, but I see no difference in lot behavior at all. I must just be 'missing it' somehow.
I have to admit: I do not fully understand the 'unlock tiles' feature. I have tried it on several occassions, attempting to build in unbuildable areas, but I see no difference in lot behavior at all. I must just be 'missing it' somehow.
#1157
15th Nov 2007 at 2:05 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
It really only affects the road area - you still can't build on the very edges.
"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)
#1158
15th Nov 2007 at 2:24 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
I need to contradict something I said earlier. I said normal buyable objects don't have their GUIDs in the MOBJT. That was incorrect. Maybe I was tired or SimPe's hex highlighting was being unreliable when I was exploring that.
"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)
#1159
15th Nov 2007 at 3:21 PM
Last edited by Mootilda : 15th Nov 2007 at 3:23 PM.
Reason: Add title
Internal data structure: MOBJT, OBJM, XOBJ, OBJT
Quote: Originally posted by Inge Jones
I need to contradict something I said earlier. I said normal buyable objects don't have their GUIDs in the MOBJT. That was incorrect. |
#1160
15th Nov 2007 at 3:31 PM
Last edited by Inge Jones : 15th Nov 2007 at 3:45 PM.
Posts: 11,682
Thanks: 9680 in 11 Posts
I found the GUIDs of my shrub and my cat statue in there - both buyable objects. I haven't followed the entire chain of reference through yet but I thought it was a good idea to let you know my mistake ASAP.
A little later: Doh!!!!!!!!!!!!! I know what went wrong. I *think* you may have said OBJM (type 0x4F626A4D) in an earlier post when you meant to say MOJBT (type 0x6F626A74) when we were talking about the cross-referencing of GUID/OBJT entries before. Yes I can certainly see that the MOBJT looks a rich picking ground for cross-references, but that's not the filetype the Wiki was describing as "This resource describes metadata imposters" which was the OBJM, and shows nothing that looks like info about my sample objects and their storage on the lot - well not to me anyway.
So if you're *not* saying you use the OBJM for cross-referencing then I think we're nearer the same songbook finally :D
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
A little later: Doh!!!!!!!!!!!!! I know what went wrong. I *think* you may have said OBJM (type 0x4F626A4D) in an earlier post when you meant to say MOJBT (type 0x6F626A74) when we were talking about the cross-referencing of GUID/OBJT entries before. Yes I can certainly see that the MOBJT looks a rich picking ground for cross-references, but that's not the filetype the Wiki was describing as "This resource describes metadata imposters" which was the OBJM, and shows nothing that looks like info about my sample objects and their storage on the lot - well not to me anyway.
So if you're *not* saying you use the OBJM for cross-referencing then I think we're nearer the same songbook finally :D
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1161
15th Nov 2007 at 4:32 PM
Last edited by niol : 15th Nov 2007 at 4:41 PM.
Posts: 4,403
Thanks: 10659 in 115 Posts
build mode infos
Quote: Originally posted by Inge Jones
I have managed to build on the road. I can't remember exactly how, but a combination of move_objects and the locktiles cheat (is it boolProp locktiles false?) should do it. |
Either should work.
#1162
15th Nov 2007 at 4:37 PM
Last edited by niol : 15th Nov 2007 at 4:45 PM.
Posts: 4,403
Thanks: 10659 in 115 Posts
simpe - hex editor - infos
Quote: Originally posted by Inge Jones
I need to contradict something I said earlier. I said normal buyable objects don't have their GUIDs in the MOBJT. That was incorrect. Maybe I was tired or SimPe's hex highlighting was being unreliable when I was exploring that. |
Lol, when switching between files in the hex editor of simpe, it's often better to move the scroll bar to update the presentation. This has been happening since I started to use it.
I know it can be annoying, but I live with it.
#1163
15th Nov 2007 at 6:09 PM
Internal data structure: MOBJT, OBJM, XOBJ, OBJT
Quote: Originally posted by Inge Jones
I *think* you may have said OBJM (type 0x4F626A4D) in an earlier post when you meant to say MOJBT (type 0x6F626A74) when we were talking about the cross-referencing of GUID/OBJT entries before. So if you're *not* saying you use the OBJM for cross-referencing then I think we're nearer the same songbook finally :D |
The MOBJT=0x6F626A74, OBJM=0x4F626A4D, XOBJ, and OBJT function as a unit.
The MOBJT contains metadata about an object, plus a Reference number. The OBJM is a table which can be used to convert the Reference number to one or more Instance numbers. Those Instance numbers can then be used to find the appropriate XOBJ and OBJT records for all instances of the object.
The LA uses this chain only for the road portals, mailbox, phonebooth, and trash. For other objects, it just changes every X,Y coordinate in XOBJ and OBJT, without regard for any other coordinate for the object (either in the current record, or in any other record).
The MOBJT will not function without the corresponding data in the OBJM, since the OBJM record acts as a liason between the MOBJT record and the XOBJ and OBJT records.
#1164
15th Nov 2007 at 6:33 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
I have been trying to look at the OBJM in this light, but I can't see it myself... yet. I mean it must be there for a reason but I am not spotting any instance numbers paired with known GUIDs, UIDs or even byte offsets in my sample lot. It may yet come into focus - like those silhouette drawings that can either be a vase or two faces looking at each other
"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)
#1165
15th Nov 2007 at 7:36 PM
Last edited by Mootilda : 15th Nov 2007 at 10:22 PM.
Reason: Clarification
Internal data structure: MOBJT, OBJM, XOBJ, OBJT
Quote: Originally posted by Inge Jones
I have been trying to look at the OBJM in this light, but I can't see it myself... yet. I mean it must be there for a reason but I am not spotting any instance numbers paired with known GUIDs, UIDs or even byte offsets in my sample lot. It may yet come into focus - like those silhouette drawings that can either be a vase or two faces looking at each other |
Let me take the pedestrian portals at the Goth house at 165 Sim Lane as an example:
The MOBJT record has metadata about the pedestrian portals, plus the Reference number: 0x006B (WORD).
The OBJM record has several entries in the table for this Reference number:
Reference number = 0x0000006B: Instance = 0x00000003 (DWORDs)
Reference number = 0x0000006B: Instance = 0x00000004 (DWORDs)
This tells us that XOBJ Instance 3 and OBJT Instance 3 contain the data about one of the pedestrian portals and XOBJ Instance 4 and OBJT Instance 4 contain the data about the other pedestrian portal.
OBJM will never contain a GUID or UID or a byte offset. It only contains a table which associates the Reference number from the MOBJT record with one or more Instance numbers of the XOBJ and OBJT records.
#1166
15th Nov 2007 at 7:48 PM
Last edited by Inge Jones : 15th Nov 2007 at 8:57 PM.
Posts: 11,682
Thanks: 9680 in 11 Posts
Ok so how far apart are these reference numbers and their corresponding instances in the OBJM file? Mine looks like "29 00 00 00 5F 00 00 00 20 00 00 00 0D 00 00 00 E2 00 00 00 90 00 00 00 E1 00 00 00 1F 00 00 00" etc So would the 29 and the 5F belong together as a pair?
BTW I didn't find the XOBJ and the OBJT instance numbers matched. Not for stuff I bought at least. There is a number *in* the XOBJ that is the instance number of the OBJT.
Later: Is portale.cs actually used? Because the string length of the object which is a byte, appears to be being swallowed up in a dummy element defined as a word, which surely throws everything out by one byte *preceding* the name string, and it's there I think he was trying to pick up a reference number "Nummer"? (Edit - no it's ok he's read the string length as part of the string) Then the string is read, which takes in the zero terminator, and then there is a Dword thrown away, which actually includes the start of another non-zero value. Not sure if it matters in the final analysis, maybe the number wasn't important, but it makes it hard to work out what is being attempted.
Do you happen to know the package name for the Goth lot then I can look at the concrete example you gave. It will probably be clearer then.
Never mind, I've spotted the cross-ref in the OBJM finally, so that's sorted that bit. I feel sure EA didn't need to make it so complex. I am still worried about the lost byte in the portal.cs though and what its knock-on effect might be. Unless of course the readstring function does stop short of the terminator leaving it as the next byte to be read.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
BTW I didn't find the XOBJ and the OBJT instance numbers matched. Not for stuff I bought at least. There is a number *in* the XOBJ that is the instance number of the OBJT.
Later: Is portale.cs actually used? Because the string length of the object which is a byte, appears to be being swallowed up in a dummy element defined as a word, which surely throws everything out by one byte *preceding* the name string, and it's there I think he was trying to pick up a reference number "Nummer"? (Edit - no it's ok he's read the string length as part of the string) Then the string is read, which takes in the zero terminator, and then there is a Dword thrown away, which actually includes the start of another non-zero value. Not sure if it matters in the final analysis, maybe the number wasn't important, but it makes it hard to work out what is being attempted.
Do you happen to know the package name for the Goth lot then I can look at the concrete example you gave. It will probably be clearer then.
Never mind, I've spotted the cross-ref in the OBJM finally, so that's sorted that bit. I feel sure EA didn't need to make it so complex. I am still worried about the lost byte in the portal.cs though and what its knock-on effect might be. Unless of course the readstring function does stop short of the terminator leaving it as the next byte to be read.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1167
15th Nov 2007 at 9:18 PM
Last edited by Mootilda : 15th Nov 2007 at 10:54 PM.
Reason: Clarification
Internal data structure: MOBJT, OBJM, XOBJ, OBJT
Quote: Originally posted by Inge Jones
Ok so how far apart are these reference numbers and their corresponding instances in the OBJM file? |
68 bytes: Zero
4 bytes: Unknown
4 bytes: Block ID = 0x4F626A4D (OBJM)
4 bytes: Count
for Count entries:
- 4 bytes: Instance
- 4 bytes: Reference
Quote: Originally posted by Inge Jones
Mine looks like "29 00 00 00 5F 00 00 00 20 00 00 00 0D 00 00 00 E2 00 00 00 90 00 00 00 E1 00 00 00 1F 00 00 00" etc So would the 29 and the 5F belong together as a pair? |
If 29 is the start of the table, then:
Instance = 0x29 Reference = 0x5F
Instance = 0x20 Reference = 0x0D
Instance = 0xE2 Reference = 0x90
...
However, if 29 is the Count, then:
Instance = 0x5F Reference = 0x20
Instance = 0x0D Reference = 0xE2
Instance = 0x90 Reference = 0xE1
...
Quote: Originally posted by Inge Jones
BTW I didn't find the XOBJ and the OBJT instance numbers matched. Not for stuff I bought at least. There is a number *in* the XOBJ that is the instance number of the OBJT. |
From portale.cs in LA V0.1.3 (search for XOBJ), I see that the record structure is:
68 bytes: Zero
4 bytes: (single) float X
4 bytes: (single) float Y
16 bytes: always 00000001 00000001 0000FFFF FFFF0000 hex for portals
1-4 bytes: Number - always 8 or 12 for portals
Since the hex values are stored with the least significant digits first, this could easily be a 1 byte, 2 byte (short), or 4 byte (int) field; I have no idea which is true. However, depending upon the Number above, the LA looks for the direction byte of the portal in a different place. If the object is not a portal, then the LA doesn't try to parse the rest of the record (after the X,Y coordinates).
Can you tell me where you are finding the OBJT Instance number?
Quote: Originally posted by Inge Jones
Is portale.cs actually used? |
Quote: Originally posted by Inge Jones
Because [the logic doesn't look right]. Not sure if it matters in the final analysis, maybe the number wasn't important, but it makes it hard to work out what is being attempted. |
As I've been trying to explain from the beginning, the MOBJT, OBJM, XOBJ, and OBJT logic in the LA is a mess. It needs to be cleaned up, but that requires research to determine what each byte in each record is for (or at least the important bytes). I really appreciate your taking a look at these record types; I haven't had much luck in trying to parse them.
Quote: Originally posted by Inge Jones
I am still worried about the lost byte in the portal.cs though and what its knock-on effect might be. Unless of course the readstring function does stop short of the terminator leaving it as the next byte to be read. |
Alchemist
#1168
15th Nov 2007 at 9:27 PM
Last edited by aelflaed : 15th Nov 2007 at 10:31 PM.
Posts: 2,894
Thanks: 17927 in 66 Posts
Non-standard roads, unlock tiles
Quote: Originally posted by Mutantbunny
I did have moveobjects on --always play with it on-- and I may have had the constraint floor elevation cheat on. I know I did not have the lock tiles cheat active. I have to admit: I do not fully understand the 'unlock tiles' feature. I have tried it on several occassions, attempting to build in unbuildable areas, but I see no difference in lot behavior at all. I must just be 'missing it' somehow. |
That's why you haven't seen a difference - MoveObjects lets you use the grid that remained locked for me. 'Unlocking' with LE releases the grid too, without the cheat, and if you move the lot to a new place after that, the grid resets to normal use.
Also, as soon as you move this kind of lot in the hood, it snaps to the road at the front, and you lose the effect of the road going through the middle of the lot. So a template would not work.
By the way, I did another lot and ran it through LA, the grid was fixed.
#1169
15th Nov 2007 at 9:48 PM
Non-standard roads; Unlock tiles
Quote: Originally posted by aelflaed
By the way, I did another lot and ran it through LA, the grid was fixed. |
Of course, if you move the lot in-game, then you lose both the unlocked tiles and the "over the road" feature.
#1170
15th Nov 2007 at 10:32 PM
LotExpander and Sims 2 development
Quote: Originally posted by Inge Jones
a reference number "Nummer"? |
Quote: Originally posted by Inge Jones
I feel sure EA didn't need to make it so complex. |
I suspect that the U11 (lot rotation) field is also legacy code. The original Sims 1 did not allow rotation of a lot within a neighborhood, so the orientation of the lot had to be coded inside the lot package itself. When EA split off the Orientation into a separate field which could be controlled by rotating the lot in the neighborhood, they should have removed the U11 field and it's associated source code.
Imagine how much easier our lives would be without legacy code!
#1171
16th Nov 2007 at 2:06 AM
Posts: 682
OTR lot expanding
Quote: Originally posted by aelflaed
That's why you haven't seen a difference - MoveObjects lets you use the grid that remained locked for me. 'Unlocking' with LE releases the grid too, without the cheat, and if you move the lot to a new place after that, the grid resets to normal use. Also, as soon as you move this kind of lot in the hood, it snaps to the road at the front, and you lose the effect of the road going through the middle of the lot. So a template would not work. By the way, I did another lot and ran it through LA, the grid was fixed. |
Well, that explains that.
Only: my OTR lots did not sanp to the road--were not placeable after binning. I must admit: I have lost interest in them fairly fast, hence didn't mess with them much, as they simply won't do what I want of them.
.
Alchemist
#1172
16th Nov 2007 at 3:55 AM
Posts: 2,894
Thanks: 17927 in 66 Posts
Quote: Originally posted by Mutantbunny
my OTR lots did not sanp to the road--were not placeable after binning... |
You probably needed to snap them to the road BEFORE binning them. After that, they work just like any lot which was expanded at the front.
#1173
16th Nov 2007 at 8:23 AM
Last edited by Inge Jones : 16th Nov 2007 at 8:47 AM.
Posts: 11,682
Thanks: 9680 in 11 Posts
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.
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.
Not to worry, I shall keep cracking away at it. I actually think deciphering file formats is quite fun :D
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
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.
Not to worry, I shall keep cracking away at it. I actually think deciphering file formats is quite fun :D
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Alchemist
#1174
16th Nov 2007 at 9:22 AM
Posts: 2,894
Thanks: 17927 in 66 Posts
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. (...) I actually think deciphering file formats is quite fun :D |
Thank heaven somebody does! I'm very happy to leave you to it.
#1175
16th Nov 2007 at 1:06 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
I am doing somewhat better with MOBJT than I am with OBJM. 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. 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. 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!
"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)
Who Posted
|