No, I don't mind. I have been trying to revision the Case Study Houses by AngelF. While working on CSH 2 Redux, I was unable to move a fence post light to a position which was currently unoccupied. Naturally, I was curious as to why this was occurring.

Subsequent testing made it clear that several vertices on the lot were unbuildable and that using the LotAdjuster to shift the lot would also shift the unbuildable area. I thought that I might have a bug in the shifting code in the newest versions of the LotAdjuster. So, I started to examine the records which were modified by the LotAdjuster, to see where the bug might be. No matter how hard I looked, I wasn't able to find any such bug.

However, while examining the Wall Graph and Wall Layer, I noticed an unhandled record named VERT. Since my problem was occurring on a vertex, I decided to look into this unhandled record and realized that it consisted of a list of coordinates (Level, X, Y) with an associated INT (likely an object instance). In general, a record which contains coordinates needs to be modified during an expand or shrink operation, so I did some further testing and realized that this was the record which was causing my problem.

Ah, good catch there, Mootilda!

I honestly find it odd that EA required a separate record for detecting object collisions for these vertex-positioned objects; why didn't they just use the existing object collision logic? Does this mean that the existing object collision logic fails for objects which are not placed within the grid (SnapObjectsToGrid false)?

Odd indeed; I have no idea; good question.

...and how is M&GS quarter-tile placement connected to this?

Many of the existing records were actually separated into quarter-tiles from the beginning, even if quarter-tile placement was only added in M&G. Vertex placement should be completely different from quarter-tile placement, which uses the existing object placement mechanism.

Hmm, interesting. Danke.

I'm hoping to have the lot uploaded by the weekend. So far, I haven't seen any odd behavior with the deleted VERT record. I've also been giving it a lot of thought and I am tending towards the belief that this is a reasonably safe modification. Thanks for the offer to help me test. I'll let you know if I actually start the upload process, so that you won't waste your time.

Thanks. There'll probably be something new to test by then.

If I ever had the VERT problem (which it is imposible to be certain about in hindsight), I would probably have solved it by using MoveObjects. Which might not work in all cases, but probably would in some. Thus muddying the record.

Corner columns would also be affected, wouldn't they? There are a few of those around. I'm presuming SnapObjects would not affect this, if the quartertile cheat doesn't.

Nice to know we don't need to go through and check existing adjusted lots!

OK, I've submitted the lot to the upload queue; thanks for the offer of help, even if I managed to convince myself that the lot is safe in the interim.

As far as I can tell, moveobjects doesn't affect the VERT record, which means that the problem cannot be resolved using this cheat. If the problem can be resolved with moveobjects, then it's likely not the VERT bug. Another excellent reason for EA to have avoided having two different collision detection mechanisms.

I'm not familiar with the corner columns, but I suspect that they are just normal objects which are positioned off-center within the tile, rather than vertex-positioned objects. Since I've never actually created an object, I'm not at all sure what causes an object to be added to the VERT record.

I expect you are completely correct about that.

I should have thought of it myself, having already decided similarly about things like wall lamps and paintings. Oh well. Good luck with the upload.

I've tried the VERT delete trick, but still am having a problem. A square in front of my fridge isn't really playable. There's no column near it, there are some walls that were out of the usual playable area but not near the area, I have no idea if this is fixable. Any other ideas? I can't recall what the original size of the lot was, so can't change it with lot expander again. Plus, I've been playing it for awhile and it just started happening. Is this related to Lot Adjuster or something else entirely?

If deleting the VERT record does not fix your problem, then you were not experiencing the LotAdjuster VERT bug. This bug will not affect an entire square, but only the corners of a square; ie, you will be able to place objects in the square, but will not be able to place walls, fences, or objects which sit on the corner of a tile.

I seem to remember seeing something about squares in front of fridges becoming unusable. Try the Stuck Object Remover at MATY:
http://www.moreawesomethanyou.com/s...pic,1609.0.html

I notice that the Lot Debugger also has an option to unblock fridge tiles, so you could try this as well:
http://www.moreawesomethanyou.com/s...topic,72.0.html

All,

I'm still trying to catch up what I've missed so far.

And, I've already started to parse some more on the object-related files under the base game.

Hopefully, the relevant wiki pages will be updated soon in a few days for at least the base game infos for objects. I'll try to integrate Inge's infos ithem as well.

Hopefully, Inge is OK with this.

I've updated the roof file page some times ago.
May check if any error I've badly made.

Roof wiki looks fine, niol. I'm glad that you're back and working on this.

Currently working on xobj files.

Welcome back to what's really important in life - the sims :D

Shower me some rains instead!


Anyway, I guess it takes more trials to figure the xobj file format. I'm making a few more instances to see clearer. I've figured the 8 obj mesh rotation and the basic outline only. There shoudl be more to figure out.
Co-ordinates can't be a problem here.

I have a question/suggestion, though it seems so obvious it might have been asked before: I understand the suns direction on a lot is determined at its first placement and doesn't change later, so it's some data stored somewhere in the lot file. The LotAdjuster can display this information, and I'm wondering if there's maybe a way to change this information, too, thus changing the suns direction in game?
It would be a nice feature, with that a sunny front house could be converted to have a sunny backyard without having to rebuild the whole thing on a new lot. Has anyone ever looked into this?

Yes, it's quite difficult, but probably not impossible. Here's the discussion thread:
http://www.modthesims.info/showthread.php?t=328167

I believe that I know most of what needs to be done, but I'm not that familiar with quaternions, so I'll need to learn how to rotate objects before this becomes feasible.

ok, seems to be a more complicated process than I thought, thanks for the link.

Here's a link which shows what happens when you just change the flag. It can still be a useful thing to do.
http://www.modthesims.info/showthread.php?t=255110

Baed on my experiences and understanding, the former cannot guarantee the latter because they are spawned through different sorts of portals.


Bravo!


As for the vert record, can a blank replace the corrupted one easily? Just wonder.
I normally finish building before shrinkage and expand a lot before building. Also, I rarely place objects at lot edges after shrinkage. But, I do use fence post lights a lot though. Thus, that may affect my shrunken lots. Seemingly, the best practical work-around for the old lots is to delete the VERT record and replace the vert-based objects.

I guess I 'll try to see what it's like in my cases after parsing the needed parts of the obj-related files.

Custom Corner columns can be just off-centre object mesh in its object placeholder, and this can be checked in the cres or gmdc file of the given object package file. But better and faster is to check if they do place the obj instance value as a sign for blockage in the VERT record.

From my own experience,
1. the placeholder centre of snapped objects inside a grid will still affect the same in-grid blockage but unnecessarily grids where its mesh(es) which may happen to be "on".
2. If the placeholder centre appears at a border of 2 grids, the blockage is still on either in-grid of the 2 grids but not the vertex, which depends on from where the grid is counted probably according to the lot orientation.
3. If the placeholder centre appears at a vertex of 4 grids, the blockage is still on one in-grid of the 4 grids but not the vertex, which depends on from where the grid is counted probably according to the lot orientation.
4. However, vertex-placeable objects like fence-post lights can really sit at the vertex. Now, I wonder if fence post affects the VERT record. If so, both partitions and object should affect this file, but simply based on what is said something like "obj instance in VERT record", that's unlikely.



Unfortunately, TS2 supports quite a wide of range of languages which means unless you check out all available languages, tutorial neighbourhood can't be easily excluded.
It may be easier to just exclude the "Tutorial" and probably a few suggested ones and accept that users may not be bothered to skip and avoid such folder and neighbourhood by themselves when they do consider the work you've done on your "behalf" (maybe, "be-most")...

3 Alternative suggestions:
3a. users may be asked to manually delete the tutorial neighbourhood or replace it with a blank. The latter is what I do currently to further trim away "rubbish", I call, to reduce the data size!
3b. probably a blacklist profile txt can easily allow users to discriminate against their dislikes from appearing in the menu. Surely, a whitelist profile is a plus.
3c. simply an extra browse button for all neighbourhoods while keeping the present exclusivity for the menu.

Anyone ? Any more alternative? I've given 3 suggestions already, it's your turns!



Finally, finished most of the missed posts. :D





Yes, the first time I realised it "several years by now" I got the same lamentation like "I'm just disappointed that EA is so inconsistent between EPs. Each EP seems to break things that used to work in previous EPs."
Since I relaised such change, newer wallpapers (wall recolours) I've made are mostly tailored to by-pass such changes by "pattern modularisation". I tried very hard on that in the Simstone set (the set with bump-map enabled), but you know what, certain wall deformation still breaks the modularity of the set. Now, I regard that's my bads not to consider any further than consistency.

I can't remember clearly whether the change started from TS2 EP5 or TS2 EP2.
A wall overlay recolour like pixelhate+Numenor's wall overlay recolours (May search pixelhate for that) may be a nice work-around this problem across different game versions for these re-reolourable "deformed" partitions (like standard walls, foundation wall, attic walls).
TS2 EP5 has the the attic wall presentation altered.

Deleting the existing VERT record is the best option. You'll lose the protection that this record provides, but I can't find any other ill effects. Note that you may be corrupting the lot if you delete the VERT record as a way of getting around truly invalid placement.

While this may be useful for people who are comfortable with removing files from their hard drive, I can't see making it a prerequisite.

This is probably more difficult for non-techies than option 3a.

I think that I'd prefer to have the Tutorial neighborhood displayed than to avoid displaying perfectly correct neighborhoods.

Just wanted to gather together some information from various other threads, related to XOBJ modding:

From: http://www.modthesims.info/showthre...541#post3084541

From: http://www.modthesims.info/showthre...273#post3091273
Probably the best way to do this testing is to avoid diagonal placement in the initial testing. Instead, try changing each normal placement to an alternative normal rotation and then test interactions with the object. Only do the diagonal testing once the other testing is complete.

If this information is to be useful for programs like the LotAdjuster and LotRotater, then it's important to avoid picking up the objects in-game during testing. Objects should both look and act correctly without user intervention.

I've not read the new posts yet,

just wanna add in my piece before that, but I've not attached the graphics yet, sorry.

Note the following are all conducted under TS2EP0 (TS2 base game).

If a careful pick fails, the in-game undo can return the object back to the object placeholder direction and its location. So, there's no way to get it wrong as long as the users know what to do.

Attached are the graphics to show my confirmational tests screenshot for such modication on the xobj file of lot package file.

The 500S$ TV set is a nice example to demonstrate that it is the particular sims - object interaction that really defines if sims can interact with a buy/build/reward-mode-object but not simply by the object alone. Apparently, it's the locked grids defined in a particular animation that limits, but that's only a speculation.

The working one is the "watch" action of the TV set while the one not working is the "work-out" action. Also, the pictures shows that it may take diagonal sestings for sims to sit down coz sims all stand watching instead sitting down, yet this is sort of out of our currently concerned scope.


Updated after reading the previous post:

I think solving the placeholder direction and location is important for further efforts on rotation of objects by any programme because once in-game, the object placeholder can affect how the objects be placed and rotated. I now speculate xobj is actually a file mostly for the object placeholder.

As inferred or mentioned in the quoted, using programme to do the work is the final way as suggested. Thus, I see no problem.

Sorry for the disorganised posting arrangement I made.




Updated for vert record talk:

I only think of replacing that particular value with zeros or the norm value.

If the lot is toasted, then I'll do as suggested to delete that record and go back in-game for regeneration.