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.

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


That's what I felt too but wouldn't know where it's refered to. But now, I'll co-relate acccordingly.

I have told you everything that I know about the OBJM record structure.

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

Are you still talking about the OBJM record, which is a fixed 8 bytes per entry? Or are you talking about the MOBJT record?

The source code believes that each table entry in the OBJM record contains 2 DWORDs, the Instance number followed by the Reference number. It ignores anything which occurs in the OBJM record after the end of the table, ie after Count entries of 2 DWORDs each.

Could you quickly explain a "fallback GUID"? Or give a pointer? Thanks.

Are you still talking about the format of the MOBJT record? The LA treats it as a table of entries where the last DWORD in each entry specifies whether there is another entry after it. The entry length is fixed, except for one 7bit string.

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.

I really appreciate your taking this on. Since I've never done modding before, I find this very difficult. I just don't seem to have the skills required (patience?) at this time.

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?

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.





Still talking about the OBJM. I have pretty much cracked the MOBJT. What version are your OBJMs?

Come to think of it, where is my MOBJT post I made earlier?? The forum has lost it!

Here it is again...


64 BYTES

Zeroes..

DWORD

String saying "ojbt" backwards

DWORD

Version number according to Wiki. Mine are version 0x55

DWORD

Zeroes

*Begin record*

DWORD

GUID of object

WORD

Unk

WORD

Unk

WORD

Unk

WORD

Unk - I am branding these as WORD because of the pattern the values make

DWORD

Private attributes

DWORD

Num object arrays

DWORD

Semiglobal attributes

WORD

OBJM CrossReference

WORD

Type (from Object Data 0x0009)

BYTE

String Length

VARIABLE STRING

Name of object

DWORD

Unk - usually zeroes

DWORD

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.

Very simple. I'm just telling you what the LA code does. I'm not saying that it's correct; I'm saying that it appears to work.

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.

This completely matches my understanding of the OBJM record (assuming that your "record" is my "table entry"), as shown by my example of the pedestrian portals at the Goth residence.

I'll check. Of course, the LA tries to handle all versions. [Update:] Where is the OBJM version?

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.



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.

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.

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.

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.

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.

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.

I notice that my 1x6 beach lot has an additional 20 beach portals from the deleted area... you might want to delete the additional beach portals before you shrink the lot...

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.

At the moment, this thread is the only place that we have to discuss anything. I do not want discussion in the private forum.

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.

Was the MOBJT file breakdown any help to you Mootilda?

All information about these record formats is helpful. I changed the LA to document the fields that you found, but no logic changes were required for this record.

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.

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

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.

Moved over from the private dangerous downloads forum, since this is actually interesting information about the game:

I'd just like to clarify this:

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?

I cannot stress enough how important I believe that it is to keep all discusssions public. I would really prefer that the private dangerous downloads forum only be used for dangerous downloads.

At this time, we only have one other thread, so it looks like all discussion should go there.

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.

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?

Probably depends upon the terrain. Unfortunately, the beach portals were not deleted. Instead, they seem to have been moved underground by the game. I haven't been able to verify this, but I am unable to place new beach portals because the game insists that there is already something in that location.

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.

Sorry, I see that both the Back and Next buttons are incorrectly labelled after a Restart; I'll fix that in the next test version.

[Update:]Fixed. Please download version 0.1.4 for fix.

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

Do you know whether normal beach lots can be shared without the blue tear?

Unfortunately, the hand wasn't evident and the beach portals couldn't be grabbed, even with the portal revealer on the lot. However, it's interesting that you didn't have this problem with your beach lots.

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.