That would be cool if you find a fix for the portal problems. I had no idea that's no problem with Ofb and up and always built on a 2x1 lot with an aditional empty deco house when the actual community place could fit into ten tiles...

I'll happiely do tests for you if you need one.

Thank you. Even if I manage to fix the problem, I won't want to release the fix without a lot of testing, so I appreciate your offer.

Unfortunately, moving the car start portal off-lot seems to stop the car from arriving on the lot. I rechecked our research to date and found that andi had moved the car stop portal off-lot, so that's my next attempt.

Question for my research: does this occur with all lot rotations (U11), or just some of them?

I have interesting results to report, in connection with hacking lot templates.

I can now confirm that the lot templates are taken from the active expansion`s program directory, at least in the case of M&G, and that they are accessed by file name.

I renamed the community lot templates for the largest and smallest lot sizes to EACH OTHER`S NAME. When I then placed a large lot from the small-lot template, the result was a usable large community lot with the payphone and trash-can where one would expect the properly-centered payphone and trash-can to be if one had placed a SMALL lot there with the right edge of the small lot where the right edge of the large lot is. I.E., the template was copied to the front-right corner of the lot, but the lot was created at the size specified in the UI, not the size specified in the template. I have not tested other orientations to determine if the "right-justification" is consistant, or becomes "left-justified" for some orientations. The point is that it DOES work when the template is too small.

When I placed a SMALL lot from the LARGE template, however, things were somewhat less successfull. Lot creation was successfull, and the telephone and trashcan were offset as expected from right-justifying the oversize template in the undersize lot [i.e., they were at the far left edge of the lot], but the lot was unusable as anything but an empty lot, as ALL the tiles were locked against Build and Buy mode editing. Lot Adjuster should be able to unlock them, but this would require exiting and restarting the game.

Conclusion: It is worth testing a BUILT lot, to see what is copied from the template. It may also be interesting to investigate actual lot template files, to see what they contain. Walls and such might not copy, but I suspect that objects would; I think that copying objects is how the templates work in the first place. Oh, and it is safer to use a too-small template than a too-large template. I expect that both lots would, in play, prove to have issues with portal placement, but I haven`t tested that.

Interesting results.

I'm reasonably sure that the justification is dependent upon the lot's orientation in the neighborhood.

Unfortunately, things are not going well on the portal front.

It's clear that the car stop portal is completely irrelevant to where the car stops on the lot in NL. Instead, the car stops at a specific distance, approximately 10 tiles, from the car start portal. In general, this would not be a problem for lots > 10 tiles, since the car start portal is usually near the right-hand-side of the lot.

However, on a 10-tile lot, this NL behavior is a major problem, since the car will stop off-lot and the sim will not be able to access the car when s/he wants to leave. Moving the car start portal to the right-most tile is insufficient to convince the car to stop on the lot. If I move the car start portal off-lot, by even 1 tile, then the car start portal will not function at all and the car will never arrive on the community lot.

So, I'm stumped. At the moment, my best guess is that we'll have to mod the portal or car to change it's behavior.

I'm going to sleep on this problem and hope for inspiration.

What happens if you put the offending portal on the left side of the lot, pointing into the lot?

Interesting question, especially given that I just tried rotating the car start portal to see what would happen. I'll try your suggestion next. Answer: car still off-lot. It looks like the game just truncates the amount that the car is off-lot, if it's too much.

What's really needed is some way to tell either the car or the portal to cut the distance between them in half on tiny lots.

aelflaed, based on these results, you may as well upload your lots... I think that it will take a while to find a solution.

Well, my suggestion did bring the car closer to the right spot. Not close enough, though.

My modding skills are definitely not up to modifying portals or car code. Right now, I can't even get the right mesh to appear! Perhaps I should leave clothes and objects alone for a while, and build something instead.

How about more small community lots? I bet that there are some interesting lots that can be made with Uni-only and some additional interesting lots that can be made with NL-only.

I think that the problem is that EA never expected us to make 1-wide lots. Lucky for us that they fixed this in OFB.

I suppose you can't really blame them for not expecting us to mod the game in this particular way...which is no excuse for all the things they just got wrong on their own!

I reckon there's an obvious need for some 2x1 NL lots. That will resolve this portal problem (up to a point).

I'm not getting very far with my object modding, that's for sure. I've begged for help now, so perhaps I'll take the rest of the day off and wait for assistance on that. It's frustrating because I can almost see what is wrong, but it's just that little bit beyond me.

I can confirm that this is not related to the orientation of the lot: I made four new ones and shrinked them, but all had this problem.
But then I messed around some more and I came across something I find a good instant solution for now: Placing an object in the cars path "breaks" the normal function and the car will just pop up on the street without driving animation. When leaving however it will ignore the blocking object and drive away normally (if the object isn't right in front of it and there's enough space to play the animation).
Outcome of my research:
- Blocking object has to be at least one tile next to the portal, it doesn't work if they're on the same line.
- If there're at least six free tiles at the enter side the car will be placed there (if there're more the car will be placed where the portal is).
- If there're not six free tiles but at least three free tiles at the leave side the car will be placed there, sims can exit and re-enter the car as usual at that point.
- Same for the opposite direction.

This solution works for shared lots, just placing a subtle object like e.g. a little tin can (or some invisible object) onto the street and the downloaders won't have to move the car manually every time, while those who have Ofb+ and miss the animation can just delete it.

Excellent. This sounds like a much more viable workaround, since it doesn't require any CC (like build / buy enable) and it doesn't adversely affect OFB+ (like moving portals off-lot).

Is there any similar problem with 1-wide residential lots? For example, are the carpools affected by this problem?

An idea: Is it possible to create an object that exhibits this blocking behavior only when NightLife is installed? There are BHAVs that are called when a lot is loaded, and there are BHAV instructions that can test for game versions. Are there any BHAV instructions that can be used to make an object switch from blocking state to nonblocking state, or vice-versa? If so, an invisible object could be made that sets itself to the appropriate mode depending on the presence or absense of the bug. Nyet? Ja?

What an excellent idea. Of course, it would be CC (which I prefer to avoid), but it still sounds like an elegant solution.

In general, I'm tempted to ship my lots as they are, then suggest various workarounds for this NL bug, including only using taxis and placing an object on the road.

Thank you.

Any idea why this thread is showing up in my Downloads by Latest Post page?

This thread was separated out from the LotExpander download thread. I suppose that there's a possibility that some flag was accidentally carried over from the download thread.

Well, it isn`t there any more, but now there`s an empty slot on the first page.

Edit: Well, THAT`s fixed too, now. ????

I tested carpool and schoolbus and they work fine on 1x1 residential. I guess it's the same for the emergency and service cars.

Thanks for testing this. Again, it's nice that the bug is limited in scope... easier to work around.

Hey, good bug-stomping, psychosim!

Mootilda, I would agree that your lots should be left as they are, with notes for NL-only players.

I've been making a couple of NL-only 2x1 lots, and am reminded of why it's so annoying to have no lot between ten tiles and twenty - fifteen would be perfect for so many buildings! However, thank goodness (and Andi and Moo of course) we can have mini sizes at all.

As some of you know, I've found a bug in the LotAdjuster (and LotExpander). It has never handled the VERT record, which can make the game believe that an area is unbuildable, even though there is no valid reason. As far as I can tell, the VERT record can be deleted without any problem, but I'd appreciate some help in testing this. I have a base-game no-cc lot which has shown the invalid "Can't intersect other objects" error, so I've deleted the VERT record to see whether I can find any problems when playing the lot. If anyone would be interested in helping me test, I would really appreciate the help. If you do test, please specify which EPs and SPs you have installed and whether or not you found any odd behavior.

I've downloaded it, but won't have much computer time until the weekend.

I'd like to move all discussion of this issue here, since the problem affects multiple download threads. Discussion to date:
------------------------------------------------------------------------
From http://www.modthesims.info/download...043#post3039043
and http://www.modthesims.info/download...168#post3040168

New version(s) of the LotAdjuster 2.8 and 3.2 now available. Resolves an error, "can't intersect other objects", which could occur even when there is no such object.

This bug has existed in all previous versions of the LotExpander and LotAdjuster. The new version of the LotAdjuster will avoid creating this problem, but will not fix any existing problems created by running previous versions of LE or LA.

If you currently have this problem on your lot, it can be fixed by using SimPE to delete the VERT (vertex layer) record within your lot package. The record will regenerate, but will only contain information for new objects, or existing objects which are subsequently moved.

Because of this, I would recommend that you backup before editing your lot package in SimPE and that you test thoroughly before sharing such a lot.

[Update:]

I have thought of one other way to resolve this problem:

If you remember how you adjusted the lot, you can undo the adjustment (ie, expand where you shrank and vice-versa) using a previous version (such as LA 2.7 or LA 3.1), then redo the adjustment with LA 2.8 or 3.2.

No. There's only one way to find this error: try to build a wall or fence in an area, or to try to place an object, and get the error message "Can't intersect other objects", even though there is no other object in that area.

The problem stems from the LotExpander / LotAdjuster not handling one record within the lot package: the vertex layer (VERT). From my limited experience with this record, I believe that this record acts as a flag to the game; any point specified in the record is seen as unbuildable by the game.

No one has ever reported this error to me before, but people may not have recognized it as having come from the LotExpander / LotAdjuster. A google search revealed only one reported problem which looks like it might have been this one (http://www.modthesims.info/showthread.php?t=362581). My suspicion is that many lots suffer from this problem, but that most people either build very little before using the LotAdjuster (in which case there are no objects on the lot that will cause this problem), or else they build the lot completely and then use the LotAdjuster (in which case, they aren't trying to build in any incorrectly-restricted area).

I don't have a complete list of the objects which exhibit this problem, but I'm guessing that it has to be objects which normally sit on a lot vertex (ie, at the corner of a tile), rather than inside of a tile. My problem occurred with one of the outside lights which sit on top of a fence post; I would guess that all fence post lights can exhibit this problem. However, in automatic testing of all of the shipped lots, I did find a couple of objects which were not directly on the vertex; I have not yet determined which objects they were.

To create a test case, I created a lot with two fences (one front to back and one left to right), then added lights on top of the fence posts. Then, I expanded or shrank the lot in all possible directions. The build error occurs where the fence post used to be on the lot, before the adjustment. For example, if I expand 10 tiles on the left, then the build error (if it exists) will occur 10 tiles to the left of the object.

I'm really sorry about this error. When I took over the LotExpander, I assumed that andi was handling all necessary records, so I never thought to examine this record to determine whether it required changes. Luckily, it seems like a rare problem.
------------------------------------------------------------------------
discussion continued below...

This is the first time that I've seen this problem. Then again, I rarely use vertex-positioned objects such as fence post lights on lots that I am expanding and shrinking.

Logically, approximately half of all previously expanded and shrunk lots will have a corrupted VERT record. The problem will occur if the objects defined in this record are moved during the expand or shrink process. Objects are moved in half of all such adjustments; specifically, when the area "before" the object is added or removed; this is completely dependent upon the internal rotation of the lot (sun direction) and which area of the lot is affected (front, back, left, right).

As far as I can tell, when a VERT record is corrupted two things will occur:

1) Vertices which should not be restricted are restricted. This will result in a "Can't intersect other objects" error when trying to place a wall (including fences) or an inability to place a vertex-positioned object. This is the symptom which will be visible to the user, because of the error message and an inability to do what you want to do.

2) Vertices which should be restricted are not. This will result in being able to place a wall (including fences) in places where you should not be allowed to, because of the presence of a vertex-positioned object. This symptom is less obvious to the user; you would have to be paying close attention to notice. However, this is also the symptom which I've been more concerned about, since (logically) it will allow users to do things that they shouldn't be doing. The question is: Will this cause any major problems in the game?

The workaround that I have suggested is to delete the entire VERT record, which will remove #1 above, but which may cause additional #2 above: vertices which should be restricted will not be restricted.

Here's why I believe that a missing VERT record is not a major issue and will not cause major problems in the game:

A) Half of all existing expanded and shrunk lots will have this problem, yet we haven't seen a lot of problem reports with expanded and shrunken lots. As well, our extensive testing didn't reveal any problems. This seems to imply that it's relatively safe.

B) There are only a few objects which are affected by the VERT record; specifically, objects which are positioned in relation to the vertex, rather than inside of a tile. The vast majority of objects are positioned inside of a tile and are therefore unaffected. I don't have a complete list of vertex-positioned objects, but the only ones that I know of at the time are lights which sit on top of fence posts. Since the number of objects is small, the effect of a corrupted VERT record is minimized.

C) Some of the build restrictions generated by this record are unnecessary. For example, I get the error when trying to extend a fence which has a fence post light at the end. However, I can easily remove the fence post light, extend the fence, and then add the light back. If the build restriction was unnecessary in the first place, then removing the build restriction should be relatively safe.

D) Missing VERT records have only half of the issues associated with corrupt VERT records (ie, #2 above, but not #1 above). Once a VERT record has been corrupted by being unhandled during an adjustment, you can reduce the problems associated with the lot by deleting the VERT record. Therefore, a missing VERT record is at least as safe as a corrupted VERT record.

Because of all this, I don't think that it's necessary for people to fix existing lots, unless they are actually displaying problems.

If a lot is displaying unnecessary build restrictions, and you believe that the VERT record for the lot was corrupted by an adjustment using a previous version of the LotAdjuster, then I would recommend backing up, deleting the VERT record, and testing to ensure that the lot has no obvious problems.

If you really want to be completely safe when sharing a previously expanded or shrunken lot, then delete the VERT record and then pick up and place back down all vertex-positioned objects. This will regenerate the VERT record and add build restrictions for all of these objects.

Mind if I ask how this VERT record issue came to your attention? Just curious.