No, I stick to maxis stuff when testing mainly. Apart from build items, sometimes.

Niol, the lot worked fine on re-entry, terrains and all. I'm letting a sim live there for a while now. Is there anything specific you'd like me to look for?

Finally found one. Nonzero in Lot6: 112 Riverbend Road in Riverblossom Hills, OBJT Instance 2 entry 13. Always zero in the main entry and the first subentry, for my current test cases.

All of the unlisted "rotation codes" that I gave you were in the main coords. I'm not checking any of the other entries (yet).

[LA/LE - UI & versions tests]

Mootilda,

I've to add that the lots i made and tested are all plain lots.
The attached is some exported copies of the lots I had play-tested with crashy results.
May use a completely new neighbourhood generated by the game to play-test it coz these lots are obviously troublesome.


[Lot -shrinking]

aelflaed,

Lumpy_C_Shrunk has its modular/connecting stair's lowest step disconnected from the ground for either the ground was lowered too much for the 7th step or the last step (the 8th step?) was trimmed.
No other problem noticed.

Those 1x1 lots were manually editted according to andi's guidelines and Mootilda's hints. Since they're all in the 10x scheme, I tend to believe they're pretty stable, just the way in my own play-tests. But since I'm not a good player. I don't normally play the game at all, so you can guess how well I can play-test them. I used to build lots mostly. Now, I mod mostly and build occasionally and play only in testings!
Just test it in whatever way you feel like coz I have no idea what to specifically test.
Probably,
1. try to see if the services are all working?
2. any difference in building properties or terrain painting?
3. any shadowing problem?
4. any suggestion... say doing some nefarious experiments on it :D

Can you give me the lot package filename please?

Lot 6, thanks. I can't see the street addresses from the directory without opening them all you see

Hmm not seeing non-zero values here. Have you played the lot you were looking at? Can you send it to me?

I don't believe that I've even played the neighborhood at all. Just to be sure, I checked the original lot straight from the disk - same values.

Just to make sure we're looking at the same thing, can you give me the position in the OBJT file?

Entry string length at 0x345:0x19. String starts at 0x346: "route_trashcanoutdoor_0_n". DWORD which we expect to be zero is at 0x36B: 00 00 00 80.

Do you believe that the rotations for all OBJT entries except the first one are also relative?

Looks like there are an additional three sets of coordinates for cAnimatable (as opposed to cObject) - all of which look like absolute values on the lot, when they aren't zero.

the lots are for your request on some old crash-prone lots.

As I said, I haven't finished analyzing the animatables. That's why I issued an interrim analysis with the portals which are just cObject. The structure of the overall file is different with the animatables. Are you yet in a position to tell me whether my breakdown seems ok for the car portals as well as the pedestrian portals?

This is a very slow process, so if you're waiting for the analysis to be complete, we need to come to terms with the LA not progressing as rapidly as it had been doing. I have to keep going in and out of the game to move things - only one aspect at a time (eg turn 45 deg on one loadup, raise by 3 clicks on the next loadup, test things with one recolourable subset, two recolourable subsets...) Then do it all over after finding an object that creates a different version of the file.

I can run a test to verify this - manually change just the main coords of an object, then look to see if it was functioning correctly in a new position, and if so what effect it had on the values in the file after saving.

But all this takes time, and I am also renovating my kitchen so try not to have unreal expectations of the timescale

So far, everything looks fine. I've done some code cleanup based on your structure definition and run the automated tests to make sure that everything still looks OK. I put in code to move appropriate objects back onto the lot and have been running some new automatic shrinking tests to see whether the code behaves reasonably. I've been reading up a bit about quaternions. I still have to add the rotation logic for the portals, but I don't forsee any problems at this time. After this, I'll be running more manual tests.

I'm very aware of the modding process (what little I've done has been slow) and have no problems with the pace of the results. Inge, I really appreciate the work that you're doing... I wouldn't have been able to come up with these results nearly as quickly as you have. In the interim, I have lots to keep me busy.

Real life always takes precedence. I'm not feeling impatient at all. If my posts aren't helpful, I'm sorry. If my posts seem impatient, I'm really sorry, since it means that I'm not communicating effectively.

I ran tests with the LA to see whether any of your lots contain strings with lengths of > 1 byte. No, you have no long strings on these lots.

Your comment about play-testing threw me off - I'm not play-testing any lots right now.

Mootilda,

I didn't mean to ask you to test lots when you don't feel like. only the following.

Lol, right now. I suggest people to use a new copy of neighbourhood folder for testing or using testing lots.
As you said all neighbourhood packages will get written, so I assume removing all neighbourhoods for a new experiment is a more ideal way to test lots.
This can further reduce interference between different tests.
However, I'm unsure of the memory dumps and not sure if the game also save on the the game programme files by chance or "accidients".

One thing I do think is that you can pretty much ignore XOBJs other than to check the GUID is an object you're into moving (such as a portal). I don't think the LA needs the OBJM at all! The coords in the XOBJ don't change when you move the object, and I don't think they get deleted if you delete the object (not 100% sure yet) but you can find the OBJT from the XOBJ anyway, and then check if it exists. If not, it was probably deleted. The changes in the MOBJT can be made, again, simply checking the GUIDs or the coords. Or carry on using the OBJM to cross reference the MOBJT to the OBJT and ignore the XOBJ altogether.

You could use the "type" in the MOBJT to work out which objects are physical maybe.

Anyway this is just thinking out loud really.

Mootilda, I think it is looking safe to say that the only OBJT coords - including rotation - you need to worry about are the first lot, the second lot (the ones in the objectname_objt entry) and, in the case of the cAnimatable OBJT, there are some numbers I have not yet fully analysed *after* the last entry, which also happen to include coords and rotations. Those change too when an object is moved. All the others like slot entries don't appear to change when the object is moved.

I've made a shop, shrunk on two sides. It is owned by a (Maxis-made) sim, and seems to work fine. It was shrunk on the left and rear to make a 2x1 lot, built to the edges on those sides, two stories on a foundation.

One NPC (somebody Tinker) got stuck on the lot when the shop was first opened, and got stuck again next time he visited. He wandered back and forth for a while, not browsing the displays correctly, and then froze in the middle of the room. I had to delete him eventually.

It hasn't happened to any other sims, so I don't know that it is down to the shrinking. No crashes, but that's nothing new for me.

I'm playing this in my full game, up to Seasons, no Pets.

What I think for the definitions of safe lots:
simply in the range of working lot that we've played so far.
But, we need to analyse all these lots to get the ranges we want to regard them as the safety standard,
Then it'd better to make an analyser to collect the limit data for the ranges and probably also for statistics.

Tried the shrinking code with the logic to move on-world OBJT objects back onto the lot. Without changing the XOBJ in the same way, the objects remain off-world. With a corresponding change in the XOBJ, at least some of the objects are being moved back correctly.

[Update:]
Looks like some objects also require a corresponding change in the XMTO.

XMTO! There's a new one :D

As you can tell, the source code knows very little about either XMTO or XOBJ. I can't see anything in the wiki, either. However, objects are being moved back onto the lot, including multi-tile objects, with identical changes to the coordinate processing in OBJT, XOBJ and XMTO. I suspect that I should add the same changes to the coordinate processing in FPL, ROOF, and WGRA, which also process individual coordinates, instead of arrays of values.

Unfortunately, I've also started to see the window problem that aelflaed documents in her thread "Lumpy Shrinker - Basegame, LA 0.1.3, LA 015". At this time, I suspect non-flat terrain, so this may not be too serious. [Update:] Forgot that the window issue is solved by saving, exiting the lot, and then reentering.

In the interim, I have applied the same code changes to all three of the Animatable OBJT coordinates, even though I'm occasionally seeing some very odd "coordinates" with some lots and objects - I suspect that the LA isn't parsing those correctly.

I have nearly finished the cAnimatable and cObject OBJT analysis. One of those coordinate and rotation sets appears to refer to the *previously* saved position of the object! Others don't change, while others change as expected to reflect current position. What I will do is upload as a doc here again, and not update the Wiki until you are satisfied (by having tried it on the LA) that the breakdown is not contrary to something you can see happening in front of your nose as you test.

Thanks for this reminder, Mootilda. Saving and re-entering the lot from the neighbourhood screen fixed the window.

Looks like the "move objects back onto the lot" logic won't work for WGRA - the game gets terribly confused and removes all of the walls that were touched. I wonder whether the correct thing is to delete the excess wall units.

[Update:]Somewhat similar problems with FPL (fence post layer). The fence posts are moved back onto the lot correctly, but seem to become undeletable, possibly because they are disconnected from the fence rails. The fences themselves remain off-world. The Trellis fence, in particular, seems to stay undeletable even if the lot is subsequently re-expanded. So, perhaps all FPL and WGRA which are moved off-world should be deleted instead.

Note that the walls and fences seem to maintain their off-world position, so that expanding them later leaves them where expected, unlike the object logic.

In any case, we can try the object off-world logic without making any change to the wall and fence logic - although ultimately we may need a solution to avoid crashes.