Thanks niol. That was very helpful. It's nice to have some concrete steps for people to follow, to try to track this thing down.

Once I'm done with the move code, I have a house that needs debugging. After I've resolved that issue, I'll look into the OBJT records.

Don't take it personally. It *is* a bit confusing, for many users -- they don't think of the road as part of the lot, because Maxis are calling a 3x3 a 3x2 (dumbed down like so much else in the game) .. that's what everyone is used to. I think it's not so bad if people ask those things: once there is an answer, it's cleared up. As opposed to everyone thinking silently "this shoddy piece of crap can't count to 3" I mean, and never saying anything about it .. that would be much worse, wouldn't it?

I also think that the LE interface could be worded more clearly in that respect. Will post a suggestion in the LE thread (yes I'm aware that it will change anyway).

I can't remember what it was now. I just set used the binary edit box to set the first bit to 1 so the number started with an A. But the game keeps setting it back again. Each time I change it, play the lot and exit the game, that bit is unset again.

Perhaps the correct solution is for the LotExpander to subtract one when displaying the old and new values. Then, it will match what Maxis says in the game, rather than the internal data.

I'd also love to change the display so that there was more consistency in the display. For example, I tend to think of AxB as A=Width and B=Depth. However, I think that Maxis is inconsistent; they sometimes show the Width first and sometimes the Depth first. If so, I suppose that the LotExpander should be inconsistent in the exact same way that the game is.

Can anyone confirm whether this is currently true? IE, is Maxis inconsistent with the in-game display of the lot size? If so, does the LotExpander match this inconsistency?

Anyway, a proper beach lot shrunk ok. Shrink from front of course or else it chops off all the swimmy areas. Of course lot needs to then be moved to the place with the narrower land between the sea and road, otherwise there is a gap between the lot sea and the neighbourhood sea, which looks silly. And you can't place the shrunk lot on a space that would have taken the original lot, because the lot would no longer overlap the water slightly so the game refuses to accept it placed there.

But anyway it was fine for what I wanted, which was to get places you could bathe along my narrow promontary.

Do you mean when it says eg "5x3" it doesn't always put the width along the road and the depth away from the road the same way round? No matter what it does, it would probably be helpful if the LE made it clear which was which - and then it won't matter what order you display it in. So instead of saying "5x3" and showing one figure reducing, you have each figure labelled as to whether it's the width of the depth. Eg display "Width=3, Depth=5" Otherwise I find myself clicking one of the arrows just to work out which was which.

As for the stuff about the LE calling a lot 6x3 when the game calls it 5x3, that's trickier. Now that we can have 1x1 lots that are only the road area (yes I plan to use one to build an arch over the road) the LE would have to call it 0x0 which is weird. Really it's Maxis who (technically) called them the wrong thing, assuming we'd never find out the road was part of the lot :D

I like LotAdjuster, for what it's worth.

Inge, I LOVE the park idea, and you've got it working! Must go and make one too...



Mootilda, I agree that being able to easily move lots independent of the road would be marvellous as part of the utility. Better title for the second option might be 'move lot to the side'.


I'm very sorry someone went overboard - the rest of us do appreciate you, you know!

For the lot sizes, I think Maxis gives the road axis first? I'll have a look when I start the game later. I think it might help for LE to put (road) next to the appropirate value. Of course, if you're making a stranded lot a la Inge, that might get tricky.

Should I remove/edit any of my old posts to clean up this thread?

WARNING to everyone:

This is an UNSUPPORTED TEST version of the LotExpander (1.2.7.11). 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

Please Note:

If you are looking for the TEST version of the LotExpander which includes the ability to shrink a lot, please use version 1.2.7.8:

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

There is no need to download a newer version.

This test version is for people who want to test the ability to move a lot within the neighborhood. Please do not download this version unless you intend to test this feature and provide feedback.

Changes from 1.2.7:

- The LotExpander now has the option of shrinking the size of a lot.

1. Land to be removed must be completely empty of objects and sims. If it is not, shrinking the lot may result in lot corruption and unexpected crashes. If a sim is currently interacting with an object on land which will be deleted, stop your sim and direct them onto the land which will be kept.

2. Shifting a building on a lot has not been implemented. If you shrink in one direction, you cannot grow on the other side of the lot. However, these two operations should be able to be done in two separate runs.

- There is now a Browse button on the Lot Selection screen, to allow you to choose a lot based on lot number or date, rather than name.

- The final screen now has a "Restart" button, which takes you back to the initial screen.

- Resolved an issue where the LotExpander would crash if it couldn't determine the primary neighborhood.

- An intermittent problem with missing fence posts after expanding or shrinking a lot has been fixed.

Changes from 1.2.7.8:

- Moved the "Over the road" checkbox to an Advanced Features screen.

- Added a new Advanced Feature: Automatically move portals (Default: Yes)

This option tells the LotExpander to automatically move the portals to their correct location, if possible. Turning this option off will leave the portals in their original locations on the lot.

- Added a new Advanced Feature: Align lot to road (Default: Yes).

Turning this option off will allow you to specify two numbers:

1. Move lot back from road: the lot will be moved back from the road by the amount specified.

2. Move lot to the left: the lot will be moved to the left (when viewing the lot from the road) by the specified amount.

Suggestions on wording will be appreciated. I realized when typing this that the second option should probably be called "Move lot" Default: No. This wording can be easily changed in the next test version.

Testing:

Here are some of the things which need to be tested:

- Expanding a lot without specifying any movement (default behavior). The lot expander should keep the lot in the same place in the neighborhood, moving it if necessary to have the new road in the correct location.

- Moving the lot without expanding it. Watch out for movement in the wrong direction.

- Moving lots with all 4 Orientation values and with all 4 U11 values (code coverage). Again, watch out for movement in the wrong direction.

- Expanding a lot while moving it. Look for unexpected behavior - moving too much or too little because of a conflict with the expansion.

Please post what you have tested and the results of the tests.

Known Issues:

Sorry, I made a mistake which can lead to a crash. Do not click on the Back button from the lot selection screen. Instead, exit the program and restart.

[Update:]

Removed test version. Newer versions for both release and test now available.

(ok if you reply here, I'll also reply here =)



That would be the most user-friendly solution, of course. There is no way to make a Nx1 lot (which would be displayed as Nx0, possibly scaring people), is there? -- but then that would even make sense, if we're thinking of lot as buildable area .. there would be no buildable area left.

But wouldn't it collide with the option of road-less lots? They'd actually be 2x2 when they're technically 2x2 (and not 2x1 like Maxis would call it).



You're absolutely correct there. I think this is an international standard. It would be really stupid of Maxis to violate this (not that it would surprise me all that much though) .. I never checked this in-game though.

If they did, I wouldn't follow the inconsistency -- I think this tool is being used mainly by people who are capable of logical thinking, and it'll only irritate them no end. I'd rather write "width" and "depth" somewhere.


Anyhow, I quickly whipped up a suggestion of how one might reorganize the resizing screen, so that the road issue becomes less confusing. Below is a screenshot.

* "Over the road" is an option that only concerns the front yard, is that right? (if unchecked, the current lot area is moved back from the road to make room for more front yard -- if checked, it stays where it is and the lot grows across the road -- is my interpretation correct? I never tried it) If this is so, then the checkbox should go next to the "front" option, not somewhere below. Is this actually proper English, "Over the road"? If it's not and if you do a major UI revamp anyway, perhaps it can be changed to "across the road" or whatever is better .. but of course changes are dangerous, since this feature is already referred to as "over" in so many posts.

* Localisation: I've no idea whether "Old size: 1 x 2" (for example) is being displayed as one string or two .. if the latter, it may not be possible to put it in one line ("Old" might be "yükkielöööomnainehioraiootyieqwrtzuiopü" in Finnish and collide with the numbers)

* I'm on a mac, so the text I added looks different. Not meant to be bold or anything, I was just too lazy to retype everything.

* Actually I think Old size, new size, maximum size belong together (somewhere outside the "enter stuff here" box) .. either that or somehow manage to tie them in with the front/back/left/right stuff in a logical fashion. Haven't had an idea for such a logical fashion yet.

* I don't know much about Windows UI standards. Not sure if it's actually correct to display a changing value (New size) the way it's currently done? It does not feel right to me, but I'm a spoiled mac user.

What do you think?

Yes, that's my favorite choice, so far. I'm still accepting suggestions, though.

Well, you're in luck! I just uploaded a lot mover and I'd love for you to test it.

But, which side? I've been trying to figure out some way to make it really obvious to people. Can't seem to come up with anything good. Especially because the neighborhood may be rotated, so the top left of the neighborhood may be at the bottom right of the screen.

I think that Maxis gives the lot sizes based on the U11 value of the lot, but I'm not completely sure about that. Since I'm programming right now, it would be helpful if someone else could run enough tests to confirm this.

I'll leave that up to you. Please don't delete anything unique though... if there's duplicate information, it might be a good idea to try to remove the duplication. I've also been wondering about changing posts to make them contain more information, so that we can consolidate everything that we know about a particular issue in one concise post.

Sounds like a lot of work... why don't you test the lot mover instead?

I like this idea. Do you think that this matches how the average simmer thinks about lots? What happens if the lot has two or more roads (like the Broke residence in Pleasantview)?

Surely, you mean 1x0? Or is that 0x1?

I'm not sure that the LE allows a 1x1 lot, including the road. I may have to add this ability. I suppose that it only makes sense to allow this with "over the road"?

Goodness, Igne, you certainly like to keep me busy!

Lots with no roads, lots with multiple roads, lots built over the road, ... The more that I think about this, the more that I think Andi had the right idea: just use the sizes from the neighborhood package. I just need to make sure that it's more clear that the numbers include space for the road(s).

Thanks. I agree that the main screen could use an overhaul. I've basically been leaving it the way that Andi coded it. The recent issue with the size of the lot is the first complaint that I've received.

Yes, this is correct.

"Proper English"? Isn't that an oxymoron?

The first time that I saw that option, I had no idea what it meant. Then, I saw a picture of a building with the second story build out "over the road". The concept became crystal clear.

I honestly don't know whether "across the road" is any more clear than "over the road". Perhaps "build on both sides of the road"?

I wanted to unclutter the main screen, so I already moved the "over the road" option to a separate Advanced Features screen, along with Inge's special requests. Take a look at the newest test version 1.2.7.11, to see what this new screen looks like.

I've basically given up on localisation for now. Things are changing so quickly that it would be impossible to localize the LotExpander at this time. Perhaps when things calm down a bit...

I agree with this. Front and Back are really related to Depth, just as Left and Right are related to Width. Perhaps grouping them in that fashion might make things more obvious.

I'm guessing here, but I believe that Andi coded it this way to work around an annoying Visual Studio programming issue.

I think that I'm really not a user-interface person... I find it difficult to word things in a way that makes them obvious and I've been leaving the main window alone because I can't figure out how to make it better. Still, your ideas seem very reasonable. Let me mull over this for a while, and see whether anyone else has any input.

[LA/LE - UI & versions tests]



1. That's true I've moments of confusion whenever the lot H and W are switched probably because the one working on it may be also confused or careless .

But, stating out the exact lot size and the road orientation is the way to avoid further confusions. This is not something very hard to realise or learn. If LE switches its displays on the lot sizes just simply because some confused and fooled users, that will lead to further confusions on those users who have been using Lot Expander and have learnt and get used to the real lot specifications.

I'm aware that Maxis has fooled the users in the first place to make them believe such illusion. But then, some of them themselves also got confused. Maybe, those are the temporary workers. That's pretty weird.

Maxis made a fussy confusion on users and now LE which shows the clear picture will follow the inconsistency and confusion Maxis made... simply because some well trained confused people whine, some people wouldn't wanna learn that little bit to avoid a wide-spread confusion. Can at least most of the LE users use LE with a clear picture in the end?

Just imagine such quite probable end-result...

2. LotAdjuster...
So, you're gonna add more features other than expansion and shrinking. Then, it's about moving as the additional feature. If somedays, this can also move houses, that will please many lot-builders, I guess. But, such watr is quite deep.

3.
probably, a preview utility can do it. It will gather the Left and Top values from the lots or a given neighbourhood and then the neighbourood gets mapped out and indicated with the directions like left, top, sunlight direction, etc.



This will confuse those who knows what "left" means while it doesn't matter to those who don't know unless those who know can all assume so.


[Lot -shrinking] - troubleshooting

aelflaed,

I think your research results still worth for further troubleshooting, so I personally think they can be moved to the more relevant threads rather than deleting them alone. But that's just my view, let's see others' view on it.

I just released a new version of the LotExpander, 1.2.8.

Please note that the new release version doesn't contain either the lot shrinking or lot moving code. There were some crashes which needed fixing and I included some of the more stable changes that we've been testing. However, I don't believe that the lot shrinking code is ready for release yet and I haven't received any feedback about the lot moving code yet.

So, just continue to use 1.2.7.8 to test lot shrinking and 1.2.7.11 to test lot moving.

If you are experiencing crashes when manipulating lots that contain objects with very long names, let me know and I will update the latest test version. You will all get the fix with my next test release, in any case.

Good night and happy simming.

I suggest you leave Left and Right relative to lot as looked at from the road (or what used to be the road if it has already been moved once and if you can tell). Left and Right is already used that way for the size adjustment, and I think it would be "A Good Thing" to use the terms consistently within this tool. I know there may be a complication if you have lost the road data at the time of the first move, so it could be a good idea to encourage users to move the lot all the way in the first go, when it is still obvious what the labels mean.

What of lots with two roads? Well only one of the roads was regarded by the game as being the actual road - the road at the front where the mailbox was placed when the lot was first laid. The player needs to (and usually does) keep a mental image of how the lot was placed initially, and will not find it as hard to label the sides of the lot front,back,left,right based on that history than they will to track the edges being relabelled as they move and size it, especially if they don't quite understand the decision tree you are using to do the relabelling. Obviously when the lot has actually been snapped to a new road by one of its other edges (is this even possible?) then it would be correct to relabel the front edge and the other edges relative to that.

One thing I know is it's unreasonable to ask people to remember is which way up the hood was when they first entered it the first time. No point in asking anyone to evaluate labels based on U values or lot orientation. IMHO needs to be road-edge related. People whose lots *genuinely* have two roads may have to accept the road picked to label front will be arbitrary.

Of course, if you want to be *really* busy, you could offer an alternative set of coordinates based on the hood coordinates, which could either be toggled between or were displayed at the same time in seperate boxes. People who wish to use this would presumably have taken steps to understand their own hood orientation. In my case I place a nhood ploppable at the top edge as soon as it loads.


I design the user interface for the PJSE plugins (and drealmBBS before that). Pete and I make a good team - I design and spec, he codes and builds My personal guideline is to label as informatively as possible without it getting so cluttered that the eye cannot pick out the important information easily. That's why I say stuff like write "Width" and "Depth" rather than hoping it's implied by what order you put the values in. And if there was a sensible amount of room I would even also put "as viewed from road" on the screen. It's all less to explain and support in the future.

Does this mean it keeps the road flat too?



Inge, don't they need a taxi to go anywhere? Even if you click on the next lot and tell them to go there, the taxi still comes to take them next door.

Do I need to get buyable portals to reproduce your Ped-only effect? If I leave the portals on the lot, can I delete them when I want to? Guess I'll find out...

All the Maxis templates are listed as 'road x depth', but when the lot is a saved one, that appears to become random. Grrr. Oh, I've just spotted another post I overlooked before - . I'll have a look.

You could base it on the mailbox, which only applies to one of those roads.


Instead of plus/minus values, try left/right values, from the road view, as is already done? Can you grab an image of the lot and show it at the right moment? (No idea how hard that would be, forgive me if it's a ridiculous idea). Oh, I see Niol has suggested this too.


So this function allows you to build both above the road and on the far side of it? I didn't realise that. Medieval overhangs would be better that way too. Shame we can't share lots built with this option.

Speaking of which, I assume we're not supposed to share shrunken lots in general as yet, apart from those Plasticbox has in testing? I like to share.

Off to look things up in SimPE...

Not with Bon Voyage, they can walk to anywhere!

But of course I could have made something like a small gravel driveway at one end of the park, and placed the car portals there, if I did not have BV. But I didn't have a public telephone either, because I was keen to make the lot look like something small and local just at the back of some houses. Because I had BV I was able to do without the transport-related clutter.

Ah. I wondered about that - maybe one day I WILL get it then.

Having tried it out, just in case it worked, I now have a park with a space warp attached - the neighbours come and go freely, but my poor sim is forever in taxi-land. Until I restart, of course, and I suppose meddling with the values in SimPE will retrieve the portals.

Running commentary:

I suspect lots with 02,01 or 08,03 read the road value first. Lots with values 04,02 or 01,00 probably read the depth first, then the road edge.

My testing was a bit minimal, since I did it backwards and chose lots in SimPE to record first, then went looking for them in-game to check the size notation. This meant I had a few that were only 1x1 lots, so not much help. However, I had one of each U-value, and two valid ones for 02,01.

Is this enough for now?

I have also messed with a few lots, using 127.11. Most have been altered in one pass, expanding/shrinking and moving.

-Two residential lots, although I haven't yet worked out why you would build a stranded house...actually I have just thought, it would enable you to have terrain roads, with the portals arranged on a dirt (or whatever) road without modding the entire neighbourhood road system. Alleyways etc.
-Four community lots, all different orientations.
-One of my distorted-road lots from earlier. This one I aligned to the road and changed nothing else, just in case it flattened the road for me. Nope.

I haven't played anything much yet, or even re-entered all the lots, but I thought I'd post some preliminaries.

-Once moved, the road tiles are not visible in the hood view, although they remain inside the lot until deleted. Those at the very edge require MovObj cheat to remove.

The expanded section of the lot does not have road tiles on it, although it is in line with the old road.

-The lots will snap to a hood road if placed in a suitable position. Haven't actually done it yet, so I don't know what happens to the lot then. This may only apply to lots where the portal defaults were turned off.

-One res. lot has a house in the middle, after deleting the road tiles. In the hood view, the green border shows the correct outline of the lot with its expansion, but not the strip where the old road used to be. Cutting the house in half, incidentally. See photo. This photo also shows other moved lots, but not very informatively.

- the park lot will allow other lots to place beside it on the right and back edges (based on the old road), but NOT along the front edge, where the lot itself originally was. (This lot is ParkEast, 04,02, Above.) The residential lot (MoveEast, 04,02, Above) will allow other lots beside it on left, back and front edges. The right edge is blocked by a neighbourhood road, so can't tell.

Better go get those portals back. I'll post more later. Or tomorrow, depending.

Don't you have my buyable portals? You'll need the community phone too, and I think there is already one in the Maxis catalogue.



It needs to be born in mind that the lot shadow/outline does not show the area that would have been road (still has the road tiles showing once you enter the lot). So you need to use a one-tile shallower lot in the space in front than it actually looks like.

Results of tests so far: All 4 U values in all 4 orientations, moved back 3 and right 3. As there are a load of pictures I have zipped and attached them. Please read description.txt that explains what they show - which is an interesting and unexpected anomaly but probably one which will have a eureka moment.

Must find buyable portals...tried several other methods, still no portals. Are they here, or elsewhere, Inge? Thanks.
I eventually realised about the ex-road space remaining invisible and unusable in the neighbourhood view.

I've now done a fair bit more with all those lots.
The moving process altered none of the orientation or U-values in SimPE. I have not seen any lot moving to the wrong place.

I altered the Sumatra lot to U10=0, to see what happened. The road was unlocked, the portals fine. I was able to drag floor tiles across most of the roadway, which nicely flattened the distortion except for the edges. However, since then the lot will not move anywhere else in the neighbourhood. I haven't tried cataloguing it. It will probably crash.

Allowing the moved lots to snap onto a road again (which they do happily in the right spots) puts the road back nicely, but does nothing for any missing portals. Altering the first axis value in SimPE didn't make them appear either.

Move East (res.)Photo below shows what happened when I snapped this lot back onto the road. Everything is as it was, just with road all along the edge. So the house is on the footpath. Visitors can be seen detouring around the building - they actually walk all the way across the road to the other footpath, then back again to reach the exit portal. Of course, this is another way to get normally unbuildable tiles into your house.

Park North - 02,01, Left.
Shrunk Right -1, Moved back 1, defaults off.
Wondering how this would work, done all in one process. The three portals were missing from the side that was shrunk. No phone or bin at all. Presumably this lot would have been okay if the default portal option had been ticked. Photo below.
Try - expand with default on, and see if the portals come back.

Park South - 08,03, Right.
Move back 1. Defaults?
Initially, a 1x2 lot would place beside this one along the front, but not on the sides or back. A 1x1 lot placed at the corners, but not along the front or edges. After play, the 1x1 would place anywhere along the edges except at the front - see Inge's post about the invisible road space remaining here. (It would be nice to have the view of that strip fixed, so you can see where the lot really is.)

Made a curved gravel drive for the car portals. Deleted the service portals. Moved the ped portals to more interesting places. Lot works well, although the curve of gravel needs to be flatter to allow for the straight-line car direction.

Park West - 01,00 Below
Shrink front -1.
This works fine, now need to move the lot and test again.

I'll have a look at Inge's pictures before bed, then that's it for me tonight. 'Night all.

In the flamingo thread http://forums.modthesims2.com/showthread.php?t=251392

I have not yet implemented the logic for keeping the road flat when expanding or shrinking at the front of the lot. First, I want to do some research into how the game uses the Top, Left, Z (height of terrain), Orientation, U11 (lot rotation), and U10 (road) values in combination, so that I can make some reasonable choices for the Z-value of the road. Once we have a flat road, it should be relatively simple to set the correct Z value for the portals, to resolve problems with flying portals. (Although the portal logic is painfully convoluted and poorly documented, so it can be difficult to judge the difficulty of changes).

The front of the road is determined by the U11 (lot rotation) value. The number and location of the roads is determined by the U10 value. I really don't think that it's a good idea to confuse those two, no matter where the user decides to place the mailbox.

I'm afraid that I really don't like this idea. What does it mean to move the lot 3 to the left and 5 to the right? Since there can only be movement in one of those two directions, I would really prefer to maintain one numeric value. Perhaps a "numeric up down" control is the wrong UI? I'm looking at the "track bar" control, which "enables the user to choose from a range of values by sliding a small bar inside another bar" (picture available on request). This seems like a move intuitive interface to me for the "movement" controls.

I've thought of this, as well (in fact, I think that it's been in my to-do list for a while now). I haven't done any research into the difficulty of implementing this, but I'm afraid that it's a non-trivial change (unlike most of the UI changes that we've been discussing).

I have no problems with people sharing their lots.

However, we know that there are some intermittent unexplained crashes. There are two possible explanations for these crashes: the game is unable to handle what we're trying to do, or there is something in the lot package which is causing the crashes.

If it's the former, then all shrunken lots will have these crashes, unless someone can come up with a hack to change the game behavior. There is no obvious reason to avoid sharing these lots.

If it's the latter, though, then the current shrunken lots have an inherent flaw which will remain with them forever, even if a subsequent version of the Lot... Adjuster... resolves those issues.

Therefore, you should definitely label your lots as test versions which may contain serious problems. I would also appreciate you keeping problems with the lots in their own thread, rather than having people post here.

Please, no! The interface right now (in your latest test release) is very clear and easy to use. You have now added enough information on each screen to make it clear what each action does.

The only thing I would change in the existing interface is not to have the warning popup every time I use the unlock to road tickbox, cos after I had that 16 times in 5 minutes I wanted to put it in the swimming pool and take away the ladder Can you store a "seen it thanks" setting somewhere?

Let me just warn you to back up your system first, in case SecuROM causes you problems. Once it's installed, it's difficult to get rid of. I removed it by restoring from a previous backup of my system and am determined not to reinstall it.

Speaking of which, has anyone else noticed that the new BV patch that Maxis released a couple of days ago is identical to the old patch that Maxis released several weeks ago? Both are version 1.10.0.122 and the binaries are identical.

I agree. I finally got a chance to run the game this morning and found that the game is even more inconsistent than I suspected. My two "1x1" lots (as displayed in the lot catalog) with U11=1 and U11=2 were displayed in the lot view as 20x10 and 10x20 respectively.

Yes, I do not need any further testing on the lot size display within the game. It's become clear that we should not try to emulate Maxis in their very confusing display of the size.

Since I have not changed the U10 (road) value, I believe that all of these moved lots remain viable lots which can be snapped to a road, assuming that the road location has not been built upon.

I wonder whether we would see the previous road space included if U10 were set to 0?

I think that I should consider adding an option to remove the roads.

Are you sure that the neighborhood is entirely flat? If not, placement issues may have nothing to do with the LotAdjuster.