Replies: 2423 (Who?), Viewed: 453382 times.
Page 48 of 97
One horse disagreer of the Apocalypse
#1176 Old 16th Nov 2007 at 2:09 PM
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
Mad Poster
#1177 Old 16th Nov 2007 at 2:32 PM Last edited by niol : 19th Nov 2007 at 2:50 PM.
Default [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.
Site Helper
Original Poster
#1178 Old 16th Nov 2007 at 7:00 PM
Default 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.
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).

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.
Are you still talking about the OBJM record, which is a fixed 8 bytes per entry? Or are you talking about the MOBJT record?

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

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.
Could you quickly explain a "fallback GUID"? Or give a pointer? Thanks.

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

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
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?
One horse disagreer of the Apocalypse
#1179 Old 16th Nov 2007 at 8:02 PM Last edited by Inge Jones : 16th Nov 2007 at 8:13 PM.
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)
One horse disagreer of the Apocalypse
#1180 Old 16th Nov 2007 at 8:07 PM Last edited by Inge Jones : 16th Nov 2007 at 8:17 PM.
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.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Site Helper
Original Poster
#1181 Old 16th Nov 2007 at 8:32 PM Last edited by Mootilda : 16th Nov 2007 at 11:06 PM.
Quote:
Originally Posted by Inge Jones
I don't see how you say this?
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.

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

Quote:
Originally Posted by Inge Jones
Still talking about the OBJM. I have pretty much cracked the MOBJT. What version are your OBJMs?
I'll check. Of course, the LA tries to handle all versions. [Update:] Where is the OBJM version?
One horse disagreer of the Apocalypse
#1182 Old 16th Nov 2007 at 8:50 PM
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)
Site Helper
Original Poster
#1183 Old 16th Nov 2007 at 11:23 PM
Moved over from the research thread copy. Please post here instead.

Quote:
Originally Posted by Mutantbunny
Quote:
Originally Posted by Mootilda
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
Of course,I know this one. BUT: in an OTR lot there IS a road. Just because it's in the middle of the lot shouldn't stop placement--at least in MY world it shouldn't lol....
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.

Quote:
Originally Posted by Mutantbunny
Quote:
Originally Posted by aelflaed
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.
What/how...and huh? lol....Please explain? I think I'm missing some knowledge here. I know Mootilda has said on several occasions to 'pick the lot up' and I haven't had a clue what she meant. Please, someone educate me here....
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.
Site Helper
Original Poster
#1184 Old 17th Nov 2007 at 12:33 AM Last edited by Mootilda : 17th Nov 2007 at 5:06 AM.
Default 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?
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.
Forum Resident
#1185 Old 17th Nov 2007 at 5:49 AM
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.
Site Helper
Original Poster
#1186 Old 17th Nov 2007 at 5:56 AM
Quote:
Originally Posted by Mutantbunny
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...
One horse disagreer of the Apocalypse
#1187 Old 17th Nov 2007 at 10:39 AM
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)
Site Helper
Original Poster
#1188 Old 17th Nov 2007 at 2:53 PM Last edited by Mootilda : 17th Nov 2007 at 3: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.
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.
One horse disagreer of the Apocalypse
#1189 Old 17th Nov 2007 at 3:07 PM
Was the MOBJT file breakdown any help to you Mootilda?

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Site Helper
Original Poster
#1190 Old 17th Nov 2007 at 4:14 PM
Quote:
Originally Posted by Inge Jones
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.
One horse disagreer of the Apocalypse
#1191 Old 17th Nov 2007 at 4:17 PM
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)
Forum Resident
#1192 Old 17th Nov 2007 at 4:21 PM
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.
Site Helper
Original Poster
#1193 Old 17th Nov 2007 at 4:47 PM
Default 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
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?
Site Helper
Original Poster
#1194 Old 17th Nov 2007 at 4: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.
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.
One horse disagreer of the Apocalypse
#1195 Old 17th Nov 2007 at 5:18 PM
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)
Forum Resident
#1196 Old 17th Nov 2007 at 7:06 PM
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?
Site Helper
Original Poster
#1197 Old 17th Nov 2007 at 7:15 PM Last edited by Mootilda : 17th Nov 2007 at 8: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...
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.

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.
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.
Forum Resident
#1198 Old 17th Nov 2007 at 9:46 PM
*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.
Site Helper
Original Poster
#1199 Old 17th Nov 2007 at 9:59 PM
Quote:
Originally Posted by Mutantbunny
The move to Three Lakes again created the blue tear.
Do you know whether normal beach lots can be shared without the blue tear?

Quote:
Originally Posted by Mutantbunny
If there is anything underground, the hand becomes evident and the item can be grabbed.
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.
Forum Resident
#1200 Old 17th Nov 2007 at 11:18 PM
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.
Page 48 of 97
Back to top