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.

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 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.

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.

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.

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.

It really only affects the road area - you still can't build on the very edges.

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.

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?

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

Either should work.

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.

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.

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.

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.

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

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
...

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?

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.

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.

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.

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.

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.

"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.

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!

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.
.

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.

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

Thank heaven somebody does! I'm very happy to leave you to it.

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!