The game doesn't care if object tiles are off lot for some objects: try the new building mode pine groups. These have an uneven arrangement of tiles and I can place them (with move ojbects on) with all but one tile off lot. Some objects which have only one tile can be straddling the lot border and still be fine. These almost off lot placed items will show up while in the neighboring lot.

I don't think I've ever found an object with animation which can do this--but now I'll start watching closer for one.

You actually see the green tile outlines on the terrain outside the lot? Ok I have to go and try those.

Later: Very intersting, thanks for pointing those out. It looks like I could have misinterpreted what was happening to tiles that get nudged off the lot, because I saw no sign of those stopping at the edge, they just vanished. Or at least their green box did. They're a handy object because their tiles are not in a uniform block so you can see what is happening to individual ones of them.

hmm, maybe there is the green tile evident, I'm not really sure if you can see it, I know the group places outside. I have to go try it too...

No, the green tile is not evident, but I think it's plain that the tiles do not pile up at the edge, like the driveway does.

This has to be the associated animation, eh?

meanwhile, back at beach shrinking:

I have a 2x4, 2x5 and I expect the 2x3 will be fine and dandy too. These place nicely in a new hood. However, there does result a leveling of land fromsidewalk to build line line. See the pics. This levleing resulted with/without build elements. The portals result in a floating position exactly the hieight of the leveling so I'm 80% sure the portals floating is tied to the leveling action, somehow, someway.

The 1xanything lots still results in a blue tear at the water end IF moved to a new hood. Size doesn't matter. 1x1s will never work as they are all water and no sand, will not place anywhere once moved. 1x2s will probably never work as they are some sand and water area only--no build area there, why have it? Where the lots are placed on the new hood, the slope there, the neighboring lots if any doesn't matter, no amount of editing repairs ithat water end blue tear.

I believe(d) the tear is tied to the beach effects portal, but removal of these portals still results in the tear which creats doubt on this idea. I think this because of the strange resulting artifact visible (white are see pic) this white area acts to modify the water linewhere it is, once the lot has been entered/edited. That white area was created by my addition of an effect portal. When a 1xanything is created, it acts to trim off all but one effect portal. EA lots. a 3 x 5, started with 3 portals, one portal governing 10 squares to the RT of the arrow (wave effect portals point out to sea.) I thought "maybe it's the lone portal not working by itself that is causing the tear to develop' so I placed a second, saved, binned moved, placed the lot in the new hood. The white artifact was the only result. Since this effect portal does have effect on terrain off lot, it seems to me that it easily may be the culprit for the terrain shifting which results in the blue tear.

It must be noted that moving the 1xanything in the SAME hood it was made in does NOT result in the blue tear. The little lots seem to be just fine left in their original hoods, no matter where they are placed. I also tried packaging/installing these, since some people believe that the binning of a lot can corrupt it, but the results were the same.

I need to try a creation-moving series on another different terrain than I have been--oh, I have been using two different ones one for the edits and one to test placement. I'll have to hunt up another.....

Delphy thinks that "a hidden private forum would certainly be the best route" for allowing downloads of versions of the LotAdjuster which have dangerous features. So, I'm looking for about 10 people who might be willing to participate in testing of the lot shrinking feature, and any other dangerous testing, such as niol's ideas of creating lots with records that have mismatched sizes.

My suggestion is that you PM me if you'd like to be included in this forum. For obvious reasons, I'd like some assurance that you understand what's required for this testing, and the damage that can be done. I'd also like an assurance that you won't share any LotAdjuster that you download there.

Hope this seems like a reasonable solution for everyone. It avoids me having to code something to try to limit access.

Members:

aelflaed
ebonyspiral - Unfortunately, ebonyspiral is too busy to help at this time.
Inge Jones
ingeli
Mutantbunny
niol
plasticbox
Rascal

Waiting to be added:

baratron
ikbod
KariMinger aka zazazu at MATY
ladykatsim

OK, I'll look into this. Sure would be nice if something fairly simple like this would solve our crashing problems. I've been assuming that all of the lot coordinates had to maintain their relative positions wrt each other.

I'm afraid that I don't understand the term: "nominal coordinates". Can you explain what this means?

I don't really know, but I *have* noticed that some coordinates in Maxis-made lots are negative. At the moment, my understanding of object records is very sketchy.

Andi's code just added a positive X,Y "difference" to every non-negative X,Y value found in the object. I left the code as is, with the one change that the values to be added could now be negative. At the time, I really didn't realize how many invisible objects there are.

I suppose that this is why I'd like to do some more research into what the various coordinates are for. Specifically, I'm wondering whether the game has a check for -1, -1, instead of a check for general negative numbers.

Sorry for the confusion, I was actually referring to this:The whole multi-tile thing is a separate issue... I'm not even sure that an object with multiple coordinates is necessarily a multi-tile object.

No need. The easiest test for your suggested change to the LA will be testing the change once it's in.

Does anyone know what the coordinates for those trees look like?

No wonder that we're all having problems keeping up with this thread. I remember when I first started looking at the LE, I went over all of the messages in Andi's original thread to try to find the really useful posts. At the time, that thread seemed huge. But, I think that it was only 15 pages. This one is over 40!

I'm not going to make any changes to the LE UI... I'm hoping that we can lock down the LA UI instead and I'll release that instead. Sorry about the advanced screen - I probably shouldn't have rushed that into the LE. For now, I wouldn't bother mentioning the advanced screen at all in the rotation tutorial... we know what the default is for 1.2.9... that's probably good enough.

I really need to find the display orientation in the lot package and fix it. It's frustrating that the portals can show one direction and actually use a different one.

I'll look into that. Should be easy to change, especially if I can find the display direction as well (if there *is* a separate display direction).

Can you tell me whether the garbage can needs to be altered, as well. Right now, my sims access the garbage from the sidewalk. Are you finding the direction incorrect on your rotated lot?

I'm currently in the middle of changing the portal logic so that it uses the current OBJT relative movement code, instead of the special absolute movement code that I added. So the work for the rotation tutorial all fits in with what I'm doing anyway. This also allows me to clean up the code a bit, so that Inge's change will be easier, as well.

About the beach lots...

Has anyone tried adding an empty beach lot to their neighborhood and changing the size of the lot in the neighborhood package, before any changes are made to the beach lot? (niol's suggestion)

If we find that this works well for creating shrunken beach lots, I would certainly consider adding this feature to the LA.

If someone would be so kind as to point me to the directions on how to, I'll try changing the hood package to shrink a beach.

I am trying to come up with some template building lots (for a 1x2, 1x3 and maybe longer (see pic) for a flat roofed 'row' building, one that can be used for either housing, like a a NY brownstone, or a downtown business, template lots that can reside in the bin until wanted, that can be whatever size building wants of it.

I think I have the pertinate elements in place, since we can't put them in but we can take them out at the edges. Please someone check me: I have walls, floor tiles and foundation in place for a four level building. (More levels of coruse are possible, but I hate playing a building the camera chokes on, so I see no reason to bother with more.)

I am wondering if I need the external wall paper in place or will this go on the sides holding shift down on a bare wall?

Am I correct in assuming that fencing of any kind will go to the edge on the top of these buildings AFTER the shrink, as it will at ground level?

Sure, that's fine - just mentioning anything that struck me.



I've moved it on that lot, so I can't say for sure, but past experience indicates that sims will use the rubbish bin from whatever direction they can access it. I often have it against the house wall, or even inside the house, and I don't always make sure the arrow points to the access area. It doesn't seem to matter - unless someone thinks differently, in which case I can do some specific checking.

Good - nice when jobs dovetail.

Fencing should be fine. I think the external wallpaper would be fine, but you could put a maxis wallpaper on for safety's sake, then people can SHIFT for themselves.

I should have said: I'm trying to put in the very barest of essentials--if I don't have to add the outer wallpaper I won't, hence as small a file and as little data moving as possible.

I know, but I don't know for sure without going and testing.

niol would probably know the best, but I'd just try opening the neighborhood in SimPE, navigating to the correct Lot Description and changing the Height and Width values.

Here's what I would do:

- save a copy of the original lot
- shrink the lot and test it
- if you find things that are missing, reload the original lot and make the changes, then save a new copy.
- repeat until perfect.

Tried this 14x20 lot... crashed within minutes of trying to play it. I was just adding some terrain paints in game.

[Lots (non-10x)]

Yeah, I just checked it with terrain paints, it doesn't work with the terrain paint. The paint is only recorded by half... gonna have to identify which part is responsible for the terrain paints... I mostly build with walls and floors and ignore the terrain paint. That's my carelessness.

Strangely, it was working with floor tiles on the expanded region... Now I suspect the lot has been altered somehow since imported in to the game.
It doesn't behave the way it used to be when I first made the original copy of it.
The assumption that binning a lot is the same as reimporting a lot fails.

Cool, I may learn more on how these differences are related to how the lot store those infos... :D

1. 2D array instance 0x00005CC0 had switched back to 41 for W instead of 57?
2. lot terrain file has 10 instead of 14 as its W value.
Terrain paint problem fixed, it's those defects that caused the terrain paint painted by half and crashed appearingly.
After comparing the lot template and a built lot out of a copy of it, I realised the game had added an extra 2D array instance 0x00005CC0 there with 41 instead of 57.
Now, I wonder if a larger number in the 10x scheme can work out and avoid these additional elements from using smaller values when the additional files fail to keep up with the specified value from the start... Just prepare for more rather than keeping it to the exact value just like the wall graph files as in any 1x1 lots including Andi's.

Still strange, the additional ground can't be tiled now for that 14x20 lot still with the defects.
But, that may hint out how floor tiles work on the lots... :D

If that doesn't work, a 30x30 lot with 1x1 neighbourhood presentation is yet another fallback for this.

The lot resizing by means of moddng the neighbourhood package can work for those sizes already in-game but not those without in-game default sizes in my tested instances. but, it's good to explore to see if that conclusion works.


[Lot -shrinking]

Mutantbunny,
Mootilda has already told you the way I did.

No, but using the LA shrinking on an freshly placed (and entered and saved) beach lot resulted in a beach lot with the desired shape. However, I didn't try playing it. However I shrunk from the road edge, so I didn't end up with a wave-maker off the grid. That would be a good test of how animated objects respond to not being able to make themselves appear on the screen - or maybe the waves would still appear but off-lot? Must try it.

I have been doing some experiments with off-lot objects in play. I moved a driveway offlot using move_objects, so that it only had one column of tiles on the lot. I then placed a car on it - which meant the car was totally over the edge of the lot.

The sims were able to interact with it to an extent - they went and looked at it (from near the edge of the lot). But when told to go for an outing, they could not cross the border of the lot to get in, and they stood idling unable to cancel the action nor respond to further commands until I deleted the car.

I *could* pick it up, even though it was off lot.

I meant where the file stores the "out of world" object in the same way as a visible object, with numeric coordinates - that evaluate either to within the area of the lot, or as values that could not be within the area of the lot, because they are too low or too high. I still don't know what the lowest number grid coordinate on a lot can be - is it 0,0 or 1,1 or is it relative to the centre of the lot so can be either positive or negative from that point?

An out of world object can be something tangible or even normally buyable, which has been instantiated by an in-game script saying "create object of type (some GUID), place out of world"; or you can get an out of world object by flagging the object as a global object in the first place - a setting in the OBJD. These latter are automatically on every lot in the game - they seem to put themselves there as soon as they are created and added to the downloads folder! There may be other ways of instantiating out of world objects, I can't think of them now.

It occurred to me that the out of world objects if they were stored in file with an apparent grid coordinate, could have a way of telling the game engine to ignore the coordinate due to them being flagged as out of world objects, or the coordinates themselves could be invalid coordinates, which would be the way they told the game they were out of world. If the latter, then normally in-world objects being left with coordinates no longer on the grid, could confuse the game.


It's difficult to write about this without it appearing confusing because the word "object" is used loosely to describe a whole entity such as a sofa or bed, but the granularity of objects is actually per OBJD.

Each tile belonging to a multi-tile item (such as a sofa or large table) is an object in its own right with its own Object Definition and GUID and *relative* location, held in the mult-tile subindex field. (additionally a multi-tile object usually has a master which is considered out-of-world inasmuch as it does not appear as a tile). There is a virtual grid that belongs to an object, with a maximum size of 256x256. An example would be a 6-tile dining table, and the multi-tile subindices for those 6 tiles might be 000,001,002,100,101,102, which would arrange them in a neat rectangle. The master tile for a multi-tile object has a subindex of FFFF As the pine trees have shown us, the indices don't have to form a rectangle or even touch each other. A single-tile object tile always has a subindex of 000 - I am not sure if that is just by custom, is compulsory, or whether the game ignores the value and just regards it as 0,0 anyway.

Anyway, to sum up, the coordinates for objects you see in the Lot file will be per OBJD - ie *one or more* for each piece of furniture, tree, window, door. I am not sure how the master tile/OBJD for a multi-tile item is stored in the file, but maybe those are the ones you are seeing that appear to be at negative coordinates.



ffff
0000
0001
0002
0100
0101
0102
0202
0203

But of course I don't know how they would look in the file - whether the actual lot-based coordinates are stored or whether they are still stored with their internal coordinates. I assume the former - with the internal coords simply used during placement.

First, I wanted to apologize for the very brief testing report last night... it was late and I just wanted to say something before stopping for the night. So, here were my observations from a few minutes of testing:

- After installing the lot, I checked the EP version with SimPE. Since it was just the base game, I tested with the BGS base game.

- I was surprised that there was no picture of the lot, in either the lot bin or the neighborhood view - if I remember correctly, the pictures didn't even regenerate when I saved the file (although I'd want to test that again). Is this something that you did? Or, was the game so confused that it was unable to determine what the lot looked like?

- The lot only displayed as a 10x20 in the lot view. I couldn't see the additional 4 tiles, which I assume were on the left side.

- A wall was buildable at the left edge of the lot, but the right edge and back only allowed walls to be built in the normal way, ie 2 tiles in from the edge.

- Terrain paints either painted very oddly (with stripes and splotches and unable to paint the front 2/3 of the lot), or crashed.

Now, for some wild speculations which require further research:

- Lots built like this will only ever have two edges buildable. Which two edges are buildable will depend upon the U11 value. The 0,0 coordinate remains stationary and all additional tiles are added to the maximum height and width of the lot.

- As building occurs in the game, more and more records in the lot package will be sized based on the lot description in the neighborhood package. While the game may not resize records, any new records will get the default size.

I never use terrain paints. Except that you made this lot a desert in a very odd way. Normally, when a lot is added to a neighborhood, it receives the terrain of the neighborhood if no terrain paints have been used. But, this lot was fixed as desert and I couldn't figure out how to change it in-game. Must admit that I prefer the default behavior and dislike the behavior of lots modded like this one.

I believe that the game changes a lot when it is put into the lot catalog. If I'm remembering correctly, a lot added to the game from the lot catalog will be marked with the latest EP, but will be otherwise unchanged. I think that this is a very annoying feature of the game, since it marks a lot as requiring EPs which it doesn't actually require.

I wonder how this behavior is affected by the EP?

Further test on my non-crashing lot: Placed several of them adjacent, did not enter any of them. Made a family in CAS and put them straight into one of the row houses. Still did not save. Played through a few days straight - went in and out of build mode changing day to night... No crash. Just cannot cause the lot to crash in its present form.

question: you said to try shrinking the lot 'without any changes'. I am assuming that 'changes' excludes the intial entry and save. Is that considered a change or not?

What about the lot file--shouldn't that get edited too?

EDIT: also on the SimPE edit topic: I placed 3 3x5 beach lots. I have looked at one so far (before my question popped up) SimPE reported the version of this beach lot, that came with BV, to be Business. What?

also: what is the 'orientation' data reporting?

also: SimPE reported the width to be 6 and the height to be 3. Obviously this is backwards from the reality lot dimensions. Is this 'normal' for SimPE? Or is it something screwy in my version?

Meanwhile, back at row houses: the answer to my 'will a shift on wallpapering cover the external side of the wall even tho it has no wallpaper on it': Yes, it will.

I have two flat roofed row building templates, a 1x2 and a 1x3, yay. I have wanted these for so long! A real city block at long last. Of course, I am assuming they will be crash proof...lol...

When are we getting the new forum?

So, a nominal coordinate is a coordinate which is relative to the lot, but not within the lot boundary? Or, perhaps a nominal coordinate is just one with a numeric value?

Yes, I believe that out-of-world objects are stored with numeric coordinates which are not within the lot boundary. However, I haven't done enough research into this to be able to tell you whether -1, -1 is the only valid out-of-world coordinate.

I don't know either. As I've tried to explain, I don't know very much about the OBJT record. I know that a maxis-made lot can contain coordinates which are either -1 or 0. I also know that Andi's code leaves coordinates which are zero or negative at the same location, but changes coordinates which are larger than zero (just checked the code to confirm this). I don't know whether a maxis-made lot can contain coordinates which are < -1 or > the lot size.

As a computer programmer, I can guess that -1,-1 is out-of-world and 0,0 is in-the-world. That would be my standard programming practice, but then I'm not a game programmer. My theory isn't supported by Andi's code, which seems to imply that 0 is either out-of-world or special in some other way. At this point I'm just guessing - I really need to do some research.

As well, I posted the table of coordinates that I am using for the portals, if that's any help to you. It certainly seems unlikely that EA would have the coordinate system be relative to the centre of the lot, since the portal coordinates that I'm using wouldn't work with that system.

I'm very discouraged that you're asking me these questions. It seems like a case of the blind (me - no previous modding experience) leading the not-so-blind (you - an experienced modder, although not with lot packages).

This leads me back to my previous plan - I should do some research on the OBJT record format before proceeding. I'd like to understand more about which coordinates are valid out-of-world values. As well, I'd like to understand more about what the multiple sets of coordinates per object mean, since it seems unlikely now that they are multi-tile coordinates. I hate to start changing coordinates when no one here understands what they are. I've seen programmers who do this (just make arbitrary changes without understanding the ramifications), usually with very poor results. I'd much prefer to understand a record before I start making major changes to it.

From the Sims2Wiki, I see that:
OBJD 4F424A44 Object Data
I don't believe that the lot package contains any OBJD records (just searched the code and there's no indication of this record type). Instead, the LA is processing the following record types:
MOBJT 6F626A74 Main Lot Objects
XOBJ 584F424A Object Class Dump
OBJT FA1C39F7 Singular Lot Object
I haven't done any research into how these record types correlate with the OBJD record.

However, if there were a way to flag out-of-world objects so that they understand that they are out-of-world, then this seems like a really good solution to our problem - potentially part of the "correct" solution.

Thanks for the rest of the description of OBJD records and how they work. I'll need to digest this. At this point, I have no idea whether any of this is relevant to the lot package OBJT records or not. However, it can really help to have this kind of description available when I need it.

No. I meant that the neighborhood package should be changed before entering the lot even once.

It seems that a newly placed template creates an empty lot file. I know that the lot file doesn't contain an MOBJT record - the main object record which references every object on the lot.

The theory is that these empty unedited lots are more flexible than an empty edited lot, because they are basically still templates, although with a size and location in the neighborhood. Because of this, shrinking these lots may avoid the problems with ridges and blue gaps.

If this technique works well for beach lots, then I can implement this feature in the LA and everyone can have functional beach lots whatever size they want.

Note that I have no idea whether this will work. I just read what niol said about lots where the LE crashes because the lot package is empty.

This seems very odd. I wonder whether we could actually use these templates with Business, somehow? I suspect that they may allow themselves to be placed, but that the beach and wave portals may require Bon Voyage to function. Another area for research?

I'm afraid that I've lost the context of this question. Have you read my post about the U10 and U11 values? If not, could I suggest that you read it?
http://www.modthesims2.com/showthread.php?p=1778032
If that post doesn't answer your question, maybe you could give me a bit more context for your question.

This is expected behavior. SimPE reports the values stored in the neighborhood package. The game doesn't use the same definition of Width and Height that we are using. Instead, the coordinate system of a lot is dependent upon the U11 value stored in the neighborhood. If U11 is 1 (top) or 3 (bottom), then the width and height should match our definition. However, if U11 is 0 (left) or 2 (right), then the values should be reversed from our definition. Please note that I'm just going from memory on the meaning of the U11 values above - I might have them wrong - look at the link above for the correct details.

Fascinating assumption. What possible basis could you have for this assumption?

Nominal was just the word I used for it. That's not part of Sims programming jargon. Yes I meant any record that had data with a coordinate format in the field that normally holds coordinates.



Surely that's the benefit of the team we seem to have built - between us we're covering quite a few areas of knowledge. I can help out with simantics-related advice (ie the type of areas the PJSE plugins cover), Niol is good at lower level stuff and reading hex files, others are experienced house builders so can recognise when something is going wrong, and so on. We can all carry out tests you specify, too.



I am also aware of a "level" field which denotes which floor an object is on. Floor in this sense means where there is an upper grid. Not the same as absolute height. Levels start at 0 (even a cellar is 0 as you had to lower the land) and go upwards. I believe the swimming pool floor is below 0, as level 0 carries on over the water. You will find a non-zero level specified in something like a non-modular staircase, where some of the tiles are on the floor above where the stairs start.



Well no, I would be surprised if it did, because they are stored in Objects.package (or custom object packages) and cross-referenced by the GUID. I think you should find GUID values in the lot file.