Replies: 2423 (Who?), Viewed: 453384 times.
Page 47 of 97
Site Helper
Original Poster
#1151 Old 15th Nov 2007 at 2:48 AM Last edited by Mootilda : 15th Nov 2007 at 5:15 AM. Reason: Add title
Default 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.
Good question. At this time, we don't have any instructions for how to do this. niol suggested replacing another lot file in the neighborhood with the "over the road" lot file, but I'm not sure that will work for binned lots. You could try it with a test neighborhood.

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 Old 15th Nov 2007 at 3:31 AM
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.
Forum Resident
#1153 Old 15th Nov 2007 at 3:46 AM
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.
Site Helper
Original Poster
#1154 Old 15th Nov 2007 at 4:57 AM Last edited by Mootilda : 15th Nov 2007 at 5:21 AM. Reason: Typo
Default 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.
You want to have an over-the-road lot available as a template, and placeable in game?

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.
Did you try unlocking all of the tiles of the lot using the LotExpander? It's my belief that this should unlock the tiles on the far side of the road.
One horse disagreer of the Apocalypse
#1155 Old 15th Nov 2007 at 9:11 AM
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)
Forum Resident
#1156 Old 15th Nov 2007 at 2:46 PM
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.
One horse disagreer of the Apocalypse
#1157 Old 15th Nov 2007 at 3:05 PM
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)
One horse disagreer of the Apocalypse
#1158 Old 15th Nov 2007 at 3:24 PM
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)
Site Helper
Original Poster
#1159 Old 15th Nov 2007 at 4:21 PM Last edited by Mootilda : 15th Nov 2007 at 4:23 PM. Reason: Add title
Default 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.
Just to confirm: You now believe that all objects are referenced in the MOBJT record, using a reference number or "metadata imposter" to access the XOBJ and OBJT instances through the OBJM record?
One horse disagreer of the Apocalypse
#1160 Old 15th Nov 2007 at 4:31 PM Last edited by Inge Jones : 15th Nov 2007 at 4:45 PM.
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)
Mad Poster
#1161 Old 15th Nov 2007 at 5:32 PM Last edited by niol : 15th Nov 2007 at 5:41 PM.
Default 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.
Mad Poster
#1162 Old 15th Nov 2007 at 5:37 PM Last edited by niol : 15th Nov 2007 at 5:45 PM.
Default 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.
Site Helper
Original Poster
#1163 Old 15th Nov 2007 at 7:09 PM
Default 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
Here's my current understanding:

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.
One horse disagreer of the Apocalypse
#1164 Old 15th Nov 2007 at 7:33 PM
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)
Site Helper
Original Poster
#1165 Old 15th Nov 2007 at 8:36 PM Last edited by Mootilda : 15th Nov 2007 at 11:22 PM. Reason: Clarification
Default 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
As far as I know, the Reference number only exists in two places: MOBJT and OBJM. The OBJM record links the GUID and other metadata within the MOBJT record to the data in the XOBJ and OBJT records through the Reference number.

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.
One horse disagreer of the Apocalypse
#1166 Old 15th Nov 2007 at 8:48 PM Last edited by Inge Jones : 15th Nov 2007 at 9:57 PM.
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)
Site Helper
Original Poster
#1167 Old 15th Nov 2007 at 10:18 PM Last edited by Mootilda : 15th Nov 2007 at 11:54 PM. Reason: Clarification
Default 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?
Well, from portale.cs in LA V0.1.3 (search for OBJM), I see that the Instance and Reference are right beside each other:
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?
I don't know whether 29 is the Count or the start of the table entries.

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.
That's good to know. Perhaps the instances only match for the road portals, mailbox, phonebooth and trash?

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?
Yes. It is used for the portals, mailbox, phonebooth and trash, as specified in the source code. All other objects are ignored in the portal logic and are handled in R_XOBJ.cs and R_OBJT.cs instead. Instances to be examined are found by looking for the portal GUID in the MOBJT record and then using the Reference number to get the Instance numbers from the OBJM record.

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.
I agree. Very little is known about these record types. If you can decipher where useful information is stored, perhaps you could update the wiki and I could update the source code.

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.
My understanding of 7bit strings is that they are not actually null-terminated. Instead, they begin with a count which is contained in one or more bytes (if a byte has the top bit set, then the next byte is a part of the character count). Can I assume that you are talking about the string in MOBJT? It's the only use of ReadString that I can find in the portal code.
Alchemist
#1168 Old 15th Nov 2007 at 10:27 PM Last edited by aelflaed : 15th Nov 2007 at 11:31 PM.
Default 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.
Site Helper
Original Poster
#1169 Old 15th Nov 2007 at 10:48 PM
Default 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.
I believe that the LA "unlock tiles" feature is the best solution for "over the road" lots. Once the tiles are unlocked, they remain unlocked through multiple game sessions. The other solutions mentioned do not make a "permanent" change to the lot, but must continue to be used.

Of course, if you move the lot in-game, then you lose both the unlocked tiles and the "over the road" feature.
Site Helper
Original Poster
#1170 Old 15th Nov 2007 at 11:32 PM
Default LotExpander and Sims 2 development
Quote:
Originally Posted by Inge Jones
a reference number "Nummer"?
"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.

Quote:
Originally Posted by Inge Jones
I feel sure EA didn't need to make it so complex.
Whenever I see a structure like this, I believe that it was EA's attempt to convert legacy code from Sims 1 into code that works for the Sims 2. I even seem to remember you saying that a maxoid had described the OBJM record as legacy code.

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!
Forum Resident
#1171 Old 16th Nov 2007 at 3:06 AM
Default 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 Old 16th Nov 2007 at 4:55 AM
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.
One horse disagreer of the Apocalypse
#1173 Old 16th Nov 2007 at 9:23 AM Last edited by Inge Jones : 16th Nov 2007 at 9:47 AM.
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)
Alchemist
#1174 Old 16th Nov 2007 at 10:22 AM
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.
One horse disagreer of the Apocalypse
#1175 Old 16th Nov 2007 at 2:06 PM
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)
Page 47 of 97
Back to top