Yes, I'd love to see a rotated non-shrunken lot up for sharing. Possibly with a note that it's experimental but we expect no problems? The sunneyside lots are a good first test, but I'd appreciate something more complex, just to be sure that we don't get any problem reports.

The worst thing is that I'm trying to implement all of the additional UI feedback as I go, so that nothing gets lost. I'm really still working on Friday's posts.

But don't worry about cluttering up the thread, if this is where it belongs. I'll catch up, eventually.

Adding and removing roads should be reasonably safe, unless you remove the front road and there is another road somewhere - not so sure about that one. Would anyone like to test this and let me know? I think that some U11 (lot rotation) values may be more interesting than others, so you might want to try it with a couple of different lots.

I know that if you change the U11 (lot rotation) without changing the corresponding U10 (roads), you can end up with a hole in your neighborhood where your lot used to be (from Andi's original thread, although of course I had to try it myself and see).

Disassociating lots from roads should also be reasonably safe. The only possible problem that I can imagine is a change in the lot's height above terrain.

Oh, I removed the "reset to defaults" button, since it's basically identical in function to clicking "Standard...". If this is a big mistake, I can add it back, but I'm trying to keep thing less cluttered - this is becoming a complex screen.

Since we don't know what's causing the problem, it's difficult to say for sure.

However, I am basically following Andi's method of changing the size of the arrays and then removing unnecessary array elements. The main difference is that he was suggesting just truncating the arrays (since all array elements should be identical in a flat empty lot) whereas I am removing the correct elements from the arrays, based on U11 and where the lot is being shrunk.

Because of this, I honestly believe that empty lots should work perfectly, expecially if the LA moves the portals.

We really need to do some testing on standard houses on shrunken lots - that is, no building on the pre-shrunken lot which could not be created in-game on the shrunken lot.

As well, I think that we should be testing shrunken lots which break the 2-tile rule for walls, but still keep the walls 1-tile away from the edge.

Results of these tests may help lead us to an answer about the problems with walls-on-the-edge lots.

This is one of the reasons that I really value your input. I want to make sure that the average non-techy simmer can continue to use the LA and feel comfortable.

Ouch! I missed this over the weekend. Were the walls 1 tile from the edge, or two?

While I believe that the crashing is caused by something in the LA (either bad code on my part, or missing code, or even allowing people to do things which the game doesn't allow), I think that it's very unlikely that the LA is only partially completing the changes that I've actually added code for.

There is a try-catch block around the entire shrinking process. If any errors occur, then an exception handler takes over. The exception handler only does one thing: set a flag which tells the LA which final message to display. So, I just don't see how it could be failing to complete the shrinking process, but also failing to tell the user that it failed.

I hope that made sense. I think that this is a very unlikely explanation.

It seems possible, but unlikely. Since we know that the game crashes when it can't get resources (talk about poor error handling!), I suppose that it couldn't hurt for us to list our specs (although, I think that many people don't actually know their specs).

However, I still think that the game is having problems with something in the lot package itself. Just a guess, but what's the likelihood of me getting the code 100% right the first try? The most likely explanation for the crashes is that I'm not perfect - and I think that the most likely imperfection is my lack of modding knowledge. You have to remember that I only started working on the LE in August and the LE / LA is my first and only modding project.

Anyway, I have two machines side by side. One is severely underpowered to run the game. I suppose that I could port some of my shrunken lots over there and see whether they crash... Luckily, I won a free copy of the Sims2 Deluxe, so I ought to install it somewhere... my internet machine seems like a reasonable choice.

Kind of off topic, but there's a checklist and much of it is UI stuff, registry access, where files are stored, ... stuff that shouldn't be that hard to get right. Unfortunately, once MS decides to ignore their own rules, it sort of sets a precedent for everyone else.

Again, very unlikely. Compression algorithms usually have error correction built in, so that they are more robust than standard files. I've never seen a zip file that didn't give an error if it was incomplete or corrupted.

While I appreciate everyone trying to blame someone other than me, I think that the most likely explanation is the LA code itself.

Just an aside: I thought that it was really funny that someone on the MATY thread tried to blame Microsoft for all of EA's poor code!

Yes, I was particularly concerned about whether this would be difficult for you. I'm not sure that a config file is the best solution, it was just an idea which should discourage a particular set of simmers. Unfortunately, I'm not sure that it discourages the right set of simmers.

I realized last night that I should really ask the more experienced people here: What is the best way to restrict access to downloads? Is there any mechanism on modthesims2 for specifying a group of people who are allowed to download something? Is there any other way that I can do this easily?

Of course, this is all because of you. I used your research (and your tutorial) to get this information.

I think that the portal logic still needs some work. I'm changing the value which controls the functional direction of the portals, but there seems to be a separate display direction as well.

Good catch. I'll fix that.

Sounds like expected behavior. If the "corner lots - adding and subtracting roads" tutorial ever gets rewritten to use the new LA, we need to remember to mention this.

I've been waffling about this issue all weekend, but I've now decided.

Yes, I think that we should remove any mention of shrinking from the tutorial for now. I'm really hoping that we can fix this feature properly and then you can put it back in again.

I believe that advice only applies in two cases:

1) Row houses, because the terrain needs to match on the left and right sides of each house, so that the game will allow the lots to be side-by-side in the neighborhood.

2) Lots which are shrunken at the front, because I don't have the "flatten roads" feature in yet and the game prefers flat roads.

Other than that, I can't think of any reason why you can't use bumpy terrain... oh yeah, I forgot:

3) I still need to implement the "smooth edges" feature. Until then, there's a possibility that shrunken lots on bumpy terrain will have some blue "disconnects" in the neighborhood.

Did you move them in-game, or using the Move Lot feature of the LA? Neither of these is a dangerous operation, but moving in-game might add the road back in at the edge of the lot.

My thinking is : IF it is a possiblity, it should be ruled out. A look at people's specs along with the other things gathered when the crashing occurs would help rule out their systems as the culprit--but just because I think this doesn't mean it's right! lol....

Beach lots: I had four lots set up. I've actually messed with 3 of those. I placed them side by side and made the same modification/build action to 'initialize' them. The first I took and shrank by 2 on the right only. The next I took and and shrank by 2 on the right and at the back, the thrid I shrank on the right and at the front, but left it tied to the road. I wanted to establish for myself if there appeared to be significant differences in the direction of shrinking. I still have the left and not tied to road combos to try out.

So far those: the portals appear to be moving fine, altho somewhat weird as they appeared tobe sunk into the ground. A bit odd looking and I am compulsive enough I had to move them to make them look ok even tho we don't see them in game play lol, they function fine (set a new sim swimming on each of the 3 lots.)

ONE-- the lot shrank on the right only-- had the blue tear on both sides and at the back of lot edge, in the water in this case. I set it down entered it bult a wall segment fixed the portals, saved and exited. Moved it to the bin and placed it again and the blue tears on the sides were fixed. The blue tear in the water was too, but upon moving the lot again, the blue tear reappeared.

I think this reappearance was due to being placed on a different terrain and the slope in the water was different. I wonder if leaving the portals sunk would eliminate the reappearance too as the beach portals, as Inge found, are the 'stairs' into the water and affect the slope there, just like a modular stair can affect the slope of the spot they're placed on.

I remember Mootilda was trying to make the lots 'fit' the terrain instead of the terrain fitting the lot which might be really good for the beach lots. I'll try to lay out a lot and not move the portals and see what happens.

The 2 other lots had much the same results, blue tear on sides, TWO, shrank on right and in back, had the blue tear in back, in the water just like ONE did. tears at the sides resolved themselves on the second move, the one in the water never did disappear.

Oh--this in the water blue tear always looks lower than the hood terrain--looked lower on both ONE and TWO

With THREE, the lot shrunk on the right and in the front, also resolved it's side tears. However, it did not have the back, in the water, tear. Instead it had a raised, peaked area in that last line of squares in the water, the corners though dropped to normal hood terrain level as they should have. Why it did this boggles me a bit and I'll mess with front shrinking some more, trying tied to road and not tied to road to see what it coughs up.

I don't know enough to look in the lot files themsleves. I can make SimPE do it's thing, but I don't know what to look for so I would not recognize anything of signifcance in it. But if someone cares to direct my efforts, I can do the actual footwork and report, like a good like droogie..?

I would like very much to come up with a series of smaller beach lots that we can simply offer for DL, like Andi's little lots. I know I would use these like crazy, can only assume others would like them too.

I think that you are talking about the fact that Andi's code used to change the neighborhood package, then crash when it tried to open the lot package. This behavior has changed. I decided that it was safer not to alter the neighborhood package unless the lot package change succeeded (based on error reports from sorcerer's version).

If we want the LA to handle empty lots, I'll need to do change the code to allow that specific option.

That's not good. Please give me more information (like config file names), so that I can try to fix this behavior.

I find that very odd. We should always be seeing width x depth (ie, 3x6 instead of 6x3). Which version of the LE / LA were you using?

Yes, I'd like you to go into detail. You might want to check out Inge's tests first, since there's no use duplicating information.

We know that the terrain changes aren't perfect yet, but it can really help to see pictures.

I'm not changing the z-value (height above/below terrain) for any of the portals. I planned to do this in conjunction with the flatten roads and smooth edges features. At the moment, the water portals are just handled with the standard object logic. This implies that the water terrain height changed when you moved the lot in the neighborhood.

We think that the edge logic still isn't quite right. Based on tests, it looks like all subvertices between the main vertices (at multiples of 10) need to be linear - we've been referring to this feature as "smooth edges".

I assume that you are aware that U11 (lot rotation - shown in the newest LA as the sun direction) makes a huge difference to how the lots are expanded and shrunk, because it determines how the various arrays are interpreted.

What this means in practical terms is that lots have a "preferred" direction of expansion and shrinking. If you get poor results with one lot, try creating a lot with a different rotation and it may shrink better. Unfortunately, creating beach lots with alternate rotations is more difficult than it is with normal lots. If you don't understand how, let me know.

You should definitely test a lot without moving the portals, to see whether the portals function correctly, as well as the effect on the blue disconnect.

If you need it to get the beach lots working well, I can certainly look into implementing the smooth edges feature.

Can you attach some pictures? They often help me to understand what's happening inside the lot package.

The arrays are really difficult to deal with in SimPE, so I doubt that it's worth trying. Give me some pictures and good explanations like this and I'll try to give you some potential fixes in the LA.

Yes, that would be great.

Well, I typed in a fairly long explanation for this yesterday, but then modthesims2 went down and my explanation disappeared. Silly me, I should have saved my answer before submitting it, but I was distracted and ...

So, today you get the short answer.

There are two mechanisms for exceptions. In both, the O/S finds the exception. In the first, when the game starts, it gives the O/S some information about how to handle unhandled exceptions. When an unhandled exception occurs, the O/S follows those instructions on behalf of the game.

In the second, the compiler acts as a liason between the O/S and the game, giving the game a chance to do something when the exception occurs.

However, no matter which technique EA is using, this is a last ditch attempt on EA's part to get a bit of information about the problem before the O/S takes the game down. This cannot be considered to be proper error handling in any way whatever. By the time that the game gets a chance to do something, it's completely lost track of what it's doing. I doubt that the game would know, for example, what neighborhood it was processing, or which lot, much less what it was actually trying to do.

True error handling has to happen at a much lower level. It's possible to use exception handling as an effective error handling technique, but there usually needs to be a separate exception handler for each piece of code - sometimes multiple exception handlers for one piece of code.

If EA had proper error handling, you would never see a crash.

Hope that answers your question. Sorry it took so long.

They don't work like stairs in that sense, they don't alter the ground level as you place them. You have to sculpt the ground yourself to fit the getting into the water animation (that is if you have placed a new beach portal yourself).

Thanks for the vote of confidence.

I was about to point to that lot Rascal tested, in answer to your previous post, but you've seen the info already. I carefully built the house within the proper Maxis parameters, so walls were two tiles from the edge on three sides, and one tile from the footpath - which means an automatic roofline there, but it does work without modding the lot or the building.

I can post the lot if you want it.

I liked it, but I can't now remeber whether the 'Standard' option was just as satisfactory. I definitely appreciate the safety net of putting everything back the way it was, without having to remember what that was.



I'll do that then. That will also allow me to include some of Plasticbox's suggestions in the same edit. Tomorrow, hopefully, I should have time for that. Hey, the attachment might get approved if I change it!

Yes, my second test upload was on flattened (not originally flat) ground at the rear, and there were pretty blue triangles all along the back half of the block.

I'll check in again tomorrow. I reckon you qualify for one of those new pretties - the Latte, I think it was. You're doing a great job.

Yes, I think that this would be a useful lot for me to check out. I think that it makes sense to try to get the easy stuff working before we try to get the hard stuff working.

There never used to be a "Standard..." button; it replaces the "Reset" button. There is one difference between the two buttons: Reset would reset the advanced options but leave the advanced options displayed. Standard resets the advanced options and closes the advanced options display.

I changed this because of the change in the advanced options display - they used to be displayed on a separate screen, but now they are displayed on an expanded section on the normal expansion screen.

Thank you, that's very kind.

Just got an interesting PM, where someone suggested that somehow the LA creates lot corruption which is so bad that the game will overwrite non-game files on the disk.

No, it does not do this.

This may be a misunderstanding of my previous attempts to explain what an access violation is.

Let me be clear about this:

I'm not changing anything about the way that the game works. I can't imagine that EA actually wrote the game in a way that it would overwrite arbitrary files on the disk.

As well, the operating system prevents the game from overwriting memory which doesn't actually belong to TS2, so that it can't corrupt other running programs and somehow convince them to overwrite their own files with garbage.

However, the game does overwrite many of its own files that it probably shouldn't be changing. I've noticed that all of the neighborhood files change, even if you have only played one neighborhood. As well, I've noticed that the game often overwrites a lot of character files that have probably not actually changed internally.

To me, this seems like a very poor design, since it encourages TS2 to corrupt game files that it has no reason to be overwriting in the first place. As with most of the poor coding choices that EA makes, I suspect that they just didn't have the time to do the right thing.

The most likely place for the game to expand any corruption is within the lot package itself. Less likely, but still very possible, are corruption of the neighborhood package and the character files. Even less likely is corruption of other neighborhood files within the current game directory, although any file that the game changes may be corrupted if the game is lost enough.

If you see people spreading this bizarre statement (about the game corrupting other arbitrary files on the disk), please dispute them.

Just remember, a lot of what you read on the internet is fabrication. People say things that are not true, and people misunderstand things that are said, then spread their misunderstanding.

That MATY post about EA's crashes being caused by Microsoft's optimization code is a prime example. Someone made a wild accusation that is not true. But, enough people will read that post that I'm sure someone will start spreading it as if it were true. Frequently-repeated fantasy becomes fact in some people's minds.

Mootilda, I was using 1.2.7.11 (I think the zip was labled xx7B) I wanted to try the xx10 but it wasn't shrink enabled and I didn't see instructions for enabling it--did not go back and read carefully yet, but I will when I have more time (BTW, no config txt files would stop me if I really wanted it maybe this is the difference between those that should be allowed to enable the shrink v those that should not.)

I'll get the names of those config files (Broadcat.ini was one, and then two others I think), but I don't think it was the LA's fault. I think it was probably the LA trying to work from XP and trying to impliment changes on Vista--making it a Vista problem? I don't think you don't need to worry about it--how many times will that combination happen anyway?--unless a number of others complain about it. Maybe I shouldn't have mentioned it....



Oh. Did you successfully 'sculpt the ground'? I tried sculpting (raising/lowering) the ground in the water and it appears it can't happen. (I wonder if the 'unlocking all tiles' function will allow it--don't know enough about that function...will investigate it more.)

I see that floor tiles can be placed on the water which is good. We can place columns on the underwater slope (moveojbects on) and that gives the option toplace the tiles.

PS: This game has historically corrupted on itself and anyone playing it, dls, no dls, SimPE, no SimPE, LA or no LA should know to make BACKUPS regularly and often. Do the sheep, the 12 and under know to do this? I know my son would have when he was under 12.

"boolProp Constrainfloorelevation false" should do it.

Both. I made an Entrance for Old Town, with two towers on each side, arch over the road. Packed up and installed (outside game) in lot bin, placed at second entrance, moved with LA so it fit that entrance. Yes the game make a new road if you move the lot, but then you just move it to the right place right with LA after. Works well. No crashes. After that I tried to just move one to lot bin too, worked as well.

I noticed the blueish gaps. Placed side by side with another fitting lot they dont show, but smothing of edges would be excellent :D

Did I say thank you for this amazing tool? And thank you for all you hard work

lol--so simple. Thanks. (can you guess--I rarely use that cheat? lol)

Mootilda--attached are the beach pics I took. I tried to label them with what the pic is about. If they aren't clear as to what they are, I'll elaborate.

May I ask why you are even doing this? Why would you want to use some arbitrary old test version (1.2.7.10)?

Oh, by the way B is hex for 11, so version 1.2.7.11 is in LE127B.zip

Current instructions for enabling shrinking in any version which doesn't have it:
1) Get a copy of the Microsoft Visual C++ Development Environment.
2) Figure out how to modify the C++ code to enable the shrinking feature.
3) Compile and run.
For now, there is no other way to enable a disabled shrinking feature. IE, I haven't implemented a config file yet.

The shrinking code has not changed since 1.2.7.8. I *have* corrected an LA crashing bug or two, but I don't believe that this should affect lot shrinking at all - if the LA isn't crashing for you, then 1.2.7.8 should be sufficient.

Mostly, I've been trying to get a reasonable UI for adding other features, such as movement of lots, and adding and removing roads. For these very simple features, the UI is the hardest part.

Most test versions after 1.2.7.8 were put out to test the new UI and additional features, possibly in conjunction with shrinking. Some test versions are put out to try to debug specific issues and have no need for the shrinking feature. Some test versions won't even allow you to expand a lot, since it's unnecessary for the testing that I need done.

I am not trying to stop people from fooling around with the lot shrinking code, although I'm not sure that continued testing with these versions is useful to me. It's clear that there are major problems and that the problems can expand over time.

I am trying to stop people from using the lot shrinking code to create anything that they actually care about or want to share, since there is a very strong probability that these lot files are corrupt and unfixable, and a (less likely) possibility that the neighborhood and character files are being corrupted by the game when it tries to use a corrupt lot file.

The only exception that I currently know about is completely empty lots. I believe that the LA may be able to create smaller beach lots which are not corrupt. However, I would suggest testing these lots thoroughly. Either that, or wait until we have a version of the shrinking code which creates shrunken lots which the game can handle.

Sounds like you may have been sharing at too high a level. When I tried it, I shared a specific neighborhood directory (N009) with read/write permissions. This prevents the LA from attempting to change anything else on the disk. If you are sharing a directory which has config files in it, you should probably reconsider.

Unfortunately, many (most?) people who play this game do not know how to backup either the game files or their system. There's no need to insult them, though.

The LA is aimed at people who have an understanding of how to backup and restore their game files, but who might not have other technical knowledge. I hope that you can see the level of expertise that I expect from the LE tutorial, and the post on recovering from errors.

This is why I have been so concerned about the lot shrinking code. It became more widely available than I was expecting. From under 10 testers, we went to hundreds of people testing a product of this code, who might not have understood that these lots might be dangerous.

I don't want this to happen again, so I'm taking a break and thinking about how to restrict access until the code actually works.