I haven't done any testing on this, but here's how I think that it works:

If you edit a lot using the in-game tools, the game lowers the land and water levels together, so you'll never see water over the land.

However, if you use SimPE to modify the land or water levels, then the game generates the water over the land the next time that it does internal regeneration of the terrain information (usually during a save after some build step).

I believe that one of the pieces of information in the terrain array is the "base" level of the terrain. IE, this is the value that the game uses when placing a lot in a neighborhood. All other array values are relative to this "base" value.

What niol did was to convince the game that the wrong floating point value inside the terrain array was the "base" terrain level... so the game believed that the lot was at absolute value 0 (ie way way down), rather than relative value 0 (ie, at the same level as the rest of the lot).

Again, I'm just guessing, based on my observations of game behavior. I don't know where in the lot package the "base" terrain level is stored, although I'm sure that we could figure it out.

Does this make any sense?

Well I don't think it can be right that the in-game terrain lowering tools lower the water too, because you can lower the ground and see the water surface still staying where it was. It just as you dig further way from the water, eventually you find its edge.

What you could be right about is that when loading the hood, it creates further water plates to cover the areas that are now low enough for them. The water plates are always rectangular.

I reckon that Mootilda is thinking of the water created with the water tool (ponds and such), and you think of the neighbourhood water. Both of you would be right in this case, as far as my experience goes: pond water always moves down when lowering terrain, sea water never does.

Regarding the latter -- sea water --, I've seen some inconsistent behaviour in my games: normally, the entire hood will have the same ground water level: dig deep enough and you'll hit water. Sometimes it's not immediately visible, but if I exit+reload and/or put the lot in the bin+back or move it around a bit, it'll be there (No, I haven't done any systematic research on what exactly triggers it to show up). Cf all the "help! there's water in my basement!" threads on mts2 .. this seems to be the case in lots of people's games.

However, I've had some lots really close to a beach (and on the same street level with beach lots) that should have had groundwater by all means, but I couldn't get it to show up. I tried because I wanted them to have the beach terrain (which in my experience correlates with the presence of sea water), but nothing worked .. I have no idea why, but I think this has a reason beyond "my game hates me".

By "beach lots" I mean selfmade ones btw (sloped lots submerged in sea water), I don't have BV.

aelflaed,

In order to try to resolve your problem with the LotExpander and the BaseGame Starter, I've created a version of the LotExpander which puts up a series of messages as it attempts to find your Neighborhoods folder. When you press Start, you should get a series of messages with the following titles:

My Documents
EA Games
The Sims 2
Neighborhoods
Path

where the first 4 paths should be as expected and the final path is the one that the LotExpander uses to actually look for the neighborhoods.

Could you please run this unsupported TEST version and let me know what messages you get and the paths associated with each title above?

Thanks.

[Update:]

Removed TEST version. I believe that I may know what the problem is. Please try the new test version which contains a potential fix, available here:

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

Could you try this unsupported TEST version of the LotExpander?

I've added the Browse button to the Lot selection screen, to allow you to choose a lot based on lot number or date.

As well, the last screen now has a "Restart" button, which takes you back to the initial screen.

Please let me know whether this meets your requirements.

[Edit:]

I incorporated these changes into the newest version, below:

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

OK, see below, does this work for you? Sorry but I can't check the U11 values myself, for lack of a windows computer atm. This is made on a completely blank terrain, so it's the default rotation as per SC4 -- this default rotation results in the sun coming from the *top* of the screen when the view is the same, only flipped horizontally, in TS2. Unfortunately I couldn't find in this thread how sun direction corresponds to U11 .. hope this info will tell you.

I'd love to have shown you a screenshot, but my graphics card and SC4 hate each other, so I made a quick sketch instead: this is how it looked like in SC4 (the main view is a bit weird -- somewhere between isometric and something else; I always go by the topdown map view).

WARNING to everyone:

This is an UNSUPPORTED TEST version of the LotExpander (1.2.7.4). Use at your own risk.

Here is a link to the current supported version of this tool: http://www.modthesims2.com/showthread.php?p=1747180

I've completed the obvious code changes to add shrinking of lots to the LotExpander. Note that I haven't tested it much (ie, one mostly-empty lot).

Inge asked me to make sure to post the source code changes, so that they wouldn't accidently be lost, as they were when Andi died.

You're welcome to play with this and pass on problems and / or suggestions, but note that this is unsupported and may destroy your lot and / or neighborhood. Be sure to backup.

Remember that I am not even trying to handle objects on the land which is going to disappear... you should be sure that the land is empty before trying to shrink.

Also, I have not yet implemented shifting on a lot... so if you shrink in one direction, you cannot grow in the other (or vice versa).

[Update:]

Removed TEST version. A newer version exists:

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

This should be easy enough - I was just keeping things as basic as possible, and trying to illustrate the simplest way to SEE where the light is, from when you first enter a new lot.



I agree, I was being lazy and using a picture I already had. Oh well.



Yep. Can do.



also yep.



I was avoiding this, just because I didn't want to get into the whole shebang. But if you think it needs to be there, I'll just have to make a longer tutorial. Sunlight on those pre-saved mini lots WAS the issue for me, since that's what I use constantly.

Personally, I never use any of the standard houses because I'd rather build for myself. I was surprised at your suggestion that anyone would bother rotating the maxis lots.

Ditto the empty lots - I remember you writing somewhere, early on, that it would work for built lots, but then retracting that to some extent. Was that because the house will still have the light the same, even if the garden doesn't? That's just weird. It would look very odd indeed. And it begs the question, why does this process work on an empty lot, then? It's still a saved lot.

.

I'll change that, and add the other tool links. Also a picture of the Calculator at work. I left that out because I had no trouble with that step from your description, myself.



I'll look at that again.

Niol:


I had decided they were clear enough, with the titles for each window mentioned and visible, but if you think it would be better, I can tame another aspect of Paint Shop Pro I guess.



I'm not certain I understand, but I think you mean to move these things before altering the lot at all in SimPE. I don't think that would help in the case of portal markers that are missing. Unless it is the rotation of the lot that results in missing markers.

Believe me, if I can skip any part of the hex editing rigmarole, I will - that's the scariest portion of the process. I thought it best to get people to record the values before and after, then they have a written note to help if they need to undo any changes, and they can be sure of exactly what they have done to the lot.



I could make this an optional 'fix' step, rather than a standard part of the rotation - "Read this if your markers are missing". I suspect the EP concerned must be Nightlife.

If I try modding one of Andi's lots in an EP game, I suppose I can find out whether that missing marker becomes visible, or if there is nothing for it but using SimPE.

Mootilda and Niol, thanks very much for your input. I'll be back!

(Mootilda, I'll download that test LotExpander and try it for you. Thanks - I know it must be a side issue, since there's only me suffering from it, and it isn't as though you had nothing else to do.)

Thanks again.

Just a suggestion... people may not think to use your tutorial for things other than sunlight unless you mention that it can be used for other things.

Remember, we aren't actually rotating the house on the lot, therefore the sunlight remains in the same place vis-a-vis the house (and the rest of the lot). Instead, we are just changing where the road (and the front of the house) is.

For an empty lot, this works to change the direction of the sunlight, since we are really only looking at where the sun is in relation to the road. But, if there's already a house on the lot, then the only question is whether we want the front of the house to change in relation to the existing house.

I don't know whether that made any sense at all... it's getting late for me.

I think that niol didn't understand why you were having people check the location of the portals before trying to move them. I wonder how often the portals are off of the lots?

Actually, I have now had three separate reports of an early crash, so I'd really like to figure out what's going on. I wish that I could repro this and not have to bother you with testing.

So far, it's really easy...I start the program, it crashes - end of test. No great issue for me, really! Nice to know it isn't just me, though.

The version 1271:
first three screens okay, then I got the Neighbourhoods message twice. Then the LotExpander screen, then the usual crash.

[chit-chat]

Sorry, I misunderstood the meaning of "2x2 lot"... These days, niol is only thinking of breaking the lot limits...


[Lots > maxi.size]

Yet, lots can be graphically larger than 64x64 with make-up and appropriate orientation dependent on where the lot is placed. I've yet to play-test it in yet another exp. neighbourhood. Somedays, I should learn to start a new neighbourhood just for a particular exp.
I deem that unworthy to dig deeper up to this point I've experimented so far, but am gonna play test that instance.

I've tested the 65x65 lot with world database offsets set as 63 for both. It works as a 64x64 lot. So, the extended graphical part (the part that exceeds the 64th) is not accessible at all and probably just can be used for graphical illusion.


[simPe Hex editor]

As for the hex editor in simpe, I chose "unsigned dec." and check the "hightlight zero " to help me fast-track the patterns of values. I guess that's why they added these options in the hex editor. But it's true it's a tiring thing to edit in a hex editor, especially without "find", "replace" feature and "macros with alterable input values probably by means of script modifications?" (I really like PSP's one though for script modification. That saves extra work for the same process with different input values...).


[chit-chat]

But, I'm realy glad that the hex editor interface can be not so bright that my eyes would feel painful, quite unlike the txmt interface and bhav interface where bright white backgrounds are preset and unalterable to me. So now for txmt modding, I wear sunglasses in front of the monitor and do some templates to save my future works for repetitive editting. As you all can see from my screenshots, you all can guess the colour scheme I'm using for the comfort of my eyes.



This I've to go dig it before any possible comment. But, I may be able to say something about the in-lot sea water.

The in-lot sea water is done by the lotskirt gridlayer (defined in a lot file and/or the game engine) and its material is defined in the neighbourhood shader. For the sea water boundaries, I guess it's defined by the height of the lotskirt water level relative to the lot terrain level rather than by the sea region defined by the neighbourhood. I guess the beach-sea transition is more like an opened swim-pool and the beach portals are nothing more like some altered swim-pool accessories especially the diving board.

BTW, the animation for the sims to get in the sea is kinda unrealistic to my eyes. It just doesn't go along with the wave pattern, and they exaggerated the whole action too much.

The moving layers of waves are controlled separately from the ocean reflection and the ocean layer vibration, and they played like the neighbourhood surf waves in the neighourhood.


[roads & portals]



I'm using the base game to experiment with lot modding predominantly for the its full compatiblity to all game versions. And it takes a second placement in-game for the same object instance of Inge's portal revealer (the flamingo) to work in the base game. in other words, at the build mode of a lot without any family, after placing an object instance of Inge's portal revealer in a lot, a user has to pick and place back the flamingo again in order to initiate its function in the base game.

I guess that's the usage trick missed.

Previously, what I actually suggested is to place the portals, mailboxes, phonebooths and garbage cans to the regions that won't be affected by the lot rotation or the road rotation before a lot rotation or a road rotation.
Therefore, these objects will remain accessible by all means after either rotation. For this process, the hex editting is skippable.

Yet, the hex editting for the portal still lacks the manual instruction on the objt instance 0 for the graphical changes.

After all, the hex editting is still important to those whose lot's portals are already messed up. So, both ways are worthy and they can serve for different purposes and different degrees of usages.

I've got a reasonable tip for the portal position hex editting.
Should one fail to get the portals out with the suggested default values, they can always input "0" for all the portals, trash cans, phonebooths, mailboxes or else position values. Thus, regardless of lot orientation or other considerations, these objects will show up at the "origin" in most cases.



Believe it or not, there're always some readers who don't know how to read an unfamiliar interface, so the dummy books exist.
Certainly, even with a fast-and-easy outline, they may still feel lost because they just can't recognise the patterns yet. But, the act of outlining can help some of them to learn how to spot the things out with the most basic need. This can also help diminish confusion led by different terminologies for the same meaning.
It surely makes no big effort when one has at least some relevant programming backgrounds or one has a person with at least some programming backgrounds to direct the process, but even a small outline can help a lot for a hex editor noob.

yes, I meant to move them in advance before they become missed out. May read about that at the earlier part of this post when I respond to Mootlida for this. May not miss a trick I stated there, too. and you can add it in the tutorial without referencing me at all when finding it useful.

After all, your effort is worthy and great... Thank you with bunches of digital things as linked,
1
2
3


[record formats (lots and neighbourhood)]



Yes, I'm glad more ideas are placed out in the hope to help solve the puzzles..
but, the water level Inge meant might be just the lotskirt water grid layer but not the terrain water layer Mootilda meant, and they're separate things in a given lot.



That's the simplest way to create them graphically, and this is the same for the terrain water layer, the swim-pool, and many others. I've been showing the terrain one in the full version of my Kavar003 lot at its hidden basement.

By means of layering and masking, the irregular shapes are actually by the objects as the masks.



1. the neighbourhood water layer is not the same as the lotskirt water layer (the one used for the sea/ocean in the in-lot view), and so I guess this is not the one Inge was pointing at.
There're actually 3 type of water layers here:
- the neighbourhood water layer (for neighbourhood view since the base game and in-lot background view since EP2 NL)[This may be what Plasticbox guessed Inge meant]
- the lotskirt water layer (for in-lot view only since EP2 NL, including the "sea/ocean" of a beach lot)[this may be what Inge meant]
- the terrain water layer (for in-lot pond/lake/etc only since the base game.)[This may be what Mootilda meant.]
Their material definitions can all be traced from the material shaders.

2. a lot reload or a neighbourhood reload is necessary for the generation of the neighbourhood water layer and the lotskirt water layer from my experiences. I've not come across a case in which I need to reload a lot to generate the terrain water layer though probably because it's directly linked to the water tool.

3. for references first, the "beach lots" plasticbox stated are normal lots made in a process mentioned in the linked tutorial.
http://www.modthesims2.com/showthread.php?t=184564

The browsing worked well, especially since in this incarnation I was able to use the normal picker view to get as far as lot picking level before beginning the browse. I can't recognise my hoods and subhoods by their filenames, so I need the "human" names to get that far.

The shrinking did not destroy any part of my building, the side walls were still in place and so was the roof. I was able to carry out further building (I didn't try tampering with the side walls though as I assumed that would not be a good idea) and save without crashing. Obviously the post box etc was missing, but I was expecting that at this stage of development. There was a slight visual glimmering when I first went into the hood after shrinking, but that had gone after entering and saving the lot.

I put the lot into the bin, and placed several of it on the hood. Now this is where it came to my attention there is another bit of data that needs altering during shrinking, if we can find it. There is obviously still something that remembers the size the lot used to be, and is insisting on keeping that size of a gap between lots when I place them. I am using a very flat terrain for this test, and I believe therefore there is a value stored somewhere rather than being able to blame deformations to the terrain for not being able to place the lots adjacent to each other.

Later: Now I am not so sure the unclosable gap between lots is the same size as if the lot was original size, after all. I shall do further tests.

Inge,
have you tried to reduce or fix the neighbourhood W and H values before trying to place them next to each other?

No because I really don't understand it lol! I went pie-eyed looking at all those numerical explanations.

lol, let me be tricked...
Holloween is close...anyway...

1. Open the neighbourhood package in simpe,
2. choose the Lot Description file
3. input your desired Wide (W) and Height (H) values. (circled with magenta colour)
4. commit and save.
5. done.

Oh I see! I thought you were talking about hex stuff again :giggle:

Ok well as it turns out that wasn't the problem. It *was* my terrain after all. I thought I had a flat enough terrain, but in fact one corner of my lot was about 1 click higher than the terrain and that was enough to ensure I could not put the lots side by side I made a new SC4 terrain 100% flat and was able to make row houses.

Interestingly, if you make the house wider than the target 10 lot tiles and then shrink to the 10, the walls on the chopped off bits disappear but the roof remains the original size, overhaning the edges of the lot. The game seems happy to save after a token build activity in this state, and you can go in and out. But after you move this type of lot to the bin and place it again, the game crashes when you try to enter it.

The reason I was trying to do the process with an overwide building is that I hoped if the roof got chopped off it would not overhang. But in fact I didn't notice graphic glimmering against the next door houses anyway. The walls don't glimmer either, but the fences do! You need to only make fences on one side of each house.

I'm so glad that this is working so well. Normally, I do a lot more testing on something before putting it out, but I knew that you wanted the source code and I figured that putting out the EXE was no big deal. Looks like you're going to do some of the testing for me. Thank you for that. This was a big addition of code and I could really use the help testing it.

Your town houses just blow me away. I was honestly unsure whether this method would work or not.

Just remember, there may still be bugs. If you find something odd, please let me know.

I really don't think that this is something that I should support, anyway. I'm obviously going to have to do a new tutorial for this, and I really need to emphasize that the land being deleted must be empty. It's a bit frustrating to have a lot which appears to work well, until you put it into the lot bin.

I know that niol has been having fun fooling around with different sizes used for different record types within one lot, but I doubt that this will ever be supported, either (at least in a release build).

So, it sounds like this is working very very well. I'm so glad.

I'm really looking forward to playing this for a while. I love the idea of giving my sims large starter homes on a 1x1 (expandable, sunny) lot. We really have made excellent progress in a fairly short period of time. I think that we all deserve a pat on the back for everything that we've accomplished on this thread!

OK, then I'll consider those requests filled and will release this when I release the lot shrinking code.

Sigh, not "obviously". I thought that the new portal logic should move the mailbox, garbage, phone booth, etc, back onto the shrunken lot. I'll take a look at the portal code again, to see why the mailbox is missing.

Please let me know about any issues, however small they seem. Don't assume that I've seen these issues unless they've already been reported here.

Next, I'd like to allow "shifting" on the lot (that is, grow one side and shrink the other).

Then, I'll try to use lot-sized tiles, to allow people finer control over buidling placement on the lot.

Finally, I'll look at the neighborhood terrain issue again, to see whether I can get it working.

Still a lot to be done, I guess.

I'm assuming that the second Neighborhoods message actually had the title "Path"...

OK, so the problem was not in the area that I was originally looking at. Let me get rid of those messages and put in some new ones later on in the code.

Yes, I'd really like to get this resolved, too. It's obvious that my system and yours vary in some way which causes problems.

[Update:]

OK, that really helped. I believe that I may know what the problem is now. (Finally!) Please find a test version with a potential fix here:

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

It wasn't missing on my shrunk beach lots, but the difference may be that they were differntly oriented - ie I had to ask the LE to shrink the side in order to shrink at front or back.

The portals I did still have on the rowhouse lot were
Service Start
Car Stop
One pedestrian portal.



You've *sort of* inadvertently managed that - see the beach lot Shrinking it succeeded in moving partly across the road and party sideways. You see I remade the road with floor tiles on the lot itself




And every bit of it very much appreciated!

Inge, I'd almost forgotten about this issue. Are you planning to test whether this works with the test version of the lot shrinker?

I had forgotten this too! I will try it with a river. I just need to clear up this thing about front/back/left/right not really meaning that if the lot was an above/below etc. Cos I thought that had been sorted out once, so that when the LE said "front" it always meant the edge where the street was? Was that not fixed once?

aelflaed, I think that this may be your best course of action for your tutorial. If setting the X, Y coordinates to (float) 0, 0 will allow the user to access them to that they can use the portal revealer, then I think that you could avoid even mentioning the portal positions in SimPE unless the user has a problem with them.

I suspect that we should consider a separate "portal" tutorial for more complex issues... aelflaed's tutorial shouldn't need to do more than suggest using the flamingo to adjust the portals and then link to the more complex portal tutorial for any other issues.

For now though (until we have the portal tutorial), if the user can just set the X, Y coordinates to 0, 0 and then adjust them using the flamingo, I think that we've got a winning strategy.

Yes, you are correct. The LotExpander clearly has a bug in this area. Front should always mean expanding back from the road. Did this just show up in version 1.2.7.4? Or, did you notice this in an earlier version?

I only noticed it just now. I remember the very old versions there was this problem, but this is the first time I have met it again since you fixed it. It may be it only applies to beach lots...