Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Site Helper
Original Poster
#2376 Old 1st Feb 2010 at 7:17 PM
Quote: Originally posted by GeneralOperationsDirector
Mind if I ask how this VERT record issue came to your attention? Just curious.
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.
Advertisement
#2377 Old 1st Feb 2010 at 7:31 PM
Ah, good catch there, Mootilda!

This Space Intentionally Left Blank
Site Helper
Original Poster
#2378 Old 1st Feb 2010 at 8:22 PM
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)?
#2379 Old 1st Feb 2010 at 8:31 PM
Odd indeed; I have no idea; good question.

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

This Space Intentionally Left Blank
Site Helper
Original Poster
#2380 Old 1st Feb 2010 at 8:56 PM
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.
#2381 Old 1st Feb 2010 at 9:17 PM
Hmm, interesting. Danke.

This Space Intentionally Left Blank
Site Helper
Original Poster
#2382 Old 1st Feb 2010 at 11:46 PM
Quote: Originally posted by aelflaed
I've downloaded it, but won't have much computer time until the weekend.
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.
Alchemist
#2383 Old 2nd Feb 2010 at 7:37 PM
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!
Site Helper
Original Poster
#2384 Old 2nd Feb 2010 at 7:47 PM
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.
Alchemist
#2385 Old 3rd Feb 2010 at 11:40 AM
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.
Test Subject
#2386 Old 16th Feb 2010 at 3:51 AM
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?
Site Helper
Original Poster
#2387 Old 16th Feb 2010 at 6:11 AM Last edited by Mootilda : 16th Feb 2010 at 6:21 AM.
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
Mad Poster
#2388 Old 26th Feb 2010 at 11:42 AM
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.
Site Helper
Original Poster
#2389 Old 26th Feb 2010 at 3:12 PM
Roof wiki looks fine, niol. I'm glad that you're back and working on this.
Mad Poster
#2390 Old 27th Feb 2010 at 10:15 AM
One horse disagreer of the Apocalypse
#2391 Old 2nd Mar 2010 at 9:01 AM
Welcome back to what's really important in life - the sims :D

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Mad Poster
#2392 Old 4th Mar 2010 at 9:55 AM
Quote: Originally posted by Inge Jones
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.
Top Secret Researcher
#2393 Old 4th Mar 2010 at 6:03 PM
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?

Check out Omicron-Simtauri, my new space project!

Newest creation on my Livejournal: Fish with party hats: Garland and default
Looking for an Underground Station? thread on GoS
Grungy cars! thread on GoS latest: VW Type 2 Two-Tones
Site Helper
Original Poster
#2394 Old 4th Mar 2010 at 8:52 PM
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.
Top Secret Researcher
#2395 Old 5th Mar 2010 at 12:03 AM
ok, seems to be a more complicated process than I thought, thanks for the link.

Check out Omicron-Simtauri, my new space project!

Newest creation on my Livejournal: Fish with party hats: Garland and default
Looking for an Underground Station? thread on GoS
Grungy cars! thread on GoS latest: VW Type 2 Two-Tones
Site Helper
Original Poster
#2396 Old 7th Mar 2010 at 1:51 PM
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
Mad Poster
#2397 Old 8th Mar 2010 at 11:49 AM
Quote: Originally posted by neighbourhood water level and in-lot neighbourhood water level (aka lotskirt water)
http://www.modthesims.info/showthre...409#post2984409

There're 3 types of "water" sheets in a lot:
1. terrain water (sInce the base game, TS2EP0; "This one is fairly easy to manipulate" by Mootilda from post 2304)
2. lotskirt water (the in-lot simulated neighbourhood water since TS2EP2-NL; also aka the beach/sea/ocean water in beach-lot since TS2EP6-BV)
3. swim-pool water (sInce the base game, TS2EP0)

It's the second one that caused the "problem" due to such placement.

Indeed, this is defined and set in the neighbourhood shader.
Quote: Originally posted by 0xCD7FE87A 0x1C0532FA 0x26B3DB7C 0xFF3A262A
# water clipping plane
setf waterHeight 312.45

I'm unsure if the value in a neighbourhood package file is more local and acts an override, but change in neighbourhood shader is obviously global. Let's not forget the possibility that the UI in the exe may still have the final say simply because some codes and values are hardcoded there which can make shader modding useless...

BTW, guess what?
Quote: Originally posted by 0xCD7FE87A 0x1C0532FA 0x26B3DB7C 0xFF3A262A
setv3 nhoodSunDir (-0.5, 1, 0.5) # default -- should be set by code from the lighting.txt value

Besides...,
Indeed, although the in-lot sun direction can be altered through lighting.txt-modding, this will globally affect all lots as a result. So, it's only useful for screenies, stories and movies but not for playing convenience nor total unification.




Quote: Originally posted by portal issues
Baed on my experiences,
1. Either extra more or missing 1 pedestrian portal is just simply all right. The more portals mean the way how pedestrians come and go.
2. As for extra vehicle portal, I'd tried it in my manually made para-2-road-sided lot. I manually added in extra pedestian and vehicle portals on the newly made road. In such testing for several sims days, I realised the school bus and the vehicles came in one side while the service vehicles entered from the other side. Besides such oddity, nothing problematic was spotted.


Quote: Originally posted by psychosim0
I tested carpool and schoolbus and they work fine on 1x1 residential. I guess it's the same for the emergency and service cars.

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

Quote: Originally posted by psychosim0
Placing an object in the cars path "breaks" the normal function and the car will just pop up on the street without driving animation.

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.


Quote: Originally posted by Mootilda
Can anyone help me? If you have a non-English version of the game, is the Tutorial neighborhood named "Tutorial" or something else? Thanks!

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



Quote:
I just noticed that wall coverings align at the bottom in the base game and at the top in Mansions & Gardens. Does anyone know when this changed?
...
Confirmed wall coverings align at bottom for NL and OFB.
...
I've confirmed that the wall coverings align at the bottom for AL.
...
the wall covering problem is M&G-only


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.
Site Helper
Original Poster
#2398 Old 11th Mar 2010 at 4:48 PM Last edited by Mootilda : 11th Mar 2010 at 10:27 PM.
Quote: Originally posted by niol
As for the vert record, can a blank replace the corrupted one easily?
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.

Quote: Originally posted by niol
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.
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!
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.

Quote: Originally posted by niol
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.
This is probably more difficult for non-techies than option 3a.

Quote: Originally posted by niol
3c. simply an extra browse button for all neighbourhoods while keeping the present exclusivity for the menu.
I think that I'd prefer to have the Tutorial neighborhood displayed than to avoid displaying perfectly correct neighborhoods.
Site Helper
Original Poster
#2399 Old 11th Mar 2010 at 10:25 PM
Default XOBJ modding
Just wanted to gather together some information from various other threads, related to XOBJ modding:

From: http://www.modthesims.info/showthre...541#post3084541
Quote: Originally posted by niol
Based on what I'm currently testing, the graphical presentation of the object including its meshes, they're defined by a range of "00, 01, 02, 03, 04, 05, 06, 07" for the 8 in-game allowed visible graphical object rotations in the xobj file. I'm unsure if quaternions are mostly for other components of the related objects.

PS, the 8 values should be for the object placeholder coz in anothere set of tests, it takes a pick-up of the objects befroe the meshes and their graphics rotate to the already rotated object placeholder.

Upon further instances, I realised more to dig to solve the xobj file for a definate routine to locate the placeholder rotation value. I've figured the ones of visible in-game objects and some of their corresponding invisible objects. I just realised there're other switches that can alter the logical offset locations, so I'm gonna compare that later.

Just a brief description, under TS2EP0, a newlty made plain lot was added decorative sculptures step-by-step.
Upon an addition of such, an invisible obj called "circularSocialDistanceMarker" is added.

From: http://www.modthesims.info/showthre...273#post3091273
Quote: Originally posted by niol
Yes, altering the placeholder value alone can eventually cause the object to rotate upon a later careful pick-up. In some conditions, other cheats like moveobject on and grid-snap may be applied to facilitate such doing.

In some cases in my testing under the base game alone, the objects gets rotated automatically while in some, it takes the in-game in-lot pick-up before the meshes follow the object placeholder. With the act of the object pick-up in lot, the direction of the object placeholder appeared to cause the object meshes to rotate automatically and the object palceholder remains its direction though such direction wasn't normally available in the base game.

Indeed, I'm thinking the game has at least some checks on enforcing the object meshes and probably some other invisible components to alter automatically upon the change in rotation value of the object placeholder for unified alignment as a whole.

Let's dissect the act of object placement. Upon an object placement, one may change the object direction. The UI tool seems to link to the values for the object placeholder (regarded as the "ultimate" object container) which holds all components of the visible object in the interface. So, the act to rotate the object may mean to rotate the object placeholder followed by automatical alignment for value changes in contained components. So change in TS2-object-rotational quaternions shouldn't be far from grabbing by at least a few means.

Based on such rationale, a simple modification for that value and users's manual pick-ups should easily do the job. However, I'm still determining the other conditions that may affect the offset of this value. Also, I'll need to install other game versions to check any potential change among versions. Also,, it's always easier and more convenient to the user end to have a programme to do all the repetitive work.

If I can mod in a way to cross the components of other objects and animations, what will that be like upon the first loading supposing no check enforcement is there before graphical presentation while the duration of such check if present is long enough for people who happen to capably spot?


Anyway after all, like you said, it'd better check if any problem with sims interactions may occur. This is added to my to-do list for this part of the testing.
Note, in TS2, many objects were not prepared to interact with sims at diagonal placements; for example the beds...
Diagonal placement in TS2 is mostly for decoration only.
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.
Mad Poster
#2400 Old 12th Mar 2010 at 10:55 AM Last edited by niol : 13th Mar 2010 at 11:41 AM.
Default xobj modding
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.
Screenshots
Attached files:
File Type: zip  1.zip (279.3 KB, 5 downloads) - View custom content
Page 96 of 97
Back to top