[Lots > maxi.size]

it appears the neighbourhood lot description can tolerate lots of 70x70, as shown in the attached pic 70x70.jpg.
It's some files in the lot package that doesn't allow 70x70.
From previous testings on the 6 steps Andi gave out.
I guess it's quite likely the world database and/or 3D arrays that might have caused the crash. But 3D arrays can afford values like 65 for 64x64 lot. Yet, 65 may be the max for that particular 3D array.

Yet, 64x64 lot is possible and values > 256 is allowed,
say:
wall graphs: 257, 257 --> 01 01, 01 01
2D array : 281, 281 --> 25 01, 25 01
3D array : 65

Further testings on lots of world database with 63 and 3D array with 70, shown in wor63-3D_70-008.jpg, it shows that the game can tolerate 3D arrays to be as large as 70x70 or even more indeed. So, it suggests it's the world database that can't be larger than 63? gonna test it out to see.
This lot is made from a lot of 70x70 specs by altering the 69 into 63 for the world database file.
The background shows up that may infer it's quite likely the word database that gets the graphics together with geometry arrays.

1.
Thus, from this test, lots larger than 64x64 can be possible when we can break that limit or simply accept the empty spaces between the showable lot terrain and the lot borders ( for the later) I'm not joking though, we can make mislocated object to fill the empty space, so such lots can look like as if lots larger than 64x64. It's really the 3D arrays that harbour the spaces there, and the barrier limit is not on it. Yet, such empty space may not be accessible but just for decorations, as depicted in lot-world63-3D70-inaccessibleSpace.jpg.

2.
wor63-3D_70-006-bpcfef-wallup.jpg and wor63-3D_70-007-bpcfef-walldown.jpg shows walls of any level can be "built" down to the ground or even under is as possible as V1ND1CARE had shown in her <4 click high wall tutorial.
Once we have studied how to make these walls through lot-modding, we'll be able to build wall in whatever shape we want.

3.
After relocation of the lot (wor63-3D_70-008.jpg), we can see how the road is accordingly added to the lot. It seems the world database file is the determinant.

4.
Just in case someone wonders about the crests, they formed due to some built walls from the original lot. It turns out that the ground had risen up to the top of the rooms. In some of the pix, I used the cheat "boolprop constraintfloorelevation false" (bp-cfe-f) to relvel some of those. But, not all of them can be simply re-levelled as the grid layers were packed together. It takes a column or unmodded walls to get the walls back to some heights or namely the grid layers separate again before the cheat can do its art.
My wall1 walls are set to flatTop true but flatBottom false for easy wall building along with V1ND1CARE's <4-click-high trick. Without flatTop true, it doesn't work. Also, my wall1 walls need no support and is submersible. OK, that's enough for the build mode tricks and script-modding for here.


Note, the testing lots are reimportable, so see the attachments.


Mootilda,

Also, just a little request here if you don't mind, can you make the Lot Expander to allow users to input the odd numbers like 64, 54 for both both W and H. For the neighbourhood view or package, may just count them as 6, 5 instead of 7, 6.
Surely may add an advance option for useers who want the risky numbers >63, 64, 65...

Although , manually editting empty lot is easy, but for built lots, manually editting the arrays seems not pragmatic. If not properly editted, the sequences of the arrays will be messed up
so that the chaos we can see fromthe attached pix.


[lot-neighbourhood terrain sync.]

Suddenly, I'm wondering what if the neighbourhood.txt (...\EA GAMES\The Sims 2\TSData\Sys, and probably with EP ones...) with
SmoothingTalusAngle=0.0
NumberOfSmoothingPasses=0
MaxLotSlope=0

These settings will demand the lot terrain and the neighbourhood terrain to be more similar to be attached together. Since here we want the neighbourhood terrain to be the fixated one not bend for the lot terrain.
So, in the cases of lot expansion, the lot terrain may have to bend to suit the neighbourhood terrain instead.

The higher these settings are, the more flexible the neighbourhood terrain.

So, my present assumption is that it's the flexibility of the neighbourhood terrain that makes it hard for expanding lots to suit the neighbourhood terrain.

Lol, this has to be tested though. imao..

Interesting tests there... I suspected that the tests that we did with the LotExpander weren't conclusive.

Unfortunately, changing from using neighborhood tiles to lot tiles is not as easy as it might first appear. This would require a change to almost every source file in the LotExpander, and to many of the functions within those files... not as big a change as shrinking the lots, but still a pretty big change.

It's something that I have on my list, but it's not a little change. Sorry.

I'm still struggling with the PSpad to seek some ways to alter the hex values with "replace" function. You know, I can save a lot of work from editting a value to another one by one if I can put my heart to do so. So long as I elongate the search string(s) long to be specific enough, I mostly believe I can do that in that way.

But as an alternative choice, I may well study how a wall built can change the lot package. That seems more promising than the deletion method. Since I've already got the 10x20 lots made, I can make any larger standard sizes with ease with LE.

Yet, I've not made the desert variant series. or others.

What's this being written in? Peter has finished updating PJSE for BV so he may be persuaded to help with some of the coding, if it's in something he's familiar with?

wow, the effort power gets stronger back?

Hello!

I've written a tutorial for rotating lots. Can someone please look at it and see if it is clear enough?

Also, I don't know what format it should be or where to post it etc, so maybe one of you knows? I couldn't find any guidelines on MTS2 just now, but the tutorials are somewhere else anyway, so I don't know how to submit mine. Presumably I don't just dump it somewhere.

Thanks everyone.

Edit - Removed the file, as it is outdated and not in a helpful format. Look for the finished version.

[chit-chat]

probably just keep it here and let Mootilda to link it to the LE thread before we finally figure out where it should belong to?


I've read a recent thread in the SimPE site that a person called ReneeFox wanting to make a "program to manipulate lot locations" here
So, I sent a pm to that person here and posted at the SimPE site to suggest that person to view this thread.
Hope you all don't mind my instinctive act. If so, come and beat me up when I deserve it . Or, demand me to slap myself.


aelflaed,

I can't open it in my Openoffice 1.1.3 copy. So, I need version 2 and above? :D

I may not understand what you're asking for. However, I don't believe that this is an issue of code-perfection...

If you want the lot expander to use lot-sized tiles in all of it's processing, then it's a pretty big change. Throughout the LotExpander, the code for each record type is written assuming that neighborhood-sized tiles are being used. Every class uses these larger tile sizes in it's processing and calculations. Therefore, along with the code to accept the different input, each class needs to have it's logic changed to use the alternate sizes. I can't think of any way to do this without editing every class and changing the logic which handles sizes. My (obviously imperfect) understanding of the code is that this is a change that touches every file and most functions within those files.

It's possible that I misunderstand what you want... perhaps you could list the record types that you want changed to use the new sizes? I believe that changing the input (from 0-6 to 0-60? 70?) isn't too large a change, and it's not too hard to divide and truncate the lots sizes to change them back to the 0-6 range, but that doesn't accomplish anything unless we are passing the lot sizes through to the processing for at least one record type... and that's where the real work comes in.

It might be helpful to think of a C# "class" or "file" as being equivalent to an instance of a particular record type within a package. Each record is in it's own file and any instances of a record type which require different processing from the "norm" are in their own file as well.

The code is in C# using .NET.

Oh, and I may not have mentioned this before, so I will now:

I don't have any problems with other people changing the LE code... I still think of it as Andi's program. In fact, I'd be very happy if someone else wanted to take over all of the development... I consider myself a "reluctant modder"... I took it over because I want the program to exist and no one else seemed to be doing anything with it...

I'm not familiar with .ODT files... how am I supposed to view this tutorial (ie, what program do I open it with)?

I have no problems with pointing them here. You might want to tell them (I don't have an account there or I'd post myself) that they may be able to glean some information from the LotExpander source code, as well. They may find the LE code particularly interesting, since it is an external program which uses the SimPE DLLs to access the package files (exactly what they're trying to create).

Pete's usually fairly willing to code, but he wouldn't be into doing the analysis, as he's not interested in Sims stuff. I was just thinking if there was some tedious stuff you didn't want to spare the time doing but could actually spec out for him (ie "replace every instance of literal 367 with a constant call so that 367 can be substituted for different values during testing"). Well maybe not that simple, but you know what I mean.

OK I can't contribute much, but this I can do .. I have no idea how "strategically placed" the road would need to be, maybe the attached file will do (it's flat with one road roughly in the middle)? If not, i'll check back at about the same time tomorrow, i'll happily take requests =).

Sorry for not mentioning what the file type is - I realised after turning off last night. I'm using Open Office 2.1.

If you'd rather I put it into some other format, I'll do what I can. I can do PDF, for example.

I'm happy for the tutorial to be on this thread for the moment. I have also remembered that I didn't yet put credits into it. I don't consider it finished yet, just ready for feedback.

html is a good format for tutorials, some people are scared of using downloaded Word documents in case they have viruses.

[Rotations: all 3]

After using values like U10=8 while U11=1, I've got the lot to deep sink the land down under the neighbourhood water... :D

What if I finish the lot and then sink a whole part of the neighbourhood down under the neighbourhood water with these lots...? :D

Then, at least a decorative undersea neighbourhood it's gonna be?
Then, gonna alter some of the neighbourhood materials to facilitate the scene...

The attached pic shows a bus is gonna get out of the neighbourhood water from the top right corner of the hole... the lot's z = 0.
To get the lot re-accessible, recover z value of the lot in the lot description file in the neighbourhood package! See sunkenlot1.jpg, z value recovery gets the lot back right where it were before the sink. In NL or later for the in lot view, one may even make it an inland island by sinking it and recover the z value of it.
(jpgs: bus outting the neighbourhood water, sunkenlot2, sunkenlot1)
So, people who had this problem, now they can fix it like that.
PS: that's a 64x64 lot I'm making out of the four default directions. This lot had the road added as if it were 60x60, so there're 4 rows on the other side of the road. To fix it, I altered the road side for realignment, and I intentionally did the previous no-no with mismatched values of U10 and U11. But I was lucky enough to solve the problem myself.


[Lots > maxi.size]

I'm testing on 65x65 to see if 64x64 is most stable largest or not. But, seemingly so far, 65x65 seems to work its way out with neighbourhood W and H as 7x7.
(65x65c.jpg)
But, still leaving out 2 big gaps due to the neighbourhood W and H values.
1.
From this, it suggests it's the neighbourhood W and H that controls if the neighbourhood terrain in a lot view after considering the previous experimental results. So, the previous 70x70 with worlddatabase set as 63 and this lot can skip the gaps by using neighbourhood W andH as 6x6.
2.
The results seem to also confirm what the terrain shader infers that 64x64 is the largest size for the material to show up in its calculation.

So, if those values are altered there, this graphical limits can probably be fixed ? Probably with "clamp" for mapping?
And if that doesn't work, invisible tiles can always nullify the overlapping terrains when neighbourhood W and H are set as 6x6.
3.
the lot 65 x65 seems to have another graphical odd,
see the attached lot65x65prblm001.jpg .

4. the lot crashed when saved, so

the world database seemingly can only have a value of 63 for those offsets as the limit number. This is based on this experiment and Inge's posts about her experiences.

The lot can save when without modification but crashed after I added invisible tiles at the edges and removed the unnecessary tiles.
Added: removal of the unwanted tiles won't crash the lot, but then the game crashed when exit.

But after all, as previously suggested, with some make-ups, a lot much larger based on other settings except the world database may not be a problem.


Inge,

Have you still the pier lot, this time it may work with modified world database set as 63 coz these value appear stable for the lot >60x60.
I'm also curious if that will still crash the game when saved.
As for the gaps or else may be well covered up with other tricks. :D


[chit-chat]

aelflaed,

I can already open the one in openoffice 2 version. But, I believe pdf and htm versions are more preferred. Thanks... gonna finish reading it.

Okay, obviously my brain was switched off last night.
Open Office files won't be open-able by Word, sorry for misleading you, Mootilda.
I think a PDF may be the most accessible option, so I'll do that next.

(edit...PDF should be attached now)

Update 30/10/07 - the finished tutorial is here:
http://www.modthesims2.com/showthread.php?t=255110.

Update 2/11/2007 - since the tutorial attachment is still 'pending approval', I'm adding it here again so people can access it in the meantime.

Niol, I don't have that lot any more, but I can make it. Would it be easier for you to try, since I don't really understand what you mean by "modified world database set as 63", so I can't carry this out. I got as far as creating a new 2x2 lot, and expanding it backwards to 12 tiles. This opened in the game ok, closed, saved, opened again but not if I did any building on it. The test will have succeeded if you expand a lot to 12 tiles, open it, build a wall on it (anywhere) and the game does not crash while it is saving.

Also I want to ask you, how did you get water on a lot so far from the sea? Usually the water plate has ended by that far inland. Or was there a pre-existing lake in that area?

Your own experiments with the LotExpander expanded terrain change, before I put in the corresponding change to the water level, seems to indicate that the water is created as needed by the game, based on the water level...

In fact, fiddling with the water level array may be a way to get water whereever we want it...

Thanks, I'm able to open this one.

Comments:

Before I say anything else, let me say that I think that it's wonderful that you've done this tutorial. For the most part, I found it easy to read and to follow the instructions and it shouldn't be too scary for people who have never done any modding before.

My comments are only meant to make this even better.

I think that the tutorial will be more compelling with a real house (at least a real exterior), rather than blank walls. Just adding a roof and some wallcovering should help. Adding a door and window might even help people to see how the house remains facing in the same direction, but the location of the road changes.

As well, I think that the display of the portals in the second picture detracts from the message. In general, I would avoid displaying the portals except in the section dealing with them.

Might be useful to put in a link to the various tools, probably at the beginning of the tutorial where they are first mentioned, so that people know where to find them.

It might be a good idea to warn people to backup before you get into the instructions. I know that people sometimes ignore this advice, but it's worth stating anyway.

There are other reasons why someone might want to rotate a lot... for example, the houses in Strangetown which face the side yard, rather than the front. I'd give a couple of examples of why a person might want to rotate, rather than just the sunlight issue... after all, I wasn't even aware of the sunlight issue when I first wrote the technique.

I also wouldn't restrict people to empty lots... this technique works perfectly well for built-up lots and may be more compelling for some people. Again, the Grunt house in Strangetown might make a good example, but you would need to include a step to expand the lot to allow space for the new road if there is an existing building.

Of course, I suppose that this means that you'd need to explain that the sunlight direction won't be changed for an existing house. Hopefully, your pictures can make that very clear.

The link for the U10 and U11 values didn't point me to the right post. Try:

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

It might be helpful to have a picture of the windows calculator in scientific mode. Alternativley, I was wondering whether SimPE might be persuaded to give you the decimal value for the instance number.

The instructions for opening the Lot file in SimPE aren't entirely clear. You might want to look that over and see whether it can be explained better. I think that it might help to say something like "navigate to the Lots subdirectory and select the package with the lot number calculated above".

Otherwise, I thought that it was very easy to follow. Fixing up some of the pictures is probably just "eye candy", but people really do respond to pictures, so you may as well use them to emphasize what the technique actually does.

I hope that this was helpful. I'll be happy to look over your second draft.

From what I understand about the neighborhood package, I think that a "strategic" road is placed at the top-left corner of the neighborhood, when it's not rotated from the "standard"... ie, when a left-facing lot in the lot catalog (U11=0) has it's placement arrow facing left and a top-facing lot (U11=1) has it's placement arrow facing the top. Of course, you have to take into consideration that the terrain is flipped when converting from SC4 to TS2.

I know, I know, why did EA/Maxis make this so complicated?

I'll keep him in mind. At the moment, I think that this change requires some strategic thinking for each record type / instance. I need to determine how to shrink each array, based on the current array logic which documents the structure of the array. The "grunt work" is more a question of analysis than coding.

[Lots (non-10x)]



Lol, I'm sorry I was rushing to record down the results and didn't proofread my typing.
"modified world database set as 63" means to set the offsets 93 and 97 to 63 according to Andi's instruction post (http://www.modthesims2.com/showpost...&postcount=106).

wow 2x2 lot, I've not tried to make lot smaller than 10x20 yet. Now, I'm gonna try... you often can think of grounds to break, and this always amazes me... I admire you a lot...


[Rotations: all 3]



Lol, basically, as long as the terrain is lower than the neighbourhood water level (set by the neighbourhood water level array as suggested by Mootilda). Actually, I just used U10 = 8 and U11 = 1 to turn the lot needing the top and the bottom to be placed on the roads. And this caused the z value plunged down to 0, that in turns caused the sunken lot scene. Obviously the lot zone is lower than ther neighbourhood water level when the lot zone z = 0. After a reload of the neighbourhood, the neighbourhood water is generated over that lot zone... I recovered the original z value to get the lot back up to the surface and moved the lot to somewhere else.

So, out of this exploration on a previous no-no , I leanrt how to alter the shape of neighbourhood terrain by altering the lot zone z values. With the lot zone locking on the terrain shape, we can do further post-SC4 neighbourhood terrain reshaping. Surely, modding the neighbourhood terrain arrays are yet another way for full manipulation. Thus, with all these tricks/techniques/methods/means/etc..., I can say that say that we're heading to control almost most things there up to their preset limits by the game engine and structures.


[record formats (lots and neighbourhood)]



In addition, I think the water level is one factor and the another one the neighbourhood terrain level. In the instance I showed in the previous post, it's the lot zone level which a part of the neighbourhood terrain level, in lot description file of the neighbourhood package file, the "z" value (the one on the right of Left and Top) decide on the "height" position of a lot zone. Left and Top are just x and y in a 3D model. Thus, we can get the water out by either raising the water level or lowering the terrain. Being able to manipulate them both, we've got what we want. :D
Also, if the water material is altered, its graphical shape can be manipulated, too.
So now, what else is left?



Probably to prevent people from adding SC4 stuffs into TS2? (lol, just for chatter BTW.)
But being able to break those barriers, we modders have learnt more things, too.


[Rotations: all 3]

aelflaed,

you did a nice and neat effort on it, but I guess 2 more things won't be any challenge to you and may make it work better.

1.
for the pix of the hex editor, may outline the specified ones so that readers can spot the mentioned ones out with ease. For my ugly version as an example :red face:, here

2.
I tend to think it may be easier to use Inge's portal revealer to help move the portals, mailbox, phonebooth and the garbage cans to the reserved buildable regions that will not be used as the new road or the old road. After the road and lot rotation, they can be placed accordingly as suggested already probably by game screenshots. This can be an alternative way to skip the hex editting part for those who can't deal with it even with an efficient instruction..

Don't get excited - I mean a 2x2 lot template. Remember, I said I was not willing to do any more manual lot shrinking? I meant that, my eyes just can't take the hex editing.



Well I still think I have a bit of information missing. When you lower bits of a lot by the sea, you can usually see under the edge of the sea surface once you are less than two lots from the sea. You can dig as deep as you like but the sea edge has been reached and you just get a deep empty crater. So what spreads the water over the rest of the land?

I think that 2x2 is neighborhood tiles, ie 20x20 lot tiles...

My initial thought, as well.

However, as I read further, I realized that aelflaed was trying to find a simple way to deal with portals which are off of the lot and which may not be visible even using the flamingo. When using the base game, I believe that there may be no way to see these portals except using SimPE... so noting their locations before and after using the flamingo seems like a reasonable way to ensure that you will be able to control them.

Perhaps this could be an optional step, based on which EP the person is using and whether their graphics card allows them to see the neighborhood beyond the current lot? Does anyone know which EP introduced the expanded view within the lot, allowing us to see the rest of the neighborhood?