OK, I spoke too soon. I was making some assumptions about how the file-open dialog worked. The more that I thought about it, the more I felt that I ought to be able to get something to work. So, I've implemented something which may not be perfect, but it should be significantly better. This will appear in the next test version.

Did the same thing for browsing for lots. So, now the file open dialog should only allow valid lot files.

I'm also going to try to get all of the other suggestions in before I upload another version.

Now only says shrink if shrinking is enabled.

I've changed Restart to put you back into the lot selection screen. If you want to change neighborhoods, just click "back".

If people would prefer going back to the neighborhood screen, I can do that. However, the lot selection screen seems like the most likely place that you want to be.

I've set the standard advanced text to black. Other text is red.

Sounds like we're getting there. I'm glad that the new interface seems to be working better.

Actually, I've never even seen the Object Workshop. Guess that means I'm not everyone?

Cool. Even if it's just a tiny thing in fact, this kind of thing makes it feel much better (useability-wise).


And you said something about the portals before, I don't find it anymore -- that you want to avoid double negatives (you're right actually): how about "Ignore portals"? "Leave portals unchanged"?



You want to put this in the *release* version? Are you sure?


In other news, I've just updated the shrinktutorial (stuck more warning labels on top, and tried to get across what's up with the "access violation") -- would be good if you could take a quick look. Link: http://www.modthesims2.com/showthread.php?t=254032

I just meant putting it somewhere in the actual modding forums, or R+D, so that we can assume a somewhat different audience .. however, I'm not sure how much sense that would make, since Build Mode is where people ask about this stuff and will be pointed at the tutorial anyway. For now I just changed it a little, see above.

"Enable shrinking"


I would have volunteered to do this but with the developments and conversation of the last 24 hours I now believe shrinking is *potentially* risky enough that normal players should not see something that will encourage them to think it's today's fashion. Therefore a more obscure thread for diehard experimenters would be more suitable for the time being. The MATY thread is probably as good as anything for now, along with the fact it's in "advanced options" and has a red warning. Obviously this position can change rapidly as we begin to understand it.


WRT the access violation, I am no systems programmer, so feel free to tell me I am talking rubbish, but I thought that because the log was written by the program (it's named by the program and is in the program's data directory) that the exception had been handled by the program. That was behind me saying I thought the program had failed safe.

Are all shrunk lots as unsafe as wall-at-the-edge lots? Say, plain "empty" lots?

I am not convinced the people with crashing lots are wrecking their hoods, there is no evidence of accumulating errors emerging and some of these people are experimenting with deliberately crashing the lots over and over and over again.

By accumulating errors I mean not the same predictable crash happening each time, but gradually things going wrong that didn't go wrong before.

Only if you've used the Object Workshop - I know I haven't. One of the great things about the LE is that it allows people like me who are NOT technical to play with things. These are the same people who are shy of SimPE.



I probably still don't understand really, but I'm prepared to believe people who do. I'm glad you are confident about the rotation code, in contrast.


I suggested 'maintain portals', I think that post was overlooked in today's frenzy.

Plasticbox, thanks for your comments on the rotation tutorial - I'll take them for consideration. And now I'd better go check on some other stuff.

Edit - I don't know, naturally, but Rascal had a good series of crashes with my shrunk-but-not-edge-built lot recently. In any case, if you want an empty lot of any given size, you can take a 1x1, sunnyside or original, and expand it with the tried-and-true LE capabilities. No stress involved, that way. I can't see why you would need to shrink an empty lot, myself.

I'm not sure any of us really have a clue yet. I feel as if we're all doing a good "headless chicken" impersonation at this stage :D

so, playing each shrunk lot per game-run can avoid potential corruption spread.among the same neighbourhood?

Also, I've never had a crash for the shrunken "blank" lot in the base game.

I'm running a series of tests in a new neighbourhood and will run each lot per each game rum to avoid such potential corruption spread if so.

All lots have light from the front right, shrunk from 30x30 to 10x20 by LE 127B.


1. "blank" lot:
2. with wall-at-the-edges, closed rooms, 2 levels:
3. with wall-at-the-edges, open rooms, 2 levels:
4. with wall-at-the-edges, closed rooms, 1 level:
5. with wall-at-the-edges, open rooms, 1 level::
6. with wall 1 row from the edges, closed rooms, 2 levels. with floor tiles at 1st level reaching the edges.:

All the same results :
no crash for a whole sims day, no crash for night toggle @ build mode.

Does anyone know? I feel as if I have reached the wall on this one (pardon any perceived pun).

Let's put it this way:- if my test hood carries on managing my own shrunk lot row houses with their walls and roofs right up to the boundary as well as it has been doing, I will soon feel happy to start using them in my main hood. However I probably won't use other people's lots in anything but a test hood for the forseeable future :D

So I was working on the Castle Courtyard Garden, part II, which includes an orchard. After shrinking both left and right side I had crashes on saving, and after a couple of trial-and-error found the problem: an apple tree placed to close (1 tile away) from the cut border. Took the two apple trees out before shrinking, no crashes on saving.
Dont know if this is helpful, but anyway.
(I have all expansions, no BV patch yet).

Ingeli, was the tree a four-tile tree, and was any part of it overlapping the cut off bit of your lot?

It was an apple tree (seasons type, blossoming and giving fruits), with a 1-tile footprint, not placed outside the borders, but one tile from the cut off - my suspicion is that the tree, in spite of the footprint, has stuff that is much bigger than the footprint (like the blossom, the fruits, the unattended state) and that some part of it was cut off and made the lot crash upon saving.

Oh, and to solve the problem I just expanded the lot back to what it was, took out the trees, and then shrunk it. Then it saved fine.

I have changed my mind on this issue. I just did what I probably should have done when I came in one morning to find the shrinking version of the LE downloaded 100 times: I went through this thread and removed all source code and executables for the shrinking code. I also changed my creator policy to discourage sharing of the test versions of the LotExpander / LotAdjuster.

The source code changes that I made have not been lost. They are disabled in the latest release source code and can be reactivated very easily, by anyone understanding C#.

I realized last night (I do some of my best thinking while I'm asleep) that I have been handling this issue all wrong.

I understood the possible severity of the crashes, but allowed myself to be convinced that people wanted this anyway - not realizing that other people might not realize what an "access violation" implied. Although I had warned about possible neighborhood corruption, I should have done what I could to restrict the shrinking code until it was either fixed or found unfixable.

I apologize to everyone for this.

However, it's incorrect logic to do nothing because you cannot do everything.

I know that I cannot prevent people from sharing the shrinking version of the LE / LA, no matter what I do. That doesn't mean that I should help them by making these versions easily available.

I am considering making the following changes to the LA:
- The shrinking code will be disabled by default.
- The test version of the LA will have a config file available. In order to access the shrinking code, the user will have to edit that config file to enable shrinking.
- The config file will be unique for each machine that the LA runs on, which should prevent sharing of config files and encourage users to make the change to the config file themselves.

I'm hoping that this will discourage casual use, but allow dedicated simmers to continue to shrink lots. Would this work for people here? Does everyone here know how to edit a text file?

In the interim, I'd like to take a break from working on the shrinking code right now.

I had several restless nights after the shrinking tutorial came out (Oct 24th?), worrying about possible lot and neighborhood corruption for simmers who were not aware of the risks. Finally (Oct 28th?), I was convinced that people wanted this feature, even though it was dangerous. I had a restless night last night wondering about what to do, now that I realized that people had not actually understood the risks.

I've felt out of control of this issue for a week now. So, I'd just like some time for things to calm down.

Hope that's acceptable to everyone. Now, I'm off to read and answer the latest set of posts.

Those are both still double negatives, although perhaps better. I think that what we need to do is focus the attention on what the user gains by using this feature, rather than focusing on what the program avoids doing. ("User must manually place portals."?)

No. I continue to believe that the shrinking feature should not be released until it works correctly. However, even in the test version, I would prefer that the feature stands out as dangerous.

I'll take a look at it now. Perhaps irrelevant until the new (safer?) test version of the LA comes out. I'm sorry if we're working at cross-purposes.

Mootilda, you can only be expected to create and publish what you feel comfortable with. I'd be disappointed if I could no longer decide for myself to take the risk and shrink lots, but you're still going to let us do it by editing a config file. I think it is generous of you that you're prepared to put in the extra work to implement that anyway, you could have just decided you were fed up with it all and pulled the whole lot.

One day soon I hope, there will be a breakthrough in understanding what was going wrong.

Done.

I assume that EA wanted to manage the amount of information (about the internals of the game) that would be available outside of the company. So, in order to restrict the amount of useful information in the crash log, they have a top level exception handler which puts out less information than usual about crashes. This in no way means that the game has been managing to avoid corrupting memory. It just means that EA is using a feature of C / C++ to catch the problem at the point where they are crashing, and to restrict the usefulness of the output just before the game dies. Does that make sense?

This is very similar to what I did with the LA - I put in a top level exception handler for the release build, so that people would stop accepting crashes which might cause corruption of their lots. Of course, the LA exits gracefully without crashing, but I didn't spend the time writing out a crash log. Instead, I ask people to attach their lot to the LE thread, so that I can debug the issue myself.

As far as we can tell from the work that you and Andi have done, shrinking an empty lot is much much safer. Still, I would test such a lot before putting it up for download.

Until we know what's causing the crashes, there's no way to say what's safe and what isn't. The fact that Andi's lots have been used extensively leads us to trust them.

I wish that I had access to the Sims 2 source code, so that I could answer more definitely about what the game can and can't handle.

Does the OS send an error message to the application that gives the application time to write this log? Or does an application come with some form of instruction file that the OS uses to write the log for it as specified?

I think Dizzy has a way of reading the exe...

I agree. We don't know whether the roof testing implies neighborhood corruption or not, although it's our best current evidence.

Unfortunately, there are only two ways to know whether the neighborhood is ever being corrupted:
1) Debug the source code. (Preferred method)
2) Test and test and test. (Our only alternative)

Even if we saw neighborhood corruption, we'd have no way of telling whether it was the lot shrinking code, or a problem with the existing game code unrelated to shrinking. That said, the lot shrinking code would be suspect if we could prove neighborhood corruption, since it's newer and less well tested.

I'm not sure what "maintain portals" means?

Beach lots.

The good thing is that there is a core group of testers who are testing very methodically so if the problem begins evolving it will be fairly indicative of being related to this activity.

It depends upon whether you are using the same saved neighborhood or not. If there is any neighborhood corruption and you save the neighborhood, then we have to assume that the game saves the corruption. If you then use that neighborhood for further testing, that corruption would have the potential to work its way into other lots.

Of course, you need to run with the same lot(s) and neighborhood when you are looking for long-term corruption issues.

No problem with the text file approach.

When you say "test version", are you referring to 1.2.7.8? Or to the next version?

Also, where do the instructions go on how to do this, in your opinion -- into the download thread/post of the version with shrinking potential (whichever that will be)? Or in the shrinktutorial? Or somewhere else?