Oh, I think I get it - because the road makes six already, there can't be 1x6, because it would have to be 1x7 really. Never mind then.

MaryLou has finished her part, so I'll check those files and then work on the submission. Mind you, I probably need to do some housework first! Not much has been happening apart from computing lately.

I'll try to use the 124, Mootilda, and let you know what happens.

(edit) well, that didn't take long. Same error. What is it about my system? Once I get these lots submitted, I'll take out my BGS and see if that changes things. I want to start using the updated BGS anyway.

Yes, however I want the default behavior to be "good enough", since some users are pretty inexperienced. I don't want to require people to move the portals.
The neighborhood terrain should always be 128x128 tiles or 129x129 vertices.
I believe that the Pleasantview neighborhood is "rotated" from the default... Top and Left should start counting at the top left of the neighborhood. Rotating the neighborhoods to this default setting should make it easier to think about the Orientation and U11 values, since there is no additional confusion of a rotated neighborhood.
Interesting; these are the array coordinates. I wonder whether the additional tiles contain information which tells the game that the terrain is adjustable. If so, this may be a simpler solution to getting the neighborhood terrain than the logic that I have been using.
Excellent. It's nice to know that the game will do this for us, although I'm not sure that the LotExpander can use this.

Well, this seems to indicate that your installation is different in some way which causes the problem. I honestly don't know what the difference could be. Hopefully, when I install the BGS, I'll be able to reproduce your problem.

That's true...


That's probably due to the camera drifting when entering a neighbourhood?



That's true, and I'm gonna check out other templates...
It turns out that the other templates are normally as Andi's calculations. It's just these lot template from the base game are exceptional with +2 for wall graph...;
LotTemplate30x30.package
CommunityLotTemplate50x40.package
CommunityLotTemplate50x50.package
CommunityLotTemplate60x30.package
From EP2,
LotTemplate20x30.package
CommunityLotTemplate20x30.package
CommunityLotTemplate50x20.package
CommunityLotTemplate50x30.package
Seemingly, the newer EPs have their lot templates directly from EP2.


But it seems they still work well... Maxis tried to fulfill simmers the want to have more lot sizes. I'd assume the variant 32 for wall graph might have been spread through lot template cloning. Even the staffs didn't realise they used a variant for cloning.

Now I'm wondering if an integer just larger than 10 will
work anyway?
How does the wall graph affect a resultant lot?

At least some lot templates were made in desertoid terrain. The jpgs weren't trimmed.

A newly made lot without 1 saving is completely blank.
After a save, all those infos are stored in a lot package file.
altering the terrain will change the terrain values in 3d arrays.

Presently, I used a common lot template CommunityLotTemplate50x30.package that appear in EP2, 3 and5. I've no EP4 (won't buy without some reasons good to me.) while EP1 is not installed.

Just check the world database of lot templates of EP0 (the base game), EP2, EP3, EP5 randomly a few samples from different lot types and EPs.
The value right after the type 0x49ff7d76, can be either 3 or 4.

All EP2, EP3 and EP5 lot templates have no type 0xAC506764 (3D ID Referencing Files); 0xAC4F8687 GMDC; 0x7BA3838C gmnd; 0x584D544F Material Object?
The exceptions are :
CommunityLotTemplate60x30.package has all
CommunityLotTemplate50x20.package has 2 0x584D544F Material Object? (XMTO) files. So, XMTO can be unnecessary for a lot template?



Lots can have 8 or 9 0xFA1C39F7 objT and 0x584F424A Xobj regardless of if any EP or lot type.
Duplicate object in lots?

EP0 lots can have 8 0x0A284D0B WAll Graph regardless of lot type. All EP2 lots have 9 except CommunityLotTemplate60x30.package
CommunityLotTemplate60x30.package is cloned or directly from an old template but still work in EP2 or above?? So, what is important is the arrays and data computed from the game engine?

Some EP0 lot templates have txmt, txtr, gmnd files regardless of lot type. So, these files are unnecessary for a lot template?

The parallel file patterns in the lot template package files suggest EP3 and EP5 lot templates were likely cloned from EP2 or even EP1.

Oh well, the lot templates are messy but are seemingly working!
Indeed, they can show what may be unnecessary to be in a lot package file and what may work or not work.

Perhaps. I think that the default rotation for a neighborhood occurs when the neighborhood is first created. Someone at EA/Maxis may have just played Pleasantview before they decided to ship it; they could have just rotated it themselves. I think that all three of the original neighborhoods are rotated differently when you first install.

The important thing is that this is yet another orientation / rotation that can make things confusing. I believe that the easiest thing is to ensure that your neighborhoods are in the default orientation.

Probably, it's good to just make a new neighbourhood for testing to avoid Maxis modding...! :D

Also, I guess it may worth to gather some "saved-but-not-built" "empty" lots from various EPs for further lot comparisons to see how the various game engines modify the lots.

From the lot template, it seems the base game lots have more junks than the EPs in general.

Materials for lot package files are mostly defined as imposter bla blah blah or lotskirt blah blah blah.

Modding lot and neighbourhood files can help me understand more on how build tools work and how Maxis made certain materials work on lots but not others (game objects, sims, etc). Presently, I'm not interested in the family data files in them tho.

Seemingly after most default changes of a basic file type are realised, then it's the time to build and check for change in a given file type in a lot package file. :D
Maybe, a lot can be built in some ways thru SimPE somedays unlocking at least some of the presently "build-mode-impossible" reaches...
By then, a phenomenon called "mod the lot to build a lot" may happen. This can by-pass the current build tool limitations.


added:

I've altered the portal x and y values thru SimPE with altered values based on aelflaed's latest suggested values.

1 Service Start (1.5, 15.5)
2 Service Stop (8.5, 15.5)
3 Car Start (8.5, 14.5)
4 Car Stop (4.5, 14.5)
5 Pedestrian 1 (8.5, 10.5)
6 Pedestrian 2 (1.5, 10.5)

I failed to get portal revealer to show the portals up and worse, all vehicles can't show up. Only a police officer could get in the lot without the police car and a bartender walked in. Worse is that they were stuck in the lot. But, the mail-deliverer can enter and leave the lot safely.

After that, I delted all the portal Xobj and objT (0xFA1C39F7) files. and reload the game, enter the lot and save.the lot. In simpe, all portal x and y value are reset to -1..
The fire truck and the exterminator truck including the corresponding NPC sims get in and leave.

But, the police officer entered the lot before the police car got stuck fooling around until the police car reached when the police officer go lecture suddenly. But if I cancel the "be lectured", thepolice officer is stucked in the lot. If I le "be lectured", it goes with the police car.
all the other services just came and go.

Except the walking bartendet and visitors got stuck in the lot. Not until I bought a pedestrian portal, select them to leave world through the portal, they're stuck there forever.

Yet, the newspaper deliverer can get in OK and after dumping the mail and a while of wandering and disappear the flamingo ad the lot centre.

still trying to do more modifications... to see how to fix this :D


Note there're 2 types of objT files, and the another one is 0x6F626A74, which is an object list of all invisibles or hidden.


What could he have meant?


Added:

Just did Xobj file replacement with instance 7 the trash can in this case.

Hi again!

I've submitted the rotated lots. I did it this morning, hoping they would go through fast before I go away tomorrow, but it seems not. So I just hope they don't reject them in the meantime, and the thread will be up and running when I come back.

I realised I need to put up the portal values for the longer lots before I forget, so...

Suitable values are (for U10 = 04, U11 = 02):

1x4

Service Start (1.5, 45.5)
Service Stop (6.5, 45.5)
Car Start (8.5, 44.5)
Car Stop (2.5, 44.5)
Ped 1 (8.5, 40.5)
Ped 2 (1.5, 40.5)

1 x 5

Service Start (1.5, 55.5)
Service Stop (6.5, 55.5)
Car Start (8.5, 54.5)
Car Stop (2.5, 54.5)
Ped 1 (8.5, 50.5)
Ped 2 (1.5, 50.5)

4 x 1

Service Start (1.5, 15.5)
Service Stop (24.5, 15.5)
Car Start (38.5, 14.5)
Car Stop (16.5, 14.5)
Ped 1 (38.5, 10.5)
Ped 2 (1.5, 10.5)

5 x 1

Service Start (1.5, 15.5)
Service Stop (29.5, 15.5)
Car Start (48.5, 14.5)
Car Stop (19.5, 14.5)
Ped 1 (48.5, 10.5)
Ped 2 (1.5, 10.5)

6 x 1

Service Start (1.5, 15.5)
Service Stop (37.5, 15.5)
Car Start (58.5, 14.5)
Car Stop (23.5, 14.5)
Ped 1 (58.5, 10.5)
Ped 2 (1.5, 10.5)

Obviously these aren't the only values that will work - ther's a lot more choice on the wider lots. But these ones seem good to me.

I'll be away until Friday, so don't be surprised at the silence.
Cheers!
Aelflaed.

Instead, can we be surprised that you're going away?

With so many big stars in the TS2 community, I doubt my absence can be noticeable. But, it doesn't matter coz I consciously choose to share some moments of my life here without expectation.

lol,, I just updated my previous post... but unsure if they're of any use...

You can be surprised I haven't gone yet...

I just checked one last time before bed, and the lots are up! As is the flamingo, but I guess you all knew that. Now I'm really going.

No, really.

Unfortunately, I haven't had a chance to actually play the game since taking on the LotExpander development. So, I've been relying on the Maxis-made neighborhoods, subhoods and lot catalog for my test cases.

Yes, that just occurred to me recently. If this is possible, then things like building to the edge of a lot and using the neighborhood terrain in expanded areas could be by-products of this technique.

Did you take the U11 rotation value into consideration when choosing your portal locations? aelflaed was only showing the "sunnyside" U11=2 positions.

I definitely need to check this out.

[Update:]
The main MOBJT 0x6F626A74 is the OBJT which has only a single instance = 0x00000000. The LotExpander is currently using information inside of this record to start the search for the portals.

The other set of 0xFA1C39F7 OBJT (singular lot objects) are the ones that we have been using to find the portals, by walking through the instances looking for the portal strings.

There is a reason that we use a different method than the LotExpander to find the portals. The logic used by the LotExpander is more difficult, but does not rely on a comparison of strings. Human beings are good at looking at strings and deciding that they are "close enough", but computers are much better at following a logical path, however circuitous.
[End update]

I still think that there must be a second location for the portals... [Update: see post after the next one].

The LotExpander needs to go through some indirection in order to find the portals (I can post more on this, if anyone is interested). By the time that Andi's original logic found the portals, it had lost the information about the U11 value and about which portal type was being changed. So, Andi tried to come up with an algorithm for portal placement which was based solely on the previous location of the portal and the new width and height of the lot.

Andi's old logic really wasn't adequate to the task. The new (test) LotExpander code maintains the U11 and portal type information through the process of finding the portals, so that it can make a more informed decision about where to put them. Hang on and I'll get you the new (better) algorithms.

Here are the algorithms for correctly placing the portals in the default positions. For now, the LotExpander is leaving the direction of the portals alone; I need to fix this.

Pedestrian direction should point into the lot from the edge. Vehicle direction should always point from Start to Stop, and Stop should point away from Start (that is, in the opposite direction).

X is the value at offset 80 = 0x50 in XOBJ
Y is the value at offset 84 = 0x54 in XOBJ

Please see the attached picture for help in determining the Height and Width of your lot, based on your lot rotation (U11).

U11 = 0 (Left):

Pedestrian:
X = 0.5
Y = 9.5

X = Height - 0.5
Y = 9.5

Car Start:
X = 1.5
Y = 5.5

Car Stop:
X = Height / 2 + 1.5
Y = 5.5

Service Start:
X = Height - 1.5
Y = 4.5

Service Stop:
X = Height / 2 - 1.5
Y = 4.5


U11 = 1 (Top):

Pedestrian:
X = Height - 9.5
Y = 0.5

X = Height - 9.5
Y = Width - 0.5

Car Start:
X = Height - 5.5
Y = 1.5

Car Stop:
X = Height - 5.5
Y = Width / 2 + 1.5

Service Start:
X = Height - 4.5
Y = Width - 1.5

Service Stop:
X = Height - 4.5
Y = Width / 2 - 1.5


U11 = 2 (Right):

Pedestrian:
X = Height - 0.5
Y = Width - 9.5

X = 0.5
Y = Width - 9.5

Car Start:
X = Height - 1.5
Y = Width - 5.5

Car Stop:
X = Height / 2 - 1.5
Y = Width - 5.5

Service Start:
X = 1.5
Y = Width - 4.5

Service Stop:
X = Height / 2 + 1.5
Y = Width - 4.5


U11 = 3 (Bottom):

Pedestrian:
X = 9.5
Y = Width - 0.5

X = 9.5
Y = 0.5

Car Start:
X = 5.5
Y = Width - 1.5

Car Stop:
X = 5.5
Y = Width / 2 - 5.5

Service Start:
X = 4.5
Y = 1.5

Service Stop:
X = 4.5
Y = Width / 2 + 1.5

I have found the portal "display" position. It is in the OBJT record type, with instances as expected. Unfortunately, I can't give an exact offset into the record, since it varies based on the version and various imbedded string lengths: http://www.sims2wiki.info/wiki.php?title=CObject

However, this explains the discrepancy that we were seeing between the portals and the boxes displayed by the flamingo. This information should allow the LotExpander to place the portal display correctly.

My guess is that moving the boxes displayed by the flamingo changes both positions simultaneously.

lol, can someone here donate or suggest a flesh unmodded neighbourhood... so, even Mootilda is too busy not to enjoy making a new one for yet another testing and investigation... :D



http://www.modthesims2.com/showpost...3&postcount=134
http://www.modthesims2.com/showpost...9&postcount=213
http://www.modthesims2.com/showpost...8&postcount=216
The problem I see thus far is actually on how to get walls built at the edges stable rather than getting it done coz it's already approachable by means fence-based default replacement but the resultant is just unstable. I really wanna know why such lot couldn't load.



Apparently, I've forgotten ... :red face:



so, this one will check for those infos before changing the lot size?

I'm looking forwards to it... :D



Yay..., that means this problem is about to be solved already... Congratulations to you and all of us... :D

I'm gonna give all the portals a default value that will make them appear in all lots without checking U11 or else. Then, I'll use the portal revealer to place them in my favourite spots customly...
But the table you gave out is very useful for making default settings for lots.

Thanks a big bunch and rushing to test things out again...

Edited:
Yay, I've got the lot working well after either method. :D
Now, I'm satisfied in terms of manual lot re-sizing.

Gonna finish the 4 10x20 lot templates for both lushy and desert areas...

Added:
just + my expereiences for manual lot-resizing, and here is about reducing the size down to 10x20:

for all the 4 directions, if U11 (lot orientation) is well considered, then one has to follow Andi's instruction on the neighbourhood.package modding and the first 6 steps for the lot package file modding skipping the last part for the portal. here
Then, mod the portal according to Mootilda's post here

If all are set. then load the game, enter the lot to fix the trash can, mailbox and the portals (with Inge's portal revealer here ) save the lot, get back to the neighbourhood, move the lot to facilitate the realignment and fix the terrain graphics.

Done.


Further suggestions:
I think the mailbox and the trashcan should also be moved to new positions so, users needn't to add new ones in that in turns add 2 more objects in a lot.. When I checked for xobj, I realised the additional mailbox or trashbox are reasonably at the back but unnecessary to the last ones while the original ones are still right after or near the portals.



(moved from post 291)

Added:
The pic was taken when I was making a 4-sided lot. We can see how the roads are made in game... :D

PS:
I've added more pedestrian portals and a more set of car and service portals to a 2-sided lot and run it as a community lot, and it seems fine so far... But I'll have to test it as a residential and even with 4 sets on a 4 sided resodemtial lot to see if any conflict can result or the vehicle can come from all sides... :D

I uploaded a neighbourhood terrain earlier in the thread. Mootilda only needs to ask if she wants me to make one with different features.

lol, for those feel interested in testing out how these lot templates work..., please do help..

Thanks to Andi8104 (instructions & Lot Expander), Mootilda (LE updates & hints), Inge (Portal Revealer), aelflaed (Portal location research), Quaxi (simPe) and SimPE team..

I'm glad to announce I've finally finished this little projects for 1x1 (10x20) lushy lot series for both Residential and Community zones.

Lol, 7zip can save 9kb for this dl...

The test version of the Lot Expander in post #274 has the new portal logic.

During testing I noticed that the display position of the pedestrian portals was still in the old location. Strange that the vehicle portals seem to display correctly, even though I haven't changed those either. I'm working on the logic to fix the pedestrian display position now; a "quick and dirty" fix, since I don't think that it's worth spending a lot of time on right now.

I also found that the ridge at the edge of the expanded terrain was enough to stop the portals from functioning correctly, which is why I implemented the simple terrain fix. Just a couple lines of code, but the terrain looks much better in my tests and the portals function better too.

So, I was hoping to get some feedback about the functioning of the portals and the look of the expanded terrain while I'm working on the portal display issue.

The only other thing that needs to be done for the portals is to ensure that the portal direction is set correctly. I'm hoping that this will be a quick fix.

So, now to try to decrease the width and depth of the beach lots?

Yes, I'd like to see the LotExpander move the mailbox / phone booth / trash can, as well as delete the excess road and sidewalk tiles.

For now, using the neighborhood terrain is on the back burner. It turned out to be a harder problem than I was hoping, so I'm still trying to fix some of the simpler problems.

I'm assuming that the neighborhood terrain problem will be easier to fix than shrinking the lots. However, if the current quick terrain fix is adequate for now, I think that I'll tackle lot shrinking before I attempt to get the neighborhood terrain again.

The shrinking alone may be enough to perform the between-lot ridge-erasing *if* the game will allow the placing of a lot on tiles that previously had a larger lot on them. That's another battle to overcome.

Sorry, I guess I misunderstood something in Inge's post when I re-read it...

Lol,.. may add some lines to switch the neihourhood.txt script file with a modded one to facilitate that if necessary.

Change max slope value
http://www.modthesims2.com/showthread.php?t=47544


Added:
I fooled around on how to switch the lot terrain texture.
It's really interesting that the "lot terrain texture" reference in the Lot Description file of the Neighbourhood package file. has no effect on how the lot package file presents its lot terrain autonomously. Probably, this is for the custom terrain painting?
Anyway, in the neighbourhood view, blending may occur.

Once a lushy lot is dumped into a desertoid neighbourhood, the "lot terrain texture" reference is automatically switched to the desertoid terrain texture "lottexture-canvas-desert" in the Lot Description file of the Neighbourhood package file, but this won't change the reference in the lot package file automatically. I'm unsure of Maxis original intentions.

OK, now about how I did in a way,

I basically switched the lot texture files between a lushy lot and a desertoid lot for my laziness and it appears to work for my purpose. Note to alter the lot size values W and H accordingly as instructed in Andi's 1x1 lot creation here (The link is just for references)


That's it, pretty simple.

Now, if there's no flaw with this simple approach, ones can easily swtich the lot terrain texture fast for their needs.

The graphical results are shown in the attached pix.
Also, the lot texture file extracts for the lush and desert.

References:
http://www.modthesims2.com/showpost...3&postcount=295
http://www.sims2wiki.info/wiki.php?title=4B58975B
http://www.modthesims2.com/showpost...&postcount=1475


Added2:
I'm trying to replicate Inge's 11x20 lot experiment..
I've a made 11x20 lot but the expanded last 2 lines are still unbuildable, quite unlike Inge's one. Here So, the one I did was more like a normal lot in this aspect?

I wonder if the graphics and the geometry are separable, so testing the value rangers for these steps may help.

There're 6 SimPE steps to shrink a lot, and here now, I'm gonna bonker to vary the values to see what may happen. Anyway, the fix by the game engine can be yet another surprise.

1. Strangely, the 10x20 lots have their offset 95 and 99 values in the wall graph files altered in an array way.
Now, they have values like X * 10 + n, Height (Offset 99) value = Y * 10 + n; n= 4,5,6,7.
I've doubly checkex and H/Yd they're supposed to be 11 and 21 before loading the game to save-fix the new lots, but I guess the game engine still used 20 and 40 to fix the wall graph's W/X and H/Y values.
Omg, really odd.
But it seems they're still working well...

So, wall graph can't be smaller?

2. Changes in the Lot Texture Map (4B58975B) doesn't cause a crash or remove the additional terrain texturing on the additional row/column of grids. Probably, the H and W values will only affect the mapping scale as the corresponding shader suggested.

3. A single alteration at the world database file can lead to a game crash during the lot loading. But it does work well with altered 2D and 3D without the other three and produce the extra grid lines.

4. The W or X value altered from 1 to 2 in the lot file 0x6C589723 doesn't cause a 10x20 lot to crash, nor does it produce the extra gridlines or affect the wall partition buildbility.

5. Just altered 2D files won't cause a crash, nor does it produce the extra gridlines or affect the wall partition buildbility.

6. Just altered 3D files won't cause a crash, nor does it produce the extra gridlines or affect the wall partition buildbility.

7. I've succeeded to use invisible tiles to completely nullify the extended part of a lot to avoid graphical flicking. My version of an invisible tile is attached below.

8. The attached lot is a 12x20 lot with lighting from the front left of the lot.
Note this is not a completely modded lot coz it has only modified 2D , 3D and worlddatabase files with the in-game-modified wall graph files, skipping the changes in the lot file and the lot texture file intentionally.

9. I've tried a 12x20 lot by modded world database file and the modded 3D array files alone, skipping even modded 2D array files, and the lot does load and I can even build walls and floors on it well.
Such lot is buildable and reimportable from the lot bin. But in my play-tst with most services and phone options, and it seems it's stable to save them and reload... I'm unsure what the missing 2D arrays may cause, but obviously in our interests here.
I tend to assume to have the same or more as a better option than to have less.
I'm not posting it until someone wants it or testing.

10. kinda expected just modded 2D and world alone would cause a crash...
So, the order of importance for resizing a lot is
World database >= 3D arrays >= equal/over-sized Wall graphs > 2D arrays (for extra floor grid layer or for terrain paint layers?) > lot texture (for terrain paint) > lot file (for description only?)
The neighbourhood package's lot description can only affect the lot's orientation in that neighbourhood or the reserved grid size (W x H) in the neighbourhood, but this doesn't affect the lot itself. so, Maxis made them kinda modular... but failed to connect them in a cause-and-effect way.

11.


So, wall1 partition can be somehow stable at the edge of a lot, or is it also because some other settings had stabilised the graphical illusion?

can you give me a copy of that lot if you still have it?

12. gonna make 14x20 for a clear possibility for row houses with invisible tiles, but if anything fruitful found out from Inge's case. That'll be just yet another alternative.

UPdated:
The last attached is the 14x20 lot for desert.

Niol, the last two tiles never became buildable. I built first on a larger lot, then shrank it manually. The walls were left standing in their original places. I got so lost while editing the hex that I got it a bit wrong and I didn't cut the lot off quite where I meant to. I think the real experiments can begin after there is a tool to shrink them, because I don't intend to give myself eye strain doing a manual shrink ever again :D

Since you seem happy to do manual shrinks, I will tell you the steps to make the house.

Start with lot 30 tiles wide. Create house 10 tiles wide in the center. Shrink lot to 10 tiles wide - ensuring the middle 10 tiles remain.

Now it is possible the wall running along the very edge will be lost if it is considered to be on the tile you deleted. If this turns out to be an issue, row houses will have to be designed with a dummy wall on the next tile in, leaving them only 8 tiles wide internally. I still feel there will be a nett gain, and small row houses are typically narrow inside anyway.

lol, I'm a lazy ass, so I make templates or back-ups for most steps, so you see why /i got the combination out easier.

But to edit the array one by one, no... I'll try to figure out how to extract the codes as if it a page words for fast replacement. And hopefully , I'll learn how to use macro in PSpad.


Inge,

what interests me is that the wall segments can stay there stably instead of crashing the game. I've used fence to replace the Wall1 and built at the edges before and the result I got is a crash when the lot is accessed without the the default replacement fence.

So, I assume there's a way to keep the walls at the edge not crashing the game while the walls can still be at the edge.

But hopefully, we can figure out how the wall is recorded in a lot file . Then, we may be able to manuallly build walls at the edges to test for stability and if affirmative applications. :D

Just got BV and gonna try to install it over my EP5 and grab the beach lot for testings... :D

Thanks for your hinting, gonna try...

:D




Probably because wall partitions are like fences that are directional. Dragging from 1 side is completely different from another side. This particularly affects shadowing of custom fences. For a given grid, it may have 4 sides for building partitions like walls and fences at the corners for the posts of partitions. Building a partition clockwise or counterclockwise will cause a difference on the rotation of data, as in the quaternion in cres for meshes?

Oh well, I'll try to figure out the cut location first with a lot already built with 8 segments of walls per allowable lining with the 2 closing wall drags. I may have to try out the 4 directions.
:D

Mootilda, sorry I didn't get time to test your latest until today.

I made a beach lot and a hill lot and expanded each of them on both sides. It seems to do what it says on the tin, except one strange feature, which is that there seems to be a layer of "water" above one side of the expansion. The water will disappear if you try to build a wall on that portion.

The beach lot allowed me to place it anywhere including back over its original place after expansion, but the hill lot became quite fussy about where I was allowed to move it. Maybe just because I was testing it on some very bizarre terrain.

For the hill lot, pictures show the water added by the expander, the water after disappearing due to the wall being build, and after ctrl-z undid the wall, the water comes back and this time makes itself a little "beach" effect

On another topic, I would be very happy to test an unfinished preview of your lot shrinking as soon as it is doing any shrinking at all, even if it's still a bit crashy and doesn't move the portals correctly. I have several test hoods so hood destruction is not a problem for me I am just very keen to start testing the principal of "row houses" from the wall placement point of view, I wouldn't be intending to actually play the lots yet so the portals are not a problem.

Inge, for Wall1, just use guid 1, as suggested in
Added after the following post,
Damn right for the fence-based default replacement?...
We've got a known chance from lot shrinking deletion.
here

Just open a 30x30 lot with 8 segments per lining and 2 wall drags to close the rooms.

For 3D array files:

the instance 15 (hexdec.), all values are "1" after the "2" which I guess is 2 "levels " of grid-layers?, and which in urns right after H value.

the instance 14(hexdec.), all values are "255" or "FF" after "1 which in turns after H value"

the instance 0B, 0A, 09, , there're 26 sets of "26". I guess they're the inside of a room. The value after H is "2"

the instance 03, alternately 20x "0" and 10x"1" resembles the buildable region and the road as a random guess.

the instance 01, it got a whole bunches of "0 0 64 64". But is it single "3", double "32", or else?

the instance 00, there're waves of 01 01 01 01 followed by 06 06 06 06 03 03 03 03 05 05 05 05 04 04 04 04 03 03 03 03 02 02 02 02 01 01 01 01

What problem is that a solution to, Niol? :D