OK, this makes sense to me. Here is my understanding:

- When a lot is modified using the "build" menu and then saved, the game attempts to regenerate the 2D and 3D arrays. The game was clearly unequipped to handle the oversized lot. (FYI: This is why the LotExpander requires the lot to have been built on; it expects those arrays. - Aha! I just realized that I could probably fix the LotExpander so that it would be able to expand completely empty lots...)

- Unless a lot is modified using the "build" menu, the game will usually save without trying to regnerate the information in the arrays. This explains why you were able to save your family before building.

- I have always assumed that the game has a strict rule about lots being a maximum of 6x6. If you use SimPE to open "Texture Image" in the Resource Tree and [lot id]!terrain_txtr in the Resource List, you will see that each lot is "allocated" a 6x6 space and the (rotated) lot is placed somewhere on that 6x6 area, based on U11. You can see this in the pictures from my discussion of U11:

http://www.modthesims2.com/showthread.php?p=1778032

I'm not sure why, but the pictures under "Texture Image" convinced me (more than anything else) that the game has a strict limit on the size of the lot.

I wonder whether there is any way to use the fact that the game doesn't regenerate the lot arrays unless the build menu is used?

Update:
I just tested this and even moving or placing furniture can cause the 2D and 3D arrays to be regenerated.

I didn't build on the lot before using the expander! I must have missed that instruction. I did however go into it to get the mailbox etc placed before expanding. Do you think it might make a difference if I had built on it first?

Inge,

I thought of a couple of other useful tests with your 11x10 lot with the wall at the very edge:

1) What happens when you try to add a roof? Hopefully, the game won't crash.

2) What happens if you try to build on the lot? I assume that you can continue to build normally, except around the very edge of the lot.

No, I don't believe that it will make any difference. If the arrays didn't exist, then the LotExpander would have failed with an error. This instruction is from Andi's original upload:



If you changed the terrain, that probably counts as "building". I think that almost any tool from the "build" menu will make the game generate the arrays. Moving the mailbox may have been enough.

I did try building and saving on the places I was allowed to do so, and there was no problem. I did not try colouring the walls, and one side of each row house will probably need a one-tile dead space and a dummy party wall or else the party wall will flicker where both lots have one. Still I think this will still look a lot more authentic than the larger dead spaces we are having to use now.

As for the roof, I was assuming the structure of the house would be fully completed before reducing the size. I can't build on that edge any more now, since it is regarded by the game as within the 2-tile exclusion zone. So the player would design a terraced house, build it, chop the sides off and then take it to the bin and place several of this same model of house side by side.

WRT the roads, so far I have spotted that I think one of the SimPE labels is wrong. I built a flat terrain with a 4-tile long road and nothing else, and am analysing that.

I believe that this is difficult to get right. This is why I'd like to add the ability to decrease the lot size in the LotExpander. It is also why I suggested that rotating an existing 1x1 lot would be easier than creating a brand new 1x1 lot.

Were you using a completely empty base game lot?

It's becoming very clear to me that "Orientation" is the orientation of the lot in the neighborhood and U11 is the orientation of the lot within it's allocated space (which is really an indication of how to interpret the lot arrays). When you first place an empty lot, they will be related. However, as soon as a lot is rotated, the two values diverge.

This explains why different lots in the lot bin have different "preferred" directions; ie, where the arrow for the road points when a lot first comes out of the lot bin. I've attached screenshots of 3 different Maxis pre-made lots coming straight out of the lot bin - without rotating them.

It's really funny that EA decided to have two different orientations: one for the lot within the neighborhood and one for the arrays within the lot. Things certainly would have been much simpler if the lot array was always facing in one direction.

The only thing that I can see which is actually affected by the U11 value is the sunlight. It would have made a lot more sense for EA to get the direction of the sunlight from the neighborhood orientation and then the lot arrays could have always faced the front of the lot. Then, it would be really easy for us to choose the direction of the sunlight.

Of course, this would have destroyed my "rotate a lot" technique.

niol,

I wanted to ask whether the stuff that I've been posting is the kind of thing that you were looking for, or whether you had something else in mind?

I'm afraid that the question was a bit too "fast"... I don't know what you're asking.

Here's the most likely explanation for the crash:

EA / Maxis has allocated one or more fixed-size 6x6 arrays for the lot. If too much lot information is written, then it overwrites something important. Of course, a good programmer who wasn't rushed would have coded for this possibility, so that the program wouldn't crash. Crashes are so frustrating and much harder to debug.

I suspect that the people at EA are always rushing to get the next Game / EP / SP out the door, so they didn't have time to protect themselves against us modding these files.

So, was your lot smaller than 36 total neighborhood tiles? If not, you might want to try again and see whether a lot which stays within the 36 tile limit crashes or not. It might at least let us have oddly sized lots (1x36? 2x18?).

Oh, and should I leave the link for the unsupported version without the size checks? It's dangerous to use, so I'm tempted to delete it, but if other people think that it's useful to have around, I'll leave it here.

Lol Mootilda,

As for the unsafe version, probably just keep it on this thread with warning. It's definitely nobody else except the users' fault while it opens up the possibility for the willies to try things out.

As for the "cap", I meant to add some limits on how the lot be affected by default over-writing.

The quote in post 108 was from a much older post much earlier than your instruction and info posts. It can still be valid coz there're still more things for me to learn here... But, I'll try to catch up more things...


As for the array and lot orientations, many simmers and modders always wonder why Maxis did not corelate/extend the neighbourhood sunlighting and shadowing to the lots. But according to a post by a parent of a Maxis temporary staffs, it seems to me that Maxis has a "big" list of contract workers. The insufficient time scheme and poor inter-communications between these workers may just have done their own arts and the coordinators and/or the managers may have tried so hard to pull the things together.

Even the material shaders, sometimes, I wonder why they didn't just simply make out mutual common standard material for most if not all types instead of presuming that many material possibilities are impossible or unnecessary. Then, with preset limits to variate some common ones to save the check points. After all, it might be practically impossible to re-construct the whole hierarchy due to the rushes?
I guess there're a bunch of coders working on different things at the same time and occasional coding conflicts seem inevitable. A fast fix is often encouraged yet not often the best or even much better solution.

Just think about that they have to release the EP or what with the obvious bugs.
It seems so hectic. Or, Maxis knows the simmers will buy it anyway however the release is so bloated or full of bugs.

I can be sure quite amount of TS2 graphical designers for the texturing didn't know they can save quite amount of textural resources with repository recolouring by controlling the diffusion scalar. Let's think of Nero's Smartstart interface. So as the TS2 meshers "couldn't think of how the subsets should be better separated for more efficient, more detailed and easier recolouring. Probably, they weren't given sufficient time to sort things out clearly.

I assume if they did, probably at least a quarter of the space can be saved.

And if they implement more on the masking, all those masked textures could have been repositorily used that saved further space resources yet maybe increasing the computation load a "bit".

After all, I want Maxis to concentrate on their qualities rather than to lock up certain infrastructures for inhibiting non-commercial modding. It's modding that helps a big part to sell the game.


Oh well, for the 1x1 lot, Andi said certain infos have to be cut off, and this I don't quite get. Was he saying what to do or just explaining why we do so based on what we believe we know? I missed the time to ask him further coz I got distracted by other things at the time.

Sometimes, I see there're some other offsets with similar values or even the same value to be changed. They're itching me that I keep on wondering if those can or should be changed like the stated, esp. for those very close to the stated ones. You know, that very instinctive assumption that they may be related.

Let me try to explain what I believe that Andi is saying:

Each of the 2D Arrays, except Instance 0x3B76, contains (Width X Height) objects of size 16 bytes, where Width and Height are stored as 4-byte integers at bytes 81 and 85 of each 2D Array. In a non-empty lot, you would have to determine where each row of the array (height value) started and ended, so that you would be certain of deleting the "correct" objects to reduce the size of the lot.

However, in an flat empty lot, all objects in the array should have the same value, so it doesn't matter which objects you delete. The only things that matter are that you end up with the right number of valid objects, which is (new Width X new Height), and that you replace the old Width and Height at bytes 81 and 85 with the new Width and Height. Andi also gives you the calculation for the new Width (X * 40 + 1) and the new Height (Y * 40 + 1), where X and Y are the Lot Width and Lot Height (for example, 2x3). The U11 value determines which of X and Y is the Lot Width and which is the Lot Height, but you can probably figure out which is which by looking at the initial values.

2D Array Instance 0x3B76 has different calculations for the Width and Height, and stores a different type of objects, but the principles are the same. you need to reduce the size of the array and replace the Width and Height with the new values.

3D Arrays are also very similar, except that they have a Width, Height and Depth. With a non-empty lot, you would have to determine where each layer of the array (depth value) starts and ends, and where each row of the layer (height value) starts and ends, to ensure that the correct objects are deleted.

However, since this is a flat empty lot, there is only one layer (Depth = 1) and all of the objects are identical, so it doesn't matter which objects you delete, so long as you end up with the right number of valid objects, and as long as you replace the old Width and Height with the new values.

3D Arrays are further complicated by the fact that each 3D Array contains objects of a different size. However, Andi has provided a table of the 3D Array Instances and the size (in bytes) of the data that each Instance contains.

Does this answer your questions?

Please note that I have not verified Andi's data, although this information is available in the LotExpander code. I know that there are other record types, but I assume that Andi has listed all of the record types and Instances that exist in an empty lot in the base game.


If you could tell me the name and / or ID of the records in question, I might be able to answer your questions. Many of the record types have the record name, such as "2DArray" and "3DArray", embedded in the record.

I do believe that Andi is relying on the lot being empty and flat to reduce the complexity of these edits.

Just a quick observation note:
I've rotated the 2 mailboxes on a residence lot so they're not paralellel to the roads.
When there's a family in the lot, no changes in the a cab direction.
Then, I try with an empty lot, when I move in a family, the cab move at right angle on the lot rather than on the road.
And ten, I call the services and the cab again , they remain on the road.

So, it seems the mailbox only affect the transportation when a family moves in a lot.


Mootilda,
Thanks very much... I now get it better.
I'm gonna retry to edit the lots more to see if I can get it done... again...

Yes, I started with a 3tile wide lot, which is what I used to make the 12 tile long lot. Then later I decided to try expanding in steps. I got to 3x6 fine, then expaning to 3x7 caused the same crash. I think I will try over-expanding sideways too. If that worked better it might point to a field that wasn't updated properly when expanding backwards. I am constantly being surprised by discovering obscure flags Maxis leave lying around in unlikely places. May be one that means "allow oversized lots" lol.

WRT keeping the unlimited lot expander - It's in this research thread isn't it, rather than the tool download thread? I think it's justifiable to keep research tools here that might be dangerous - it's not going to be listed with the MTS2 downloads.

Road research: I am not sure if it's worth putting much effort into researching the road data, unless you think it will help the lot expander directly. The thing is, it's going to be as impractical to ask people to edit hex to add a road as it is turning out to be to edit the hex to shrink a lot - ie one slip and you're lost! Someone would have to write a graphical interface to it. And since there is always the method of editing the hood in SC4 and reimporting it, a road editor is no priority.

The lot shrinking is a far more useful thing to be working on, as I believe it will give us successfull row houses. Even if the row houses are not as useful after all, there are reasons people might want to shrink a lot so it fits in a particular location. Another good use for lot shrinking would be when you have two adjacent lots that both want lowering to match or have a river running along the bottom of them. At the moment you just can't get rid of that ridge between them. You can expand them both to smooth it out, but at the moment you can't shrink them back to their original size so they have to remain overlapping and flickering. I am sure that everyone would find a use for getting rid of that sharp ridge, and with this use, there would be no extra objects to get rid of. You could even have a lot stretch mode that did not move the portals, which would be used by people solely planning to immediately shrink the lot back again.

PS I was wrong - portals do have their own placeholders after all. I am beginning work now on an object that will help to reveal them and make them movable.

What Inge had done with her lot, that is what I ment with the Lot expander, to ajust it to make this a general, alone not with individual tile's but with hole blocks of 10 tile's at the same time, I've got 2 buildings already waiting to be ajust to be smaler... to a 1x1 lot, with the walls to the edge... Great work Inge, and Mootilda for trying to make a tool for this... If I had the skills than I didn't need to ask it to you guys and girls... But I don't have the skills to do this myself... many thanks from me to all of you...

Where is the lot expander.

http://forums.modthesims2.com/membe...ad.php?t=175884

Interesting information. Did you do anything on the lot (the one with the newly-moved-in family) between calling the cab the first and second times? Specifically, did you use anything from the Buy - F2 or Build - F3 menus?


I'm glad that I could help.

I was thinking about this last night and realized that I've been making another assumption, based on the LotExpander code and Andi's initial instructions for creating a 1x1 lot. If my assumption is incorrect, then decreasing the size of an empty lot might be much easier that we believe:

I wonder whether we actually need to delete the excess objects from the arrays? For most, if not all, of the record types and instances, the array is the last thing in the record. There is a possibility that the game is coded so that it just ignores excess data in the arrays. If so, an empty lot would be very easy to decrease in size. If not, the game will probably crash right away, so it would be wise to run any tests in a window.

Sounds like the worst possible scenario for us... the game expects a maximum height and a maximum width, rather than just a maximum size.


Wouldn't that be wonderful? It's clear that Maxis is too rushed... they work on a lot of things that don't get finished, and they don't have the time available to clean up afterwards.


Yes, this is really research for a separate tool. I don't believe that it will help me with the movement of the road at the front of the house, from within the LotExpander.

Have you found that my "adding roads to a neighborhood" technique worked for you? The primary problems that I can see with expecting people to use that technique:

1) Not everyone has SimCity (although I bought it recently at EB Games for under $10).

2) Not all existing neighborhoods have associated SC4 files.

The Life Stories neighborhoods are a prime example. None of the three SC4 files that Maxis included with the game actually match the terrain for any of the three included neighborhoods.

It's possible that we may be able to extract the SC4 information out of the neighborhood package. I tried one quick attempt when I was first trying to add roads to existing neighborhoods, but the attempt failed. Another area for research.

3) The technique destroys many / most of the neighborhood decorations, although there may be some as-yet-unresearched way to get them back.


Yes, I also believe that shrinking a lot should be a fairly high priority.

Unfortunately, it's a major code change. I've been trying to get some of the smaller easier changes out of the way first.

Of course, nothing is as small and easy as I hope - turns out that the Lot class isn't actually working - when I tried fixing the Lot.Top and Lot.Left, I found that the fields weren't being updated in the package. When I went to look at the Lot class, it's clear that it needs a major code cleanup - it's doing way too much work and failing miserably.


I think that this is a great idea. I need to fix the portal logic anyway, so this should be an easy addition.


Would it be possible for you to explain placeholders to me, or to point me at some additional information? I am such a newbie when it comes to modding.

Lol, probably add a warning to the download thread to discourage spammers or "thankers" to post here.

I don't mind if there're occasional irrelevant or repeated suggestions and I do that when I look back , but just hope to keep here as topic-oriented as it can.

After all, that is my poor tolerance on certain things.


3 screenshots to tell a property about the portal.
I ordered a sims to call delivery, and the trucks stopped on 1 side, but I moved it to the another side with the moveobject on cheat to confuse the routing a bit.
The delivery sims seemed to be confused for a while but then finally retrieve a new routine to reach the truck and drive the truck in the same direction on the another side of the road!

Eg2:
a firetruck was called and I U-turned the truck, and it drove along the opposite road way to quit.

eg3:
the bug truck was violently moved to the lot's buildable area and it still works.

So, the portal only calls for the service vehicles to load in the lot at some predefined common positions, but probably at least doesn't require the vehicle to be exactly at a particular location in order to "leave the world" just as we see in the atypical driveway instances. Being able to mod the lot orientation can also enable more ways to place driveways and more. I thought bhav was the only key to it.


As for deletion of objects in the arrays of both 2D and 3D,
The up-messed lot is an instance of that. Yet, I could have made more than 1 mistake during that trial..

I 'm gonna try a copy of it and remove all the arrays after the stated offsets and the depth offsets for 3Ds (as long as I figure it out) to see what will happen after my excercises... :D

STR# 0x85 holds model names. To get the object to show the model named in String 1, you code it as "Stack object's graphic :- 1". EA have a model called nullModel which is sort of just blank space. They also created a model called "placeholder" which is a square box with an arrow on it. Most of their portals have placeholder in string 2. I had to make a patch to add it to some invisible objects I also wanted to see. Quite simply my portal revealer tells the portals to display their other model. And when you've seen enough it turns them back to their invisible one.

There is a menu for when your lot is populated, and also so you can use it on unpopulated lots, when buying it all portals become visible and to hide them again you sell the object. I can upload it soon.^H^H^H^H in fact here it is now.

Edit: Updated portal revealer in next post.

Mootilda, here is the test terrain you asked for. It has all sorts of dips and wobbles, and some beach. Ask me again if you need any special feature.

I have also uploaded the patch to make some of the go-here tokens revealable, and an updated revealer, which now includes the wave effects.

I was thinking... you were going to try and get the expanded bits to follow the countours of the existing terrain... It occurred to me that you don't have to do that for every vertex, only the very edge seams of the expanded lot. The player can easily contour the in-between parts of the new bits to blend in as they wish, the only thing the player would not have in their power is to get rid of the ridge at the edge, which won't happen any more if you are able to implement your idea.

BTW I also managed to use a beach portal to get my sims using a standard waterside lot as somewhere to swim. But I had to make a couple of small tweaks to it so they didn't test if it was a beach lot! I can upload a customised beach portal elsewhere later.

Excellent. I am just getting to the point where I will need to do some testing of my new logic. This should really help. Thanks so much.


Looks like this will be very useful in determining what to do with the portals.

I've completed the code to keep the lot in place in the neighborhood. At the moment, I'm finishing off the logic to get the expanded terrain from the neighborhood package. Then, I'm going to take a look at Tsouka's problem with the paintings; hopefully an easy fix. I think that the portal logic is a pretty small change, so that's next. Then, decreasing the size of the lots, which is a major code change.


Yes, I thought about this, too. However, the smoothing logic was a breeze, thanks to a friend of mine who knows a lot more about game graphics than I do. So, it's too late... that part of the logic is already done! The only problem remaining (I hope) is rotating the lot terrain from the neighborhood package based on U11 and Orientation. I'm really hoping to have this done very soon.


That sounds like a great thing. I'm sure that there are a number of people with non-Bon Voyage beach lots that would love to have this fix.

Were you able to make the lot < 6 deep? I just can't believe that Maxis only released those huge beach lots.

Well it wasn't a beach lot, just a small one that I had first created on a slope so that it became "flooded" when placed near the sea. So what you can see the Sim swimming in is the old-style sea water. It would be easy to make buyable waves too. But what I can't find yet is how the beach lots make the sea water reflective - water seen from non-beach lots is that dead looking blue gel. Niol is the expert on water shading, he might be able to fill in the missing information for me

Research topic moved over from the LotExpander thread:
http://www.modthesims2.com/showthread.php?p=1783030


There are several 2D and 3D arrays that Andi didn't understand well enough to determine the correct format. One of these, he just sets to zeros. I looked at the array briefly when I first took over the LotExpander, but couldn't determine the format, either. Since the LotExpander seemed to be working, I thought that there were more important things to spend my time on.

However, if the problem with custom paintings is caused by the LotExpander, then my suspicion is this misunderstood record instance.

If someone wanted to help me with this problem:
http://www.modthesims2.com/showthread.php?p=1782710
they could try making a lot with custom paintings, similar to the ones in the bug report. These portraits were created within the game using 'Paint Portrait of...' on the easel. Delete the 3D Array (0x2A51171B) Instance 3 using SimPE, then let me know whether the custom paintings are still there. If you can determine the format of this 3D Array Instance, so much the better!

In general, I could use a list of what is stored in each of the 2D and 3D Array Instances. This technique is a really easy way to compile such a list:

1) Create or find a lot with interesting features. Backup.
2) Using SimPE, delete one of the 2D or 3D Array Instances.
3) Run the game and see what's missing from the lot.
4) Restore from backup
5) Repeat for all 2D and 3D Array Instances and other interesting lots.

I'm imagining a table similar to the following:

Of course, eventually this information should make it's way into the Sims2Wiki:
http://www.sims2wiki.info/wiki.php?...InternalFormats

I intend to update the Sims2Wiki when I have a break from the LotExpander, but I'd be very happy if someone wanted to do some of this work now.