Thanks for all the explanation. Is there documentation somewhere that I can read up on? I took a look at the wiki and the info was pretty sparse. As for it not being required to change the size of the lot, I knew this - I was hypothesizing that maybe the hard limit was stored here. If that's not the case, then maybe I should start petitioning to Maxis about making an expansion that unlimits lot sizes...

Other than the wiki, I don't know of anything. I've been muddling along with a combination of Andi's original LotExpander code, the wiki, and using SimPE and the debugger to look at what happens with various lots. I'm afraid that it's very hit or miss.

That's why updating the wiki is one of the things on my list. There's a lot of information about record formats embedded in the LotExpander code and I'd love to make it available to a wider audience.

I really appreciate it, too. As I've mentioned before, I'm a computer programmer who writes tools that other programmers use to write programs. I'm not used to talking about techy stuff to non-techies and I really want to be sure that the things that I say make sense. Let me think about the rotation issue some more and see whether I can come up with a better description.

Here's the difference: the front of the lot always needs a road, but you can have a road on other edges of the lot, as well (ie, corner lots). I suppose that's why there are two different values.

I agree that the sun direction is a really good way to think about U11. Would you believe, I never even thought about lot rotation that way until you asked about it? I honestly never even noticed the sun, except that I hated how dark the houses looked when I turned on shadows. I suppose that's why it's so nice that this group has such a wide variety of people - everyone has their own way of thinking about things.

Think of it this way. Here's a picture of a house from Pleasantview, rotated based on the U11 value:I say "the road is at the left side of the lot". SimPE says "the house is on the right side of the road". We're both describing the same thing.

Hmmm... good question. I can't think of anything much that Orientation matters for, outside of programming the LE. It just tells you things like "the Broke house is facing in the opposite direction from the Goth house" and "the Caliente and Lothario houses are facing in the same direction". Not terribly interesting.

Orientation just describes what you see when you look at the neighborhood.

Finally, I caught up!

[Thread Splitting Organisation]

First of all,I guess we really need gather the relevant pieces of infos back to some more concrete posts or threads after moving to a private forum... I felt overwhelmed with so many aspects are being filled in the same thread.

It's no longer easy to track back some reference posts made all the way back...
we've different aspects like:
1. LE/LA testings for different versions & its UI
2. lot rotation/road rotation/neighbourhood rotation
3. lot resizing with different techniques including with LE/LA and manual editting
4. other related lot moddings

Maybe, we need some reference TOC to help organise these infos and reference posts before the new-comers get really lost about where we have been so far. They can't be blamed for not reaing all the materials when they're mixed in the sea.


[Lot -shrinking]



1. the lot package is empty when the lot is made in the neighbourhood mode until you enter and make a change and save it...

2. you'll need to use a QA version of SimPE to edit beach lot, or you'd better use the hex to edit the beach lots. The EP5 version of SimPE plugin view is not EP6-ready for any editting. I had to use the hex editor to do beach lots.

3. a 3x5 lot can be 6x3 or 3x6 in SimPE or LE/LA dependent on the lot orientation (this you need read back the graphs I linked for you in another post.) Why 6 instead of 5, that's because the road is actually a part of the actual lot.

4. In my tests, flat floor tile based roofs are working well just like the flat roof tool roof. So, these tests seem to resonate each other.

5. that trick only work for the template sizes already existed, and that's why if we hack into the template system, we can make out more templates for this usage. There's nothing to edit for the lot package file in this trick coz it all depends on the input values in the neighbourhood package file.

6. There're only 8 templates beach lots : 60 x (30, 40, 50, 60) for both residential and community lots: As I earlier said, the lot-resizing trick @ neighbourhood package file before any lot package modification can only work with the template sizes already existed. I stated this out in the hope of 2 things:
a. to solve some of the problems on the terrain formation for those sizes already existed.
b. to research more on how this templating works that may in turns lead to a way to use this trick for other sizes.
Presently, I don't see it's as simple as to make a new template of other sizes as a test on 20x60 failed in a test, but it needs more instances to increase the confidency of such conclusion.



I think the make of a lot in the neighbourhood mode will only take care of the editting on the neighbourhood package file. Entering the lot. making a change and saving the lot is the actual step that initiates the game engine to compute and copy the specified arrays and data into the lot package file. Seemingly, the terrain data will depend on the neighbourhood package file as well.

As for the gash and mask, I guess the "mask" size depends on the w and H values in the neighbourhood package file.


[chit-chat]

pegasus,

May you attach the lot package? I feel I'm feeling lost missing out of a lot of contexts for what you're trying to show.


[Rotations: all 3]



I think you explain this pretty clear. there're 3 rotations, one for the neighbourhood itself (the sunlight bias, left, top, z), one for lot on neighbourhood (U10, road rotation?), one for the lot itself (U11). So, the 2 autorotations plus the 1 combo rotation. That results in 64 or 4 to the power 3 possibilities...? :D

To clear the orientation things out, just make out the major 4 possibilities in a neighbourhood.
May also try on different neighbourhood for further confidency.


aelflaed,

Mootilda only rotated the graphs from Andi's one to view the rotation according to a specified axis. so, basically, they're showing the same thing but with a different viewpoint.
Mootilda also describe the direction based on SC4, and it's known that the rotation is reversed in TS2, so you may see why the left and right are switched betweemn these 2 interfaces.


All,
the shadowing seems to be an after-effect of the sunlight bias. they're always opposite to each other in terms of direction.

Would I have to cause a crash in order to get a read-out? Seriously though I am sure this would do fine but you'll have to give me a hint about how to get the info out of it.

Yes, I agree. Messy job, though.

How about we take one type of message each and try to gather all the reference material for that into one post? I should probably collect all the rotation stuff, in that case.

Mootilda, I think your explanation of the orientations was pretty good really. I still fail to see what use the Orientation record is to us, but that's partly beside the point. It does need to be mentioned with the U10 and U11 stuff, so people looking at SimPE will know that the Orientation button isn't what they're looking for.

Yes, I know, and I could understand both - I keyed into Andi's viewpoint better in that instance, that's just an individual thing.

That's pretty clear - put that in somewhere!
I even altered the Orientation on one lot, a while ago, to try and see what changed. I'm pretty sure the lot did nothing different at all. Including NOT moving to a new spot in the hood. Shouldn't something have been different? I guess it doesn't matter for currrent purposes, but it niggles.

OMG!! What a mess! I have just taken a good look at those OBJT resources and it looks like they list every CRES node or mesh subset or something. There's not much simanticky stuff going on in there. That probably explains why MaxoidTom described the tile system as "legacy". At first sight it looks like the game has turned all the objects into a true 3D world, rather than the view being built up from an objectgroup-referenced array. Anyway this is first impressions - now I have to put *one* object I am very familiar with onto an otherwise virgin lot and see just what I can spot with my object's mark on it :D

Later: I placed a tiki loveseat on centre back of the smallest standard lot size, virgin lot, virgin 100% flat hood (made with one tone greyscale heightmap).

One of the OBJT files (one of the large group of OBJTs) mentioned lead tile OBJD name and various facts about the materials and slots.

One of the XOBJ files contained the GUID of the lead tile OBJD but had no decipherable words.

None of the resources of the lot file appeared interested in the other tile of the loveseat, nor the "master" (out of world) OBJD either by name or GUID. NB the lead tile OBJD was (as usual) the one with the relative coordinates of 0x0000 otherwise known as "0,0". Looks like if you were hoping to move on-lot any escaped tiles of multi-tile objects that may not be possible.

PS I expect to find some way of cross-referencing the GUID to the Object ID - possibly in the XOBJ. I need to try and find out what the Object ID of the loveseat is, so I suppose I need an error dump.

niol, you said: "I don't see it's as simple as to make a new template of other sizes as a test on 20x60 failed in a test, but it needs more instances to increase the confidency of such conclusion."

Are you saying you tried to make a 2x5 template of a beach lot? How did you try?

I'm not sure what you said, but I want to make sure you understand: I have a 2x3, 2x4 and 2x5 beach lot made with the LA which are functioning perfectly so far. In fact, I'm thinking I should post them and see if they work for others on their systems. How to do this?

I think that I made a mistake when this thread and the LE thread were spun off from Andi's original thread. At that time, it probably would have made more sense to create a new thread for each interesting topic. I was concerned about trying to keep up with a number of different threads, but now I believe that this all-in-one thread is harder for everyone to keep track of.

I noticed yesterday that the average thread has 10 to 20 posts. We have over 1000.

So, in the spirit of "better late than never", I wonder whether we should create some new threads? As we have time, we can either copy our posts over to the appropriate threads (and then delete them here), or we can create a TOC in the first post of each thread which points to posts here (and any other relevant threads). We might even be able to do both - if we could come up with a reasonable list of posts per topic, one of the moderators might be able to split them up into separate threads for us (I have no idea how difficult this would be, but it may be worth asking, so that the posts remain in the correct order).

Please note:
I'm not asking anyone to do anything yet, except to brainstorm on good thead topics and possibly gather together a list of relevant posts for a particular interesting topic. Oh, I suppose that there's one other thing that we can all do... Let's try to keep each post to one topic. If you put the topic of the post into the title, it should be easier to split these off in a day to two, once we've decided exactly what we want to do. If you have time, you might even want to add titles to your existing posts.

Since we're already creating a hidden private forum for the LA test versions, I wonder whether it would be possible to start all of these other threads with that usergroup as the owner, so that no one person is overwhelmed with the task of maintaining the TOC? The "Lot Modding Group"? "Lot Modders"? "Lot Adjusters"?

The list of current members is available at:
http://www.modthesims2.com/showthread.php?p=1815911
I'm still hoping that a few more people will want to join, but I suppose that we've got a good base group now. Thanks again to everyone for wanting to help with this testing.

We won't start the threads now will we? Wait till we've got the forum? Then, when the LA development has finished, perhaps Delphy can throw the threads back into the modding forums so everyone can benefit from anything we've discovered.

I'd prefer to have the downloads private, but the discussions public. Why? Well, because then someone like dizzy can download the crash logs and look at them, or someone who has no interest in testing can explain what an access violation is and which files are likely to become corrupt.

It would also allow us to find other people interested in testing these dangerous features. If no one knows that we exist, how do we recruit?

Then it seems a bit of a waste to take up a project forum on MTS2. I could easily set up a temporary download area on one of my forums, just to hold the test downloads, and it won't inconvenience Delphy. Just post a link to it each time you upload one. It would need the testers to register at the forum of course, and be put into the appropriate usergroup.

Else to make it *really* secure I could have a new forum set up in a couple of hours and set up the testers' accounts manually. I can just scrap it when this phase is over and the app is published.

Later: OK I found the ObjectID/GUID cross-reference in XOBJ - I knew it had to exist somewhere lol. ObjectID appears at 0x060A and 0x1E08 (duplicated not split). The field is probably allowed to use the next byte in each case too, though in the examples it was 00 (which it would be anyway as there were not many objects on the lot). The GUID appears at 0x070C-070F. The OBJT instance number is the same as the ObjectID.

Which bytes of the XOBJ should I be looking at for grid coordinates? I can't see anything that looks obviously like one.

Yeah, I also think the discussion should stay open to the public for the same causes Mootilda has mentioned.

The only thing kept private should be the download.


As for new threads for different topics, I guess we can go both approaches.

1. We need some concrete topics defined first. The ones I typed are only my suggested divisions, and I need you all help decide on them.
2. we may gather the post links to the first post we make on those new threads. May update along the post gathering on that same first post of the poster. True, some posts have multiple topics but they are still linked for each topic.
3. help one another to check if those linked are really relevant. and also combine them together.
4. probably move the relevant contents to the new threads. (dependent how we feel like to do so by then.)

Well I want the discussion open too, not just to benefit the development of the LE but to let people read information in general. But what's Delphy going to think about setting up a private forum and there's only one post in it with an attachment? That's why I assumed the plan was to post the discussion in there too. As far as I am concerned I have always been of the opinion that it's fine to post the test releases of the LE openly and tell people it may destroy their computers, their lives and the universe and let them decide for themselves. However I respect Mootilda's right to make the decision.

So far, it sounds like we're all in agreement about this. Good.

I hope that I made it clear that I just want the forum so that I can restrict access to downloads, and not for any discussion. Here's my initial email to Delphy:If you think that I haven't been clear enough, please let me know. I can try to make the purpose more clear when I submit the group of users.

Thank you. While I'm not perfect and may occasionally put out a version with bugs, I really prefer not to widely distribute a version that has serious problems. I'm hoping that this is a good compromise, until we get something which is more stable.

That was me I believe. Yes, this is so (incredibly annoying).



The sun direction is somehow hardwired into the lot at the time of its creation. I know of no way to change it afterwards. This goes for both the in-lot view and the impostor (neighbourhood view). Rotating the lot doesn't do anything (I assume you mean "rotating" by normal in-game means: picking up the lot and turning it around) -- every lot has its own private little sun, so to speak.

If you look at this screenshot for example, you can see that the buildings have the sun coming from different directions (e.g. the two brick houses on top right of the pic). On the screenshots further down the thread , you can see that the sun is coming from the exact opposite direction inside the lot.

Hope this helps to answer your question.

This test version of the LotAdjuster doesn't do anything, so don't bother to download it.

That is, unless you want to see everything that the LA knows about the OBJT record format. Then, just double click on the LADebug.bat file and pretend that you are going to expand a lot. When you click on the Next button after selecting the expansion, a log file will be written out in LADebug.txt. Then, the LA will abort and your lot will not be changed.

Inge, this is for you. I'm sorry that the variable names are so terse, but if you can determine what's in any variable, I'll fix the LA with the new name. I hope that this will be helpful in trying to determine the structure of the OBJT record. In the interim, I'll try to get you some information about what's in the XOBJ record. Good luck!

Oh, if anyone determines that the LA is using the wrong data format, just let me know and I'll fix it.

Thanks. I just couldn't believe it when you first told me, but this looks like a poor design decision on the part of EA / Maxis. The sun direction should definitely be related to the orientation of the lot in the neighborhood, so that all lots which face in the same direction have the sun in the same place.

There is only one way that I know of to change the sun direction - write a program which rotates every single 2D and 3D array for every record type in the lot package. Ouch! As painful as this would be, I'm still considering writing this code. It's just low on my priority list.

Yes, thank you. I appreciate your help.

Let me know if you have any problems figuring out how to get a log from the test version above. Or, if there's anything else that I can do to help you.

Now, perhaps you understand why I've been so reluctant to touch this piece of code. This is one messy record format. I'm really hoping that the OBJT log will help you to figure out what we need to do with those out-of-world objects.

The single OBJT record type is actually:
MOBJT - 6F626A74 - Main Lot Objects
The multiple OBJT record type is:
OBJT - FA1C39F7 - Singular Lot Object

When looking for the portal information, the LA does the following:
- Use the MOBJT record to get a list of the following information per object type: GUID, descriptive string, and a reference number. There's a bunch of extra hex bytes in the record which the LA ignores. I can give you some additional information about the MOBJT record structure, if it's helpful.
- Use the OBJM record to associate each GUID above with a list of XOBJ / OBJT instance numbers, via the reference number. The OBJM record basically contains a list of correlations between reference number and instance number; I can get you more information on this structure if it's useful.
- Then, the LA makes the changes to the XOBJ and OBJT instances that it found above.

If it would be helpful, I may be able to make a quick change to the LA code which would more clearly show the correlations above, by forcing all objects to pass through the portal logic with debug logging on. Please let me know if this might be worth trying.

Here's my suggestion: Wait until we have the dangerous testing group up and running. Then, upload your lots there. Everyone who has Bon Voyage will test them for a bit. If there are no problems, then post them more widely.

That way, we get a small dedicated test group before distributing them to the world.

Bytes 80-83 (0x50) and 84-87 (0x54). They are stored as floats (single), which is probably why you didn't recognize them.

There's some overlap here, but here are some suggestions for possible threads:

1) New LotAdjuster: UI and test version issues
2) Lot shrinking - all techniques
3) Row houses (walls on the edge of a lot) - all techniques
4) Lots > maximum size (6 neighborhood tiles)
5) Lots with sizes which are not a multiple of 10 (does this include lots < minimum size of 1?)
6) Rotation of neighborhoods and lots; sun direction; top, left
7) Standard road locations and associated pedestrian, car and service portals
8) Non-standard roads: lots with no roads, lots moved away from the road, lots built over the road
9) Beach lots, beach portals and waves
10) Internal record formats for neighborhood and lot packages
11) Creating a 1x1 lot
12) Modifying the neighborhood terrain; adding roads to an existing neighborhood
13) Correlation between lot and neighborhood terrain; smoothing the lot terrain, blue gaps and ridges.

You've all been very busy overnight.

Mootilda, just to let you know, I really think the rubbish bin is the most forgiving of the 'portal' (service?) objects. I can do more proper testing if you like, but I took care yesterday to place the bin in a corner, so it was surrounded on three sides, with the arrow facing to an inaccessible corner. The sim still used it fine, from the one access point remaining. The mailbox direction is obviously far more vital, both for the video and for general access.

I'm happy to have the test downloads posted wherever works for Mootilda. (Your request to Delphy looked clear enough to me). I don't mind where the discussion happens, either.

Non-techy here again - what is a TOC? It's probably obvious once I am told.

I don't know how this would work, but it sounds good if more than one person can keep things updated.

Would it be best to make just a list, by number, of the posts relating to a certain topic, or to paste each entire post into a document, to be re-posted later? I have half an hour spare, so I was thinking of beginning a rotation posts collection.

Table OF Contents?

That sounds fine, Mootilda, about the lots testing, just what I wanted to do.

Something a bit odd: While adjusting portals (to actually play the lot, I wanted the portals in the perfect positions). I noticed that the car portals sometimes had multiples, sometimes not. Why would there be more than the original ones and never as many as the beach portals that dispappeared without trace (which of course was my first assumption)? Next time I find this situation, I'll investigate it more