A list, by post number or by links to posts, seems like a reasonable first step. Who knows, perhaps that's all we really need in the first post of a new thread. The discussion can continue on from there.

A brand new lot should have exactly 6 standard portals: 2 pedestrian, 1 car start, 1 car stop, 1 service start, 1 service stop. If there are more than that? Well, perhaps EA / Maxis was very sloppy with the original lot template?

I believe that the beach portals are still in the lot file, but with "out of world" coordinates. We could probably find them by running a debug version of the LA to list all of the portals and their coordinates. Would you like to try that?
The crippled version of the LA that I just uploaded for Igne should show you all of the beach portals.

EA sloppiness is all I could comeup with too, but haven't checked it out yet--will tomorrow.

[lot templates]



1. I meant a residential lot of 20x60, I've not made the 60x20 lot template just in case that failure was due to U11. But, I've not done this testing fully yet... After all, I now think it's safer to make those templates from the largest lot template size. Or even, i may have to use a whole custom folder to fix the lot template before using them as templates. Lol, here I mean lot templates in the game file systems not the ones in the lot bin.
Lol, there're many things keeping me busy lately. Here and there, you know... I also start to lose track on which experiments I "have been" doing... So, you see why I realised some re-organisations is necessary as more infos and topics are put in.

2. I suggest to wait for some in-group testings before public testings. I now still regret to release those resized lots so impatiently and didn't realise I didn't check them carefully enough. After all, my understanding has been changing as I learn more things and get in more infos. This I'm glad for.


[Thread Splitting Organisation]

All,
I've nothing to add to the topic list presently, but I think thread title may be formatted like
Lot-modding - resizing - irregular sizes
Lot-modding - resizing - 1 x 1
Lot-modding - resizing - beach lots
So by means of title structure, we may group up these separate topics to show their potential co-relevancy.

I've thought to put in a lit light and unlit light to find out where they store the stage or material or bhav or what it's running at the time of lot-saving.
I hope to find out how some of these potential means are stored.
1. numeric values to stand for the stages/statuses of the object in-game at the lot-saving moment.
2. material group or scenegraphical group named for a particular state.
3. scoring data
At least some graphical animation by the materials will be newly initiated for every lot-entry. So, I doubt the stage would be recorded for those.

but, am I talking about fantasy?

Thanks for the extra info Mootilda, I shall digest it over the next several hours.

Another idea for the administration of these extra threads. Does anyone think it would be a good idea to have a new child forum under research and development for lot and hood-specific discussion? Then the threads would be easy to find, and maybe one or two people who are actively researching this area could be made moderators of that specific child forum along with one of MTS2's regular moderators such as Numenor?

Maybe a child forum would be good. I also had the thought that the whole downloading problem could be easily circumvented by emailing the test programs to the testers - but it might be very unwieldy of course.

I'm gradually going through the 1082 posts (up to page 2 of goodness-knows-what) and noting what topic they relate to.

Most of the early posts about rotation and portals so far are no longer relevant, since the LE now does some of it. How much of the general, outdated discussion would we want to keep in a topic thread? Everything, for the sake of completeness/history? Or just the bits that work?

No I think you have a good idea there. Mootilda is still trying to build up a list of 10 people to make the private forum worth setting up, and there still aren't 10 last time I looked. The file is not all that large. Assuming none of the testers nor Mootilda are on dialup or metered charging, the email idea should be perfectly workable. The benefit of that is that even specially tailored versions can be sent to individuals without Mootilda having to put in bold font "this is a debug version for MutantBunny only" etc.

I'm happy to put my hand up as a tester (I have pm'd Moontilda to let her know). My technical knowledge of the workings of the game is limited - but I'm willing to learn. For the record I also think the email idea is a good one.

You didn't delete it, Mootilda - did you want to?

The child forum is a neat idea and pretty workable.
I don't mind receiving downloads through emails from whom I know from this group.

When I first read your post, I thought "that's a good idea".

But, when I tried to decide on the primary sub-categories, I realized that the whole topic of lot-modding doesn't seem hierarchical to me. Row houses may be related to resizing (shrinking or irregular sizes), or they may not (overlapping of lots). So, then resizing is a subcategory of row houses? Obviously not.

So, I think that we should to stick to the original suggestion of creating subthreads. This thread can act as the main TOC, which points to the subthreads as they are created. The subthreads can point to all other subthreads of interest in their first post.

This certainly follows good development techniques. Allow a small group to find the main bugs, then expand the test group. That's the whole idea behind having an in-house testing group, an alpha test, a beta test, and then a release.

Argh after wondering for ages why bytes 80-87 were all zeroes I have just worked out you gave the byte positions in decimal! SimPE shows the matrix labelled in hex. What tool are you using that labels the byte positions in dec?

The MOBJT does not appear to have my specimen loveseat in it at all, that only has an OBJT and XOBJ. MOBJT seems to comprise only global objects for some reason.

The OBJM file looks rather unuseful to the untrained eye, just a list of consecutive numbers with no obvious cross-referencing. I would be very interested in more detail about this then, or tell me to go to the wiki if it's all already in there.

You still might have different features in different stages of development, so would still want an inner testing circle and an outer testing circle perhaps, with the releases flowing outwards like ripples.

Please let me know if there's anything that I can do to help. I really appreciate your looking at this, since I have felt completely out-of-my-depth on the issue of objects. If the shrinking crashes are caused by out-of-world objects, I'm really going to need all of the help that I can get to figure out how to solve this.

That would be wonderful, if it was possible. I like this idea better than trying to create a hierarchical structure for lot modding issues.

I think that lot-modding is a basically unexplored area, which is why this thread has been so active. There's so very much to do and so very much to learn. At the moment, the LotAdjuster is the main tool that we have for lot-modding, so all of the topics have migrated to this thread.

When I took over the LotExpander, there just didn't seem to be much information outside of the source code itself. Unlike objects and sims, which seem to have a lot of information available. I love that we are helping to map this uncharted area.

Too unwieldy for me. I'm not even willing to consider this.

That's a huge task. Thank you.

I think that it's worth having a post per topic on this thread which points to all of the other posts, since you're doing the work anyway. The new threads should only contain pointers to posts that are still relevant, why bog them down? If we can summarize all of the relevant posts into the main post for the new thread, so much the better. However, that's also a huge amount of work (summarizing a lot of threads and extracting only the good stuff), so I'd leave that for another time.

I hope that people don't mind me reposting something which I posted at MATY. I really think that this bears repeating:


I really have to disagree with this. What JM says is true: if the game crashes, then it won't have time to save the corrupted data.

But, my concern is this: The game seems to work most of the time. However, at least one person has experienced increasing numbers of crashes over time. I'm concerned about what the game is doing with the "corruption" when it doesn't crash.

The access violation means that the game is accessing random memory. It could easily be corrupting random stuff in its own internal memory without causing an access violation. The O/S isn't going to stop the game from doing whatever it wants to with memory which belongs to the game - it only really stops programs when they try to access memory which is outside of valid memory space. So, anything that's loaded into the Sims 2 memory space is in danger of being corrupted.

We know that the game doesn't have strict checks for data corruption. It could be blindly continuing on, corrupting little bits of stuff as it goes. If our suspicion about out-of-world objects is correct, the game is only trying to access memory which is "a little bit off" from where it should be. Given the huge amount of data in a lot file, the most likely thing being corrupted (at least initially), is the lot itself. So, no crash and the user saves the lot to play another day. The new bits of corruption are saved with the lot. The next time it's run, the game corrupts the lot a bit more. Over time, perhaps it corrupts the neighborhood, or other lots being played, or sims.

I'm not saying that this is happening. I'm saying that it's a possibility. That's why someone said that it's better to have a spectactular crash than to have a little bit of corruption which grows and grows.

Some of us have been playing these lots without any sign of corruption or crashes. Perhaps the shrinking code doesn't corrupt all lots. Unfortunately, we don't have a LotAnalyzer which will check a lot for corruption and tell us what's corrupted and whether the corruption is spreading. That's why I consider all of these shrunken lots potentially bad - even if they've never had a crash.

According to the Wiki. OBJM is just something to do with the imposters? Wouldn't that just get remade when you save the lot?

Found it. Removed it. Thanks.

I'm so sorry. I was looking at the C# source code. Never even thought about the fact that SimPE only uses hex. In general, I try to add a prefix to all hex values (0x); that's how programs differentiate decimal and hex. How about this: in future posts, I'll try to specify both decimal and hex addresses? "Width at 80 = 0x50" Would that be better?

That's interesting information. I told you about the portal logic because I assumed that all objects could be handled in the same way. However, Andi's object code doesn't follow that path (except for the portals). Instead, he just changes the X,Y coordinates in the OBJT and XOBJ records separately, without reference to any other records.

I'll check the wiki and the source code and get back to you about this.

[Update:]

According to the wiki
http://www.sims2wiki.info/wiki.php?title=4F626A4D:
4F626A4D
Short name: OBJM
Long name: Object Material
This resource describes metadata imposters and goes by both OBJM and OBMI.

64 Bytes: File name (null terminated)
DWORD: Version
DWORD: Entry Count

for each entry:
DWORD: Unknown
DWORD: WORD Count

for each word:
WORD: Unknown

Let me see what I can add to this from the source code.

[Update:]
The information about the entries seems to be wrong. Here's what I've got:

68 Bytes: File name (null terminated) - usually all zeros
68 = 0x44 DWORD: unknown (non-zero)
72 = 0x48 DWORD: Block ID = 0x4F626A4D
76 = 0x4C DWORD: Entry Count

for each entry:
DWORD: Instance of XOBJ and OBJT record
DWORD: Reference number (refers back to an entry in the MOBJT record)

The code doesn't have anything else about this record.

Can you explain what a metadata imposter is? Or provide a pointer? Thanks!

My two cents, and I know I'm the odd man out, always am, always will be:

I don't really like the idea of a bunch of different threads. The idea of a thread per topic is good, at first glance and in a perfect world (forum?.) But the fact is, with many threads there will be many repeat posts, many references to the other threads, possibly missed important data because one doesn't read that thread for a day, concentrating on another, etc, and many moments searching for 'where did I read that' data. I can see that it does LOOK like a good idea, but in practice, I think it'll lack seriously.

Look at this thread, really, it is the 'go to' place, we all post here, we all get exposed to all the various ideas/thoughts, it is givng us on average two pages of posts to read a day, and in reading everything posted we are all expanding our knowledge bases. I know I for one will still want to read all the psots in all the different threads--it'll just be more spread out and harder to keep up with for me. Just my personal view...

Emailing: my first reaction was, 'oh hell no' because I don't give out my home email to anyone anywhere--security risks, whether you see it or not. My email registered here and everywhere else is my hotmail account. I suppose the file could be mailed to there, but it will be a pib to get it that way, even if it is under the max size allowed.

Of course, in the end, I'll just go with the flow whatever is decided.

Mootilda, I understand your concern with corruption. I think it is a good thing to be concerned with. I also think that the game does 'heal' itself and in that it can and does limit, maybe stops, corruption. Does it limit/stop ALL corruption? Maybe and maybe not, remains to be seen with lot shrinking.

But where is that point of 'is this lot safe' or not? How many cycles/sim hours/people hours does one have to play to prove it is safe? Perhaps we need to set up a 'what is safe' outline/guideline?

You're on the list. I think that it's really good to have a variety of skill levels.

We have 9 people. pbox asked a couple of people, so I was still waiting for one more PM. However, I suppose that 9 people is a pretty good number. Why don't I pass this on to Delphy and see what happens?

That's why it's a good idea to discuss this whole refactoring before actually doing anything.

This was my initial reaction, way way back at the end of September when the first refactoring was done. That splitting was basically a no-brainer, since it allowed me to update the main LotExpander post and showed the tool as being supported again. The gain clearly outweighed any loss.

We decided at that time to create two additional threads, rather than just one: one for the LotExpander and support of the released version, the other for all of the research, discussion, and test versions (this thread). Three threads seemed very managable, especially since Andi's thread was locked.

Having too many threads to watch is still a concern for me. However, many people are having problems keeping up with this thread, so it would be nice if we could do something to organize things a bit better.

I think that niol's original suggestion was just that we create some indexes to useful posts. I took it the extra step and suggested that we consider additional threads, because I thought that some people might not be as interested in some of the topics. For example, I'm much more interested in tiny lots than in huge lots. So, having multiple threads might actually give us all less to read.

We could still consider niol's original suggestion of creating posts with links to all posts on a particular topic. The main post on this thread could have links to each topic TOC. If each person took over one topic, keeping the TOCs up-to-date might not be an overwhelming task. Although, any ongoing TOC is still going to be a large amount of work.

Another idea is to have each post point to the next (or previous) post for each topic that it covers. Over time, we could update our old posts by adding links. That way, someone who was interested in a topic could start at the main post and follow the links through, avoiding all irrelevant posts. I haven't got any real feel for how much work this would be, or how well it would work.

Adding titles (which just list the topics covered) to each post might be a simple way to allow people to skip irrelevant posts for the topic that they're following. Very little extra work and the gain may be substantial. The hard part is those long posts where we talk about everything at once. We'd all have to try to restrain ourselves. New topic - new post.

Do you have an alternative strategy to suggest?

That's good to know. If I felt that the game could eventually heal the corruption, I wouldn't be nearly as worried.

Obviously, there's no way to prove that a lot is not corrupt by playing it. However, I trust a lot that's been played by 10 people for a week a lot more than I trust a lot that's been played by me for a half-hour.

In general, my preference is to fix the shrinking feature to remove our concerns about crashing and corruption. We just need to come up with some reasonable strategies and then test the results.