Lol I haven't *got* to the OBJM yet, so far I have been focussing on each filetype you last asked for The only thing I would say is that I am beginning to think the OBJM is actually the top of the lookup hierarchy rather than the MOBJT, as the OBJM actually appears to have one short entry per Instance UID. I think the game goes *from* the OBJM to the MOBJT and OBJT for its next layer of info.


Can I have something more specific than "I'm running into some rotations " so that I can research them. Please send me the lot file and point out the relevant OBJT instance numbers. You may have simply hit a different version format I haven't finished analysing (I did tell you there were some of those) and therefore what you have pulled out isn't from their rotation field at all. At a quick glance I can recognise parts of the rotation codes I listed in some of them but in those cases it looks like you have managed to get them shifted by a couple of bytes. Though like you say it could actually be an undocumented rotation code.

Later: I have spotted some of these myself now. So far I have only seen any in the slot entries, so I *think* these are probably modified by some relative values in the CRES hierarchy. I am not worried yet, because I am hoping that with the obligatory/recommended load-buildaction-save that LA users are instructed to do after editing a lot, the objects will be self-correcting to preserve their internal integrity. I mean they may be already totally relative values anyway and not need altering. So in the light of this new information my recommended course of action at this point for the LA is to only touch the first set of coords for each object (in the ped portal example that would be the ones immediately following "So straight on with the coords..."), and maybe the one for the _objt entry if it happened to be the same as the main coords.

[Testing Worthiness - presently]


Because beach lots and the normal lots share a lot of common hidden objects and they can have been mislocated throughout the shrinking process. Mislocation can cause errors on some running objects which may have been a cause for some of reported crashes.

That's why Inge went into investigating the data formats for these files in a hope that it may help improve the shrinking codes to avoid errors due to that known potential cause.






That's not a real proof but just an as-if-safe assumption. But, I may take it for LA 127B, which had "strings that were really long" and "fencepostlayer" fixed, in my own exp. play.
Since these 2 were fixed, I can only get a bare ambiguous case for a type of roof lot to crash at day-night toggle. No other exception so far... Quite unlike the ealier 1277, I had several crashes in my base game copy. I do surmise the "strings that were really long" was the major factor for relatively more crash-prone results in my experiences. The latter doesn't appear to cause any crash in my limitted fencepost-silencing tests.

Also, those who claimed corruptions or further "frequent crashes" haven't shown the followings to support the validity of their reports:
1. Had they used a new neighbourhood folder for different LA versions? (To avoid accumulative corruptions from impaired versions of LA)
2. Had they removed custom hacks or even any potentially related mods?
3. Had they confirmed that their back-up copies or blanks if any wouldn't result the same?
4. Had they really followed the precautions?
etc...

These I've yet to read about if any.
That's why I said previously there're some reports that are just still in questions coz some of the reporters didn't provide even just some very basic informations such as "LA version, "game version", "concise procedural steps", lot specs., the original blank resluts etc.

Let's not even talk about if their procedures were proper as they barely told. If we read about the posts, there's a trend that those who know more on what they're doing tend to have fewer crashes or even no crash at all. Why?
I don't wanna name someone out, but I do see people mis-performed some tests and concluded on those improperly handled experiments. I don't wanna be mean, but I do see some problems, so I made a "still in questions" remark instead in the hope that ones would pick that up. I'm not perfect either and I did make mistakes, and I'm just lucky to notice some of my own and others' problems.
Let's not get confused with those distractions.

I do see that we may need some clear dummy guidelines to tell the basics -- what to test and how to perform basic testings as a fundamental reference point, probably better with supporting explanations on the steps (so testers can get to know why they are doing that or even can suggest back something we aren't aware of ...).
Surely, we'll need a suggestion thread to keep check on the validity of the testing reference as time goes by. People should be welcome to discuss about their procedures before experiment performances to diminish waste of efforts.


[chit-chat]



A binned lot will appear in all neighbourhoods in a given custom folder.
A family is normally specific to a given neighbourhood in which they were made.
I'm unsure if any inference drawn from the above 2 facts is really relevant.





We can't be even certain if the Maxis lots themselves won't corrupt themselves anyway ... [in a jokey manner on Maxis products... ]

The pun may be resolved up to the point at least in the workable range.

Right, I am getting a suspicion that the "rotation" field is actually just the 2nd half of some ghastly quaternian array. Mootilda, using your handy automated field stripper, please can you check whether any of the fields I have labelled "8 BYTEs - Unk (always 0)" actually have non-zero values?

Also let me know if any of those unlisted "rotation codes" *are* in the main coords (the first coord and rotation set in each OBJT)

pbox, yes you are right--whatever a 'safety test' would be defined as.

As niol says, and as I have said in every way I can think of to get through, we don't have a standard 'safe lot' guideline--and we need one evidently. Mootilda is refusing to set one as I gather she has no idea what that could possibly be or even admit we need one.

And yes I agree, the EA/Maxis lots very well could be 'corrupt' themselves. And if so, so what if these lots are corrupt too, lol....However, a standard guideline for 'what is a corrupt lot' is also not defined.

For me, the answer to 'what is a corrupt lot' as currently accepted is 'does the lot crash?' an acceptable 'safety test'. Well, the beach lots have not crashed therefor they meet this definition. However, Mootilda does not accept that definition evidently as she claims they 'might be' corrupt, nor does she, evidently, have any idea what the definition should be and is unwilling to discuss it to set one.

Further, when someone manipulates a discussion with a 'what are you talking about' type statement because they have chosen to convienently forgot all the posts prior to two posts back, they are simply being...well like an EA support tech! Simply unknowledgable without wanting to admit it. And the bad part is in the unadmittance, not in the unknowing.

I was right about the Quaternians unfortunately. The 2 DWORDs I labelled "rotation code" appear to be the quaternian Y and W. What I was calling East is the start point for the rotation, so probably should have been called North (though I will go into the game and check the sunrise on my lots), and the really annoying thing is that the objects' rotations are not all exact graduations of 45 degrees, some are just off, which is what explains the large variety of actual hex digits we're finding.

So unfortunately if the LE wishes to rotate objects, it's going to have to have some algorithm to decide whether an object was "sort of facing north" etc based on limits to what you'd accept as pretty much the variation you'd allow before calling it NorthEast, IYSWIM

Edit: I have just discovered the shadows don't move during the day!!! That's not right!

I really think that this is uncalled for.

FYI: Mutantbunny is now on my ignore list.

Yes, I agree with that, only that I wouldn't call it a 'safety test' -- it's actually an 'unsafety test'. It answers the question: is this lot corrupt? -> Does it crash? Yes.

The opposite is not true, however:



No -- all this means is that they're not *proven* to be unsafe, but it doesn't mean that they're safe. I believe this is where you and Mootilda have been miscommunicating before. Read my above dizzy-quote again: only because no crash occurs does *not* mean that there's no corruption going on; it only means we don't *know* it does.

It's like: here's a box; there may be a bomb in it or a cute bunny (or perhaps nothing at all). If the box explodes, we know it was a bomb, but if it doesn't, we don't know anything. It *may* still be a bomb that blows up tomorrow -- we simply don't know.

Do you know what I mean?

Believe me, i'd be very happy if this could be solved in some easy way (like, opening the box and looking inside) .. but unfortunately, none of us can do that. Mootilda doesn't know the source code of the game any more than you or I do; again, I can absolutely understand your frustration but please don't take it out on Mootilda. I think you're being really unfair here, probably without realising *how* unfair.

(I need to run off now, sorry if this sounds like a brush-off -- I really don't mean to start an argument with you =) I just hope that a "third opinion" from another builder may take the poison out of your argument. There is no reason to argue, we all have to live with the same facts .. hope you get my drift.)

The only thing is, if we had this attitude to everything, that if it didn't crash the game it still didn't mean it was safe, would we ever have any custom content to download?

can the values found from this trick help?

http://www.modthesims2.com/showthread.php?t=204112


Yay, 1 more supporting point on the suspected shadowing problem.

I invite you, again, to prove me wrong: DEFINE what you want for a lot to be deemed 'safe' and how we are to reach that without a testing base.

Inge, like I said above, it's everybody's own responsibility -- as matter of fact: if my lots crash someone's game they're not going to hold it against you, and vice versa. Only Mootilda is in a different position than we are (as builders), that's what I was trying to explain.

I don't believe this - Mootilda I think you might be about to be incredibly relieved that the LA code is right about the OBJM after all. By an *incredibly* weird bit of coincidence, the OBJM I was analysing had entries whose OBJT numbers were the same as the XOBJ for the next object. Though it now leaves me unsure how to tie up the XOBJ instances with the objects on the lot.

You're right, I'm incredibly relieved. I have been very concerned about the portal code since you told me that the code was wrong. Thanks for letting me know.

We're not out of the woods yet - I can't spot any way of cross-referencing to the XOBJ since making that discovery.

Well, the GUID does it of course, but that won't say which XOBJ goes with which instance.

Why is the thread locked?

"Locked by: ThreadMover Reason: Outdated / No Replies"

[Update:]

Note that a thread can be unlocked if you have something to add to the discussion.

That's interesting, because the "strings too long" bug was causing crashes in the LE, which means that the LE never would have completed the shrinking. Do you still have an original lot which crashed after shrinking with a version of the LE which did not have the long-string fix and didn't crash after shrinking with a version with the fix? I'd be very interested in examining such a lot, if anyone has one.

I've wondered about the fence posts, though. After all, the LE wasn't moving them at all, which means that they could easily have ended up "out of world", which we believe may cause crashes. Has anyone actually checked whether all crashing lots had missing (possibly replaced) fence posts?

It would be really wonderful if the various bugs that I've fixed already were causing a lot of the problems with the shrunken lots.

Yes, but the binned lots are not referenced in the neighborhood package, so they don't really explain why all neighborhood packages are modified during every game session.

We are all doing our best to resolve the corruption problem - it's a difficult one, and is taking time. It isn't helped by taking out our frustrations on each other.

Our current ability to test the safety of these lots is limited to being sure when they are corrupted, but at least getting more general testing may set minds at rest.

Mutantbunny, perhaps you would feel better if you released a beach lot on the building test forum - the forum this thread is attached to. Label the file as risky, and ask people to test and offer feedback on your upload thread.

If lots of people trial it, and no-one reports a crash after a week, say, then perhaps that lot can be deemed 'safe as far we can tell'.

No-one is telling you what to do with your lots, but we are trying to do the right thing by everyone. It's a juggling act.

With "the LE wasn't moving them at all", do you mean LE 1.2.7.7 or later versions too? Two of my crashing lots (the Backdoor Lane and one of the other ones) were made with 1.2.7.8, and from what I recall, that version seemed to handle the fenceposts OK (read I didn't see missing posts anymore with it).

From what I can tell right away, it looks like the fenceposts were fine on the 1.2.7.8 lots (read they showed up in their proper place, without me having to replace them) -- i could go through my old screenshots to be really sure, would that make sense?

Which version had the fix? My terrace lots crashed, and I could re-shrink the blue one with the updated LE if that's what is needed. They were made with 127.11

My terraces did not have missing/replaced fence posts.

It looks like this problem was fixed in 1.2.7.8, which means that crashes on lots created with 1.2.7.8 cannot be explained by this bug. You've answered my question and there's no need to do anything more.

Does that deal with the long-strings possibility too?

No, it doesn't. The most likely result of the long-strings bug was a crash in the LE itself, which means that the lot would remain untouched.

However, if anyone still had a copy of a crashing shrunken lot from before it was shrunken, I can check it easily to see whether there are any object strings > 127 characters. If you remember what custom content you had in the houses, you can also just check yourself for very long object names.

Note that this is a very rare bug. I believe that the only issue is with custom content... I don't think that Maxis has any objects with names that long.

There is a copy of my blue terrace, unshrunk, on the hidden forum.
Niol, I've started playing your mini lots. One CL lot, no troubles I found. One RL lot, which was doing fine (building) until I tried to use a terrain paint, when it hung completely. I'll go and give it another try.

Longest string was <75, which is still quite a ways from 128.

Just FYI: the ones that were crashing LE were from aussietopenders. Was anyone using these?