But why doesn't the marker move when you've changed the value in SimPE?

I've got MaryLou's permission to submit my lots, and she's even offered to make thumbnails for me. Shame I can't ask Andi. The credits list on this is going to be enormous.

Because the portal hasn't moved Maybe we still don't know exactly how to move portals in SimPE.

aelflaed, an enormous list?
Andi, Mootilda, Inge, Sorcerer, MaryLou, and ??? ...


Currently, I'm busy on something, but will keep on checking here :D

Plasticbox, Numenor, my husband...there are probably more. I think the most extra people I've ever credited before would be three.

I've started doing a house request, just for a change, but when MaryLou finishes the thumbnails I'll get back to the rotated lots submission. I think I'd better do the complete set, so I've got four more to alter now.

Good night!

Well, it seems I staid too long away from this thread :D
Now I have to read, with more attention, all this discussion.
In the mean time, among I am working also on other things, I made some experiment with the beach lots. What I have got(without read anything about this discussion, so be clement ) at the moment is a strange "thin" lot (look at the screen ).
All the portals seem to work fine, and the sims can also swim, you can build and save without crash, you can move/rotate it on the neighborhood and can put it in/out of the catalog.
Now I'm reading all this long discussion.......

This is definitely still on my "to do" list. I don't like requiring people to move their directories around.

However, plasticbox is using 1.2.4 without any problems, so I'm wondering whether there might be something odd about your installation. I don't suppose that you have 1.2.4 available to try? If I remember correctly, you said that 1.2.1 works and 1.2.5 doesn't work. If you'd like to try a newer version than 1.2.1, I could attach 1.2.4 for you.

Until I get the BGS installed on my machine, there's really no way to tell what the problems are. Our attempts at "remote" debugging didn't seem to be working very well.

The new Portal logic in the LotExpander is going well, thanks to everyone here. When I finish that, I think that I'll install the BGS and look at your problem.

I had no problems seeing the portals which were negative, they just showed up in the neighbor's lot. I was also able to move the negative portals onto my lot without any problems (although I think that I needed moveobjects on).

Have you got the lot view distance for your neighbors set high enough?

I know that the LotExpander has some problems, but have you tried using the LotExpander on the rotated 1x1 to create some of the other sizes?

I'm so glad that we can have smaller beach lots... I just can't believe that Maxis only supplied these huge ones. Have you tried decreasing the depth of the lot (from the road to the water)? Or, does it look like the minimum depth for a beach lot is 6 (including the road and the beach and water)?

Lol - leave them there. It means we can have more warning of visitors approaching

In the base game and UNI, certain portals won't appear due to lack of neighourhood view support..

But I think you would still see the Sim approaching, as they would be technically on the current lot. You could always see the roads.

I decided to keep all of the portals on the lot. People with very small lots can move them off of the lot, if that makes sense.

I think that I've finally noticed the same issues with the portals that aelflaed was seeing. I just expanded 165 Sim Lane. When I used the flamingo to check the lot, I noticed that the vehicle portals were correct, but the pedestrian portals were in the original location (ie, at the edges of the old sidewalk). Then, I used SimPE to check the pedestrian portal coordinates and the coordinates were correct for the new lot size and location. It looks like the game hasn't actually moved the portal markers to the new locations, although the portals themselves may have moved.

I'm going to test this now to see where the pedestrians arrive and depart from the lot. So far, I do not consider this to be a problem, just an observation.

[Update:]
As I suspected, pedestrians come in at the edges of the new sidewalk (ie, where the portal X and Y coordinates indicate, rather than on the edges of the old sidewalk (ie, where the revealed portal boxes display).

I don't really consider this to be an issue, so long as the portals function correctly. It would appear that the game is able to compensate somewhat for the difference between the portal location and the portal display. I'm wondering whether there are two X and Y coordinates... the one that the LotExpander has been modifying and the one that's displayed by the flamingo.

I don't see how this is possible in the way you describe it. The blocks you see are not simply markers, they *are* the portal in a different graphical form. No different really than when you have a sim meal where the plate appears full to start with and then begins to look half full, and then empty.

The only thing I can think of is that the graphical representation of the lot as it was last played is stored somewhere, so the game shows you some objects where they were, not where you moved them to using another tool in between times.

Yes, it seems very odd. However, I can't say that I really care, so long as everything works. I may look into this later, but for now, I'm happy.

Could be. Let me see whether making another change to the lot changes the display of the portals...

[Update:]
Using the build tools didn't change the display of the portals. So, I changed the display location for the portals (using the flamingo) and then checked them in SimPE - no change in the X and Y values.

[Another Update:]
I did one more test. This time, after running the LotExpander and checking the portal coordinates using SimPE, I started the second phase of the lot expansion by removing the excess road and sidewalk tiles. I thought that perhaps the display of the portals was somehow locked to the old road and that deleting the old road before moving the lot in the neighborhood might allow the display to reset.

However, it made no difference. The portals still display in the old location, but function as if they were in the new location.

Ok well here are the patches to make the portals buyable. They won't be visible other than as green arrows unless you change them with the flamingo. I did try making them visible as you buy them, but then found they were visible by edfault on all new lots. Not what most people will want

How about just routinely forcing the portals to move inside the new boundary of a lot (basically, for all values of all portals are autonomously altered within 10 or within the new boundary values) when the lot expander detects the portals' location while users have clicked the fix button or checked the fix option before test. It can be a portal test and fix. The fix may be yet another option rather than an autonomous follow-up?

This way, it's easy to get all the portals to show up even in the base game or UNI with Inge's portal revealer.

For fine tuning, use Inge's portal revealer along with pix of Maxis standard placement for portals based on aelflaed's research. So, there'll be a few standard instructional pix to show the standard portal locations within the grid lines. Then, users can already follow graphically easily.

Surely, users can be reminded or told they can still customise the portal locations within a lot.

Just finish a part of a project. So, I'm trying to get 10x20 lots in all 4 directions. They were made in the Pleasantview, but I'll record down the Z values for the 3rd neighbourhood plains as well just for comparison.

A neighbourhood terrain is about 125x125
Top starts the value counting from the default bottom (mostly the sea) of the N001 Pleasantview. Left starts value counting from the default right. Interestingly, the counts seem to be the differences between the boundary and a lot centre, but since I'm using 30x30 lot for the present calculation. I guess a 50x50 or larger lots can do more accurate results.

The 4 new lots on the make were made on the plain terrain as depicted in the attached pic.
The attached rtf file has some value records for these lots.

Wow, Inge, thanks for the buyable version, now more niferious experiment to go... :D

from post 230 this thread

I guess Andi meant there're normally 8 objects in a template or unbuilt "empty" lot; 1 trash can, 1 mailbox, 2 pedestrian portals, 1 car start portal, 1 car stop portal, 1car service start portal, 1 car service stop portal.
Normally, the portals occupy from the 3rd instance to the 8th instance.

However, I guess the numeric order is only significant for locally linking to other relevant infos for the same objects in a particular lot package file.

-----------------------------------------------

All,
1.
in 30x30 lot template, the wallgraph has values of 32 instead of 31... See the attached pic.

2.
The attached file is a rtf file about LotTemplate30x30 - T 0xEC44BDDC - I 0x0000C284 - 0x02010704
I'm trying to understand what it means due to my curiosity and the seeming pattern I think I've recognised. just throw in doubt when any... we shall see more...

3.
forgot to reply that the first 10x20 lot I made has its arrays all trimmed autonomously after the fix. So, no manual trimming is necessary.

I don't have it, but I'm happy to try for you.



Well, I don't understand much of all this, but I am sure I restarted the lot at least once, and quite likely the whole game, while observing that lot where the pedestrians entered ten squares from the marker.

Having modded ten more fresh lots this afternoon, it remains true that some of the markers are off in the distance, some vanish (only one today, and it was a negative value again) and others appear piled in the corner. Some negative markers didn't vanish, possibly because I altered them before opening the game. (Mind you, I believe I had altered the one that vanished, too). Most the the negatives that were altered before running the game appeared in the corner - except for the one that disappeared completely.

My current recommendation is that, in recording the original values, any negative ones should be instantly altered to positive numbers, before attempting to use the flamingo. I think that makes them appear in the corner, where you can at least retrieve them. The markers out in the distance will snap onto the lot when picked up.

Using the flamingo is considerably reducing the fiddling required in SimPE, but by no means completely removing it so far. But it's still great - I'm much less likely to put the flamingo in the wrong place than the maths.

Inge, all the original vertical mini lots have some of the portals out in the neighbourhood, and I've used them in basegame for ages without ever seeing the neighbours coming. It's one of the few disadvantages of the mini lots - less chance to catch walkbys.

By the way, just one of today's lots had the portals in instances 3 - 8. Just for a change. So it's worth checking that each time.

Mootilda, I'll be able to post the values for the longer lots soon - have to do a translation first for MaryLou.

Thanks all. Again.

Don't forget that just because a portal is in a certain place, doesn't mean sims have to exactly animate on that particular spot. For example, the line for making the visitor appear goes like this:

[prim 0x0010] Find Location For (Stack Object ID 0x0000,
relative to My 0x000B (object id),
facing,
normal,
prefer empty: True,
user editable: False,
on level ground: False,
with empty border: False,
begin in front of refobj: False,
with line of sight to center: False)

Which means if for some reason it is not a suitable spot, the visitor can be materialised anywhere along a vector.

Lol, I've been using Andi's 10x20 lots for several lots for a long while, walk-bys can pass by fast esp. the pass-bys are jogging... They just run by and leave in a few seconds. And surely in my cases, I caught them still.by pausing the game and click on them .
Generally, I have no such problem. All the things I needed can show up, but I don't normally use service or emergency when I used those lots, so those I can't tell.

You know, that actually only occurred to me this afternoon, when I had nearly finished.

Maybe I'll try the missing lots that way - I don't have a copy of the 1x6 size.

Once I have this project out of the way, I intend to get the newest BGS and try that, too.

aelflaed.

The 1x6 size is the 1x5 ( you have to add the block of the road) that you have already made

The sizes for the mini lots are
1x1 -> 1x2
1x2 -> 1x3
1x3 -> 1x4
1x4 -> 1x5
1x5 -> 1x6

2x1 -> 2x2
3x1 -> 3x2
4x1 -> 4x2
5x1 -> 5x2
6x1 -> 6x2

Here is a version of the LotExpander with the changes noted below.

WARNING to everyone:

This is a TEST version of the LotExpander (1.2.6.3). 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

Changes from Version 1.2.6.2:

1) Fix problems with the portals.

Here is the new Portal logic:
The LotExpander expects the following set of portals:
2 Pedestrian
1 Car Start
1 Car Stop
1 Car Service Start
1 Car Service Stop

If there are more than the expected number of portals of a particular type, then the LotExpander falls back to the old logic, which attempts (sometimes unsuccessfully) to move a portal based on it's previous location.

However, if there are the expected number of portals of this type, then the LotExpander moves the portal(s) to their "correct" location on the lot.

I am considering changing the logic for an unexpected number of portals so that the LotExpander attempts to determine which ones are in the "standard" locations for their type, and it will move those portals accordingly.

Please let me know whether you have any further problems with the portals, especially when expanding 1 wide lots which have a different rotation (sun direction) from Andi's lots.

2) Partial solution to height of expanded terrain.

Since the neighborhood terrain changes turned out to be more difficult than expected, I made a very small change which may help. As you may know, the LotExpander was selecting a maximum of four terrain values to copy into every point in the expanded terrain. I have changed this to expand the lot out at every edge point, then to fill in the corners. Since we are using a much larger number of values, this should produce a better effect.

I haven't given up on using the neighborhood terrain. This is just an intermediate solution.

It would be nice if people could try expanding lots on hilly terrain or beach properties, to see whether the expanded terrain logic has improved. I'm trying to avoid this kind of failure: https://thumbs2.modthesims2.com/img/...chexpanded1.jpg

Update:
Removed the TEST version. Look for the new Release version, coming soon.

Anything that can help us to narrow down the problem is worth doing, as long as it's not too much trouble for you.

WARNING to everyone:

This is an older version of the LotExpander, for testing purposes only.

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