I thought you get in as soon as you have any download featured? This is the first time I have ever seen a download thread featured and the author did not carry the cup also.

I've built a new terrace lot, shrunk only at the sides and basically the same as yesterday's. I'll add it to my existing thread, since no-one told plasticbox that wasn't kosher.

[chit-chat]

Rascal,

proabably, they don' act like that in an uncertain field.. You see what I mean...
coz there's insufficient amount of materials for them to compare in order to erm ya know...


aelflaed,

if SimPE is open and not shut down, and this may interfere with the in-game savings.
So now, I turned it off completely before running the game.


Numenor,

As the Ranchies may mostly know what I had suggested about this. I'm not gonna repeat that. After all, It was well responded. I've no further comment on that thread.

What Inge had said are also what I've observed. We and many others do have observed the behaviours in this aspect despite different degrees of concern.
It's just that we didn't normally talk about this when there's not a strong case (a stigma?) that initiates it. The Moo Moo awards is for the overall archival (though not always but at least mostly) while the Featured is counted per an "exceptional" download. The "rules" were well stated. This I'm glad to receive one offering from the site even though I'll carry on my alternative choices.

As I have said before somewhere in this site, I think people will know where to find their likes as long as they're accessible. A featured brand isn't important at all but means more advertising for the downloads. Sooner or later, people will still mostly likely get to their likes anyway.

But it's true the Featured brand now is the obvious way to reach the Ranchies subforum for a more socialisable subforum for discussions and OTs.

This looks wonderful. I think that you've really done an excellent job with this. Initial comments:

Instead of calling it "Inge's Flamingo", I'd call it the "Portal Revealer". The function is the important thing, not what it looks like. You might want to mention the appearance once.

I really like the new pictures. Funny how a good picture can tell so much.

I found the sun directions a bit confusing. You use four words (rear, bottom, front, top), but I think that you're only describing two locations. I would try to be consistent and only use two of those - "front" and "rear" are probably more descriptive to the average simmer, since they refer to locations on the lot. "Top" and "bottom" seem more appropriate if you are describing locations on a piece of paper, or on the computer monitor.

Oops, you've told people that lot shrinking is available in 1.2.8 of the LotExpander, but it isn't. I haven't released that feature yet. Until we can figure out this crashing problem, I don't intend to release it - although I could be convinced otherwise. Perhaps you should point people at the first post on the research thread for now - I intend to keep that updated with the latest test version of the shrinking code, for now.

Once I release the shrinking feature, you can update your tutorial.

All in all, I really thought that this was concise and easy-to-follow, while maintaining the technical details for people who need them.

And, since I don't think that I'll be implementing rotation of lots anytime soon, I shouldn't even supercede all of the work that you've done.

I agree, this seems like an ideal way to share your tutorial. It becomes very easy for people to ask questions and give feedback. It should be easier for you to make changes on-the-run. As well, you get credit with mts2 for all of the work that you've done.

...or who made it

Is it possible that your lot is underground? You might want to start keeping track of the Z values.

Cool!

Not silly. Thanks for bringing this to my attention. This is exactly the type of thing where I may be able to help. I went over to the MATY thread and made a couple of suggestions.

Good thing that you checked this. I'd completely forgotten about this issue. The portal functionality (ie, how they work) and the portal display (ie, where you see them on the lot) are controlled independently. I finally had to modify the LE to change both the XOBJ and OBJT records for each portal.

Unfortunately, the explanation of how to change the OBJT record is difficult, because the X and Y values are not in a fixed location. The OBJT is a pretty complex record structure. For now, the easiest thing might be to have people buy new portals if their old ones disappear.

[Update:]

I've been thinking that there may be some value in having the LE try to move all off-lot objects onto the lot (advanced feature?). Finding lost portals and more robust shrinking of lots are two places where this might come in handy.

Unfortunately, this could be a substantial amount of work - mainly because the record is pretty complex and isn't well documented and I haven't done any cleanup on the existing code.

Still, if people believe that it's worth the coding and testing effort, I'm open to trying to do this.

If I could be sure that the crashes were caused by off-the-lot objects, I'd consider this a very high priority. But, perhaps I've been looking at things the wrong way around? Maybe writing this code would fix the crashes... then we'd know what was causing the crashes in the first place.

It would certainly be nice to have access to a better server. I would also love to use my journal for some notes on the LE development. But, I'm resigned to the fact that this may not happen.

If you're right about this, it's probably because the Andi got the cup for the LE.

Let's face it, I'm not doing this work for the recognition. I'm doing this because it's a cool tool which I may be able to make even better - and that's something that I personally want.

Coming out of hiding here for a moment:
I have a 1x1, 1x2, 2x1, and 2x2 collection of lots, all of which have been shrunken using the Lot Expander. None are crashing for me, but then I've not had crashes on Plasticbox's lots either. Would it be ok if I submit them with (of course) the dire warnings? They come in a variety of styles and shrinking methods, which is why I think they may be good for testing...plus I have all EPs.

1x1 - No walls on lot edges. Rather, the right, left, and rear walls are one space from the edge. Right, left, and rear were shrunk.
1x2 No walls on lot edges. Right and left walls are one space from the edge. Rear bonus room is a good 6 spaces from the edge. Right and left sides were shrunk and I believe the rear was as well...I'll double check my notes at home.
2x1 Right and left walls are on the edge. Rear wall is one space from the edge. Right, left, and rear were shrunk.
2x2 Right and left walls are on the edge. Rear wall is a good 6 spaces from the edge. Right and left sides were shrunk, rear was not shrunk.

None come furnished or with landscaping/lighting. I can add lighting, though, if ya'll think that might be best. All Maxis content (which is highly irregular for me and basically the only reason I can share, but I thought it best while this was still experimental).

A few pics (just details of the Xx1, I didn't take pics of the other two yesterday):

Mootilda,

lool, I do check the h, w, l, t, z, u10, u11, and a few other values
gonna take a nap

My lots are shrunk at the sides only. (The screenshots in the tutorial, btw, are screens I made while building the actual upload -- Backdoor Lane 42, one of the crashing lots. Just in case other questions like this one come up while I'm offline: a close look at the tutorial/upload screens may answer them -- it's that exact same lot, not a copy)




I'm not sure I can follow you =) by "off-the-lot objects" you mean the portals which may not be moved correctly, yes?

This may be worth noting: one of my crashing lots -- the first one, Row House 01 -- was shrunk with the LE 1.2.7.7 (which didn't move portals by itself) so I put in 3 of the portals manually. Just in case this plays a role.

Other than that, I am sure I did not leave any objects in the to-be-deleted area when exiting the lots. However, I can't say for sure that I never *put* anything there (and removed it again) during building .. just in case some objects leave footprints or something.

No, I mean objects in general which have their coordinates off of the lot.

This is not my area of expertise, but I seem to remember a post that niol made which said that there are sometimes hidden objects on lots.

When I wrote the shrinking code, I assumed that people could actually see and remove all of the objects on the land to be deleted. If it's true that the game creates hidden objects which may be on otherwise vacant land, then the land to be deleted could look vacant without being vacant.

I assume that some more experienced modders would be able to verify whether this is true. In the interim, let me see whether I can find that post.

Also I never put any family into my lot before shrinking or publishing it, because simmies can leave invisible debris lying about. Dunno if PB and Aelflaed did.

As long as you warn people about the possible lot corruption, I have no problems with your sharing these lots - they look very nice. With any luck, the fact that they were made with Bon Voyage mean that no one will experience any crashes.

I hope that you won't mind keeping track of any issues that arise. Rather than having people post their issues here, perhaps they could post them on your upload thread and you could pass on anything that seems really relevant to the LotExpander?

If you send me a link to your upload thread, I'll put the link into the original post on this research thread. I've been trying to visit everyone's upload threads once a day to see whether there's any information which might help us to find these shrinking issues, or to see whether I can be helpful with any other issues.

When writing the lot shrinking code, I thought that it would be safest not to try to delete any objects on the disappearing land, but to just leave them alone.

The LotExpander attempts to keep all objects in their original location on an expanded or shrunken lot. In order to do this, it sometimes has to move objects to keep up with the movement of the land itself. When shrinking a lot, this logic will move objects on the disappearing land off of the lot (to their original location with respect to the rest of the lot). This is why I warned people to make sure that the disappearing land is empty.

Would you know what happens if an invisible object is off of the lot area? Could this be causing the crashes that we're seeing?

Do you have any additional information about this invisible debris that might be relevant to the LE? For example, do you know where it might be stored in the lot file? If we could find and either move or delete these objects using SimPE, we might be able to determine whether that's what causing the crashes.

This is also what I was hoping might be accomplished by having the LE print out a log file. The lot file might show us what objects the LE believes are on or off of the lot.

Kaboom! Another idea down! (No, I did not.)

I think the most straightforward way, right now, to sort out whether the EPs used make a difference, is if a BV user would download aelflaed's or my lot, change it very slightly in Build Mode, and reupload. And then see if that lot still crashes. (Someone has said this before, I know, I'm just not sure whether it was on this thread)


Mootilda,

KariMinger == Zazazu on MATY; I believe you already linked to her thread.

I just updated my Backdoor Lane post with links to all other shrunk lots that I know about. Did I forget anyone? Here's the list:

aelflaed @ mts2 (base game compatible) -- 7PM crash reported
Inge Jones @ simlogical (BV required) -- no crashes reported so far
Zazazu (=KariMinger) @ MATY (all EPs required) -- no crashes reported so far
DocDoofus @ MATY (BV and probably other EPs required) -- no crashes reported so far

(Mootilda, I believe Inge's lot is not linked in the OP here)


OT: Mootilda, since you say above "It would certainly be nice to have access to a better server" -- I've never seen a big difference in site performance whether I was logged in or not (= whether I was on the special server or the one for everyone), if it's any consolation =). Only when downloading stuff it makes a real difference.

Well in my experience, BHAV code does not make the application crash, usually just throws up errors. Usually crashes are sound or graphic elements missing or not properly linked. If there was an object holding the sky effect for nighttime, and that was missing when it got dark at 7pm, in theory that would be the sort of thing I would be thinking of.

What I do know about the lot contents, is that all the "global sim objects" things like careers, foods etc are all actually on the lot when it is created. What I don't know is whether they are considered to be on a tile, which in turn might get deleted. If so, and if after that first crash the lot plays fine from that time on, it seems like whatever it was gets spawned again. Perhaps the lot creators could play their own lots till they crash, and go back in and play for one successful day before evicting the sims, refurnishing, and sharing them.

I just went to check if my links are correct -- I think we should be aware that current test results and overall impressions might be skewed due to very different sample sizes:

* Inge's lot has been downloaded 9 times
* Zazazu's lots have been downloaded 4 times each
* aelflaed's, 179 times (both versions together)
* mine, 780 times (all together; not counting previous d/ls on this thread)


In other news, Simsample just posted on the other channel (MATY thread):



Doesn't prove anything, of course. Simsample obviously has BV (he was the one who most consistently crashed so far, I think).

Mootilda: you said the LE isn't deleting objects on the lot on its own but the game does that -> this *could* mean that different versions of the game go about it in different ways, do I understand this right? So that if there's some invisible crap left on the lot, and BV is able to clean it up but Base/NL isn't, the crap in conjunction with a CAS sim blows up at 7PM. And it's somehow disabled/removed when the lot has been autosaved and is replayed.

Something about lot borders *must* be different with BV. It is absolutely impossible to place lots with underwater borders *directly* next to each other (border to border) in pre-BV games, but with BV beach lots this works. (From screenshots I've seen)

How is a CAS sim different from townies/in-game sims? Memories? Inventories? Family ties? They haven't slept on the lot yet? I can't think of anything remotely useful .. I don't know how to make a connection between a completely unplayed lot, and a crash depending on what kind of sim moves into it. (Saying this because, apparently, the lots only ever crash with a newly moved-in CAS sim.)


Just read what Inge wrote (we almost cross-posted): the "global sim objects" thing might be the missing link to deleted/invisible/improperly deleted stuff on the lot, and what sims are on it .. there could be something that CAS sims have that other sims don't, or the other way around.

Yes, I had the exact same idea about how to safely share lots =). That or hire a BV user to fix them =). Or simlpy, install BV. (I'm a bit curious whether or not Seasons would work?)

Still, it's a bit unsatisfying that way .. feels a bit too much like voodoo to me, if you know what I mean? Perform arcane rituals so that your lots won't crash, without actually having understood what happens.


ETA, simsample also says "I save the game, it doesn't crash (..) I can consistently reproduce a 7PM crash in the Pbox lots (..) but only with CAS sims and unsaved lots." (Maybe the saving clears up whatever mess Base/NL leave behind?)

I did move somone into the Modern Terrace briefly, which is why I knew they wouldn't use the side gate. The Blue Terrace is unplayed.




Great minds think alike! This is also one of the suggestions my husband has offered. However, since I can't seem to make them crash, we'd need a helpful 'pre-crasher' to call on.

The other suggestion he made last night was that it could be something called a race condition. You all know about that? My system is probably low-end compared to some of yours, which could affect the likelihood of the crash.

I'm happy to post the specs for my system, but I'm clueless as to how to find them out. I tried a couple of options, but I always end up having to ask hubby for help.

plasticbox, I have Seasons, but now I'm confused about what you are wondering - tell me if you would like somethig tried. The small amount of play I did in Seasons with your lots did not produce a crash.

Niol, I'm not sure what you're responding to? I turn off everything before running the game, you have to with the BGS, or at least you used to - I suspect the need was fixed with the recent update.

Mootilda, thanks for your comments on the tutorial. I'll tidy up those few things and put it up for general use. Somewhere. The building thread is not working just now - won't manage attachments - so I'll try again in a while.

No, that's not quite what I said. The LE does not delete objects, but just keeps them at the same relative location on the lot. This means that objects which are on land to be deleted will end up off of the lot when a lot is decreased in size.

I have no reason to believe that the game is deleting objects whose coordinates are off of the lot. I honestly don't know what the game does with this type of item. We know that portals which are off of the lot can continue to function well. It's possible that this is true for all objects. However, it's very reasonable that different versions of the game may handle objects which are off of the lot in different ways.

I wonder how difficult it would be to get the LE to print out just the name of each object and it's location? Probably not too bad. Then, someone could go through the objects and decide whether to try moving them back onto the lot, or deleting them. Does that sound reasonable?

Just to reiterate: I have no idea whether such objects exist, or whether they would cause a crash. We could easily be looking at the wrong record - it could be the roof or something else causing the crash. It could be something in the sim information. I really don't know.

[record formats (lots and neighbourhood)]



So, the off-the-lot hidden objects can be stored in yet a virtual space not defined through the lot world database, 3D arrays, 2D arrays but others especially the objT and xobj files probably coz their positions are only relative to the lot axes. That's a pretty free scale for this dimension.


[Lot -shrinking] - trouble-shooting

Lol, how about making the same but unfurnished lots ( no object like column object but not column deck, no windows or doors or garages or driveways, etc )(only walls and fences and halfwalls, roofs, wallpapers, floor tiles, foundations, ...) to separate the groups of possibilities first. probably, also the same lots with only the objects left on the exact ground while no build objects.
If the former crashes as usual, then if the latter also crashes, chances are either set can have their own to reasons to crash or inherit the same problem.
Note, this doesn't exclude the co-effects when neither causes a crash.

Some plain shrunked lots being played past 1900 can be the background controls for the testings..
Sorry, I've to suggest this coz I majored in Biology .

With all these majorly-categorised testings, we should have a good chance to really head to the real direction(s) unless we're dealing with multiple causes among different game versions. [I'll ]

[trimmed...]

Oh, anyway, any comment or suggestion or arguments or constructive criticism?

[moved...]

[Trimmed to save the space after my wondering...]
No, I don't mind , Mootilda, as I said I suck on it but I just wonder about things.


[roads non-stand.]

Added:
1. That attached is a test result for moved lot 20x40, the lot had been moved back by 2 and left by 3. Now, it acts a 20x60
moved1.jpg
2. The 2nd is moved back by -2 and left by 3.
movedlot2-b4.jpg
movedlot3-middle.jpg
3. The 3rd is moved back by -3 and left by -2.
movedlot4-after.jpg
4. The 3rd is moved back by 3 and left by -1
movedlot5-4thbefore.jpg
movedlot6-4thafter.jpg

I've managed to get the attachment to go through - the tutorial is here:
http://www.modthesims2.com/showthread.php?t=255110

Exactly. The game is clearly willing to handle some objects in the virtual space outside of the lot.

The question is: what is the best thing to do with these objects? Leave them alone (off the lot), move them onto the lot, or delete them?

I think that deleting these objects is the most dangerous of the three possibilities, since there is always a chance of missing some reference to the object in the lot file - and we all know how badly the game handles invalid references.

The easiest thing to do is to leave them in the virtual space surrounding the lot, since that logic already exists in the program.

However, if we knew that this was causing crashes, it would certainly be worth investing the time in writing and testing the logic to move these objects back onto the lot. Just be aware that this is not a trivial change.

It makes a lot of sense to try to isolate the problem by having sets of minimal lots to test. Unfortunately, the fact that the crashes are intermittent can make testing much more difficult. And, it can be difficult to play a minimal lot long enough for the crash to occur.

I would go even further with this. Since the walls, floors and roof are stored in different record types, or possibly different instances of the same record type, I would suggest testing with only one of the above per lot. If we could find a play-path which always results in a crash (no matter how complex), then we could try that same play-path with various minimal lots to try to narrow down what causes the crash.

Of course, this only works if the problem occurs with just one type of object. If multiple object types are required to produce the crash, this technique won't help at all.

Unfortunately, the LotExpander has no way to check whether a particular byte in a record is:
- a byte,
- a half of a short (or which half of the short),
- a quarter of an integer (or which quarter of the integer),
- a quarter of a single float (or which quarter of the single),
- an eighth of a double float (or which eighth of the double),
- the length of a string, or a partial length of a string (or which part of the length),
- a character within a string,
- or some other type of data, such as a bitfield.
None of this information is available without a human being making a decision and then writing the code to implement an algorithm to handle it.

Unfortunately, in order to find the X, Y coordinates, the LE needs to be able to "understand" the record structures well enough to parse them - that is, to decide that this byte is a part of a string and that byte is a bitfield. There's no other way to do this, that I know of.

The reason that these coordinates seem to be in different places (apparently random, at first glance) has nothing to do with the type of object in the game. It's based on such things as record types, instances, versions, imbedded counts and lengths, etc. The logic has to be right, or the LE will be trying to move an object by changing the wrong value in the record - which will probably lead to more crashes, not less. Note that the EPs installed only affect the things listed above, such as record versions, they don't directly affect the record structure.

The LotExpander already has logic to move objects based on the amount that the lot is expanded or shrunk on various sides. There are a number of X and Y coordinates which are changed for each object, but I don't know what any of those coordinates mean or how they relate to each other.

Minimally, the LE would have to have logic to:
- determine whether an object is on or off of the lot (or straddling the edge?)
- move some, but not all, objects
- move an object back onto the lot without breaking it
- handle exceptions, such as windows, which may appear to be off of the lot when in fact they are straddling the edge
The LE may even need additional logic to handle some types of objects which straddle the edge, so that bits of the object are deleted and bits are kept.

This becomes much more feasible if we can narrow down the objects which cause problems and only deal with them.

Again, the data is never randomly placed. It is placed based on an algorithm. There is no such thing as a categorisation check for a data type. The LotExpander needs to understand the data within each record well enough to apply an algorithm for finding each X,Y coordinate. If the LE does anything other than this, it is much more likely to break things than to fix them.

This would never work. At the very least, you would have to list every single object in existence, including every piece of custom content ever made, and the locations of each of the X,Y coordinates for each of these objects in each installed EP.

niol, I appreciate your trying to help, but it's pretty clear that you don't really understand C# programming enough to help in that area. I hope that you don't mind that I skip the rest of this.

I'm not sure where you're going with this. Circular swimming pool corners are already buyable. Since there's already a very simple workaround for this problem, I haven't been spending any time on it.

Until the attachment actually shows up, I'll leave the link to your previous version in the original post.

Ok, thread is in the queue at the moment for my set of four: http://www.modthesims2.com/showthread.php?t=255161

I tried to get it up last night, but there was some issue with the upload utility that seems to be ironed out. I also have a set of six with two corner lots (the corner ones have a side and the rear on the edge, none of my earlier set have a rear wall on the edge) done as of last night, but I both need to take photos and wait until this is hashed out. It sounds like just telling people to save first thing will eliminate the 7pm crash, but it would certainly be preferable to have it hashed out first.

Regardless of whether this becomes a freely sharable feature in the future, you still have my thanks. The urban area of my main 'hood is going to look much, much more realistic now thanks to you.