Replies: 2423 (Who?), Viewed: 448807 times.
Page 55 of 97
Mad Poster
#1351 Old 28th Nov 2007 at 7:31 PM
Default [window placement][wall modding]
[window placement]
As for the windows, they can be removed before lot-resizing to avoid any potential problem and placed back after lot-resizing with moveobjects on cheat.

Surely, if the codes can handle them properly, keeping them is a plus.


[wall modding]

As for the walls and fences, I guess, there're more to study.
It seems the wall graphs are categorising the wall segments and at least obviously listing out their coordinates. I'm still struggling with the other values and where those numbers linked to.

From my previous fence testings, it appeared the wall graphs are also responsible for fences.

Changing the wall segment shape won't affect the wall mesh at all in gmdc in terms of any visible values presentable in the SimPE gmdc plug-in viewer.
Surely, I can't render the gmdc file with simPe.

I had a side of the only one wall segment deformed down to 4-click-high but can't see any differences from the one without such deformation in terms of 3D array instance 1. All other 3D arrays and 2D arrays remain the same between these 2 instances of lot file copies unless the hex view wasn't updated properly.

So, I assume the wall size can still be stored as those unsolved values.
Site Helper
Original Poster
#1352 Old 29th Nov 2007 at 4:03 AM Last edited by Mootilda : 29th Nov 2007 at 4:22 AM. Reason: Add title
Default [window placement] [wall modding]
Quote:
Originally Posted by niol
[window placement]
As for the windows, they can be removed before lot-resizing to avoid any potential problem and placed back after lot-resizing with moveobjects on cheat.

Surely, if the codes can handle them properly, keeping them is a plus.
I believe that the source code will be able to handle these properly, as long as the arrow faces in.

Quote:
Originally Posted by niol
[wall modding]
I had a side of the only one wall segment deformed down to 4-click-high but can't see any differences from the one without such deformation in terms of 3D array instance 1. All other 3D arrays and 2D arrays remain the same between these 2 instances of lot file copies unless the hex view wasn't updated properly.
Don't know for sure, but I believe that the wall height is completely determined by the 3D Array Instance 1 (terrain height). This is what convinced me that the original smoothing logic was too agressive. It was smoothing every layer in the array, which was actually changing the height of the walls, foundations and fences.
Site Helper
Original Poster
#1353 Old 29th Nov 2007 at 4:25 AM
Default Shrinking and crashing
Quote:
Originally Posted by ingeli
I tried to cut a lot where I built a part of a house on the part that was to be shrinken (it was a mistake, really) and again got a crash on saving after shrinking it. Redid, expanded, took out the built stuff and reshrink, worked fine.
Did the shrunken part of the house have anything on it, other than walls and roof? When you expanded, was everything back to normal?
Mad Poster
#1354 Old 29th Nov 2007 at 8:45 AM Last edited by niol : 30th Nov 2007 at 1:37 PM.
Default [wall modding]
It's buried in many "3" in terms of singles. The slight change from 64 to 63. My fault, to be careless.

Mootilda, you're right,

I finally found that one different bit.

It seems the pop-up info trick does tell the matching singles values in 3D array instance 1in-game.

So, now I'm gonna mod it to make it to further prove that's the way to make wall < 4-click-high...

added:
a pic for proof
I altered 0.75 to 0.375 in singles @ instance 1 of 3D arrays in the corresponding lot package file.
Screenshots
One horse disagreer of the Apocalypse
#1355 Old 29th Nov 2007 at 10:36 AM
I thought I might as well cover the cPerson for thoroughness while I am at it. That's why the extra delay in OBJT analysis. I don't think you'll be wanting to move people though.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Site Helper
Original Poster
#1356 Old 29th Nov 2007 at 3:09 PM Last edited by Mootilda : 30th Nov 2007 at 5:44 PM. Reason: Added title
Default Shrinking restrictions
Quote:
Originally Posted by Inge Jones
I thought I might as well cover the cPerson for thoroughness while I am at it. That's why the extra delay in OBJT analysis. I don't think you'll be wanting to move people though.
The LA definitely needs to be able to move people. Thanks for looking into this.
One horse disagreer of the Apocalypse
#1357 Old 29th Nov 2007 at 3:19 PM
Oh! I thought the user advice was to only shrink empty lots.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Site Helper
Original Poster
#1358 Old 29th Nov 2007 at 8:39 PM Last edited by Mootilda : 30th Nov 2007 at 5:39 PM. Reason: Add title
Default Shrinking restrictions
Quote:
Originally Posted by Inge Jones
Oh! I thought the user advice was to only shrink empty lots.
You mean unoccupied lots? Do you think that's necessary? The LA supports expanding occupied lots, so I assumed that it would also shrink them. Unless you know of some good reason to impose that restriction... Is there something in the lot package that would make this difficult?
One horse disagreer of the Apocalypse
#1359 Old 29th Nov 2007 at 8:46 PM
I had just thought those were the instructions we had agreed for shrinking. Presumably I have remembered wrong.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
One horse disagreer of the Apocalypse
#1360 Old 29th Nov 2007 at 10:22 PM
Ok try this. Let me know if you find OBJTs that don't fit this breakdown.
Download - please read all instructions before downloading any files!
File Type: zip OBJT.zip (6.6 KB, 18 downloads) - View custom content

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Alchemist
#1361 Old 29th Nov 2007 at 11:19 PM
The only problem I had with an occupied lot was because the sim was using the deleted part of the lot, and vanished. I got her back after some fiddling, and things worked otherwise. It would be wonderful to remove some of the 'do this/don't do that' guidelines about shrinking safely.
Mad Poster
#1362 Old 30th Nov 2007 at 6:46 AM Last edited by niol : 30th Nov 2007 at 2:17 PM.
Default [lot shrinking - precaution changes?][wall modding][rotations - lighting-to-shadow towards origin]
[lot shrinking - precaution changes?]

if we can be sure certain features are really working, the shrinking guidelines will need revisions and updates.


[wall modding]

May check out my last post to show the wall height modding.


[rotations - relative directions of lighting, shadowing, origin]
The origin of a lot U11 is at the corner opposite to the corner of lighting source. The shadowing of an object is also pointing at the direction of origin corner.
Site Helper
Original Poster
#1363 Old 30th Nov 2007 at 5:36 PM Last edited by Mootilda : 30th Nov 2007 at 5:38 PM. Reason: Clarification
Default Shrinking restrictions
Quote:
Originally Posted by aelflaed
The only problem I had with an occupied lot was because the sim was using the deleted part of the lot, and vanished. I got her back after some fiddling, and things worked otherwise. It would be wonderful to remove some of the 'do this/don't do that' guidelines about shrinking safely.
I originally suggested only one restriction: the parts of the lot which will be deleted must be empty. I wanted the restriction because it would mean a lot less work on the source code, since the OBJT record type was not well understood. At the time, I didn't realize that it was an impossible restriction -too many invisible objects that people had no control over.

So, Inge and I are working on the OBJT code and we'll try again soon.

I'm still going to suggest that the areas of the lot which will be deleted should be empty. The difference is that the LA will now handle the invisible objects better, which will hopefully eliminate (or at least reduce) crashing.

I'm also hoping that the changes to the OBJT code will completely handle occupied lots.

My work with off-world WGRA (walls and fences) and FPL (fence posts) has not been encouraging - lots of crashes and nothing usable so far. However, walls and fences on the edge of the lot may actually be OK, since they are still technically "on world". I'm not so sure about the roofs, though - needs more research.

I don't remember who suggested the restriction that shrunken lots should be flat, but there is some evidence that the game will crash if it has a problem resolving lot edges. So, row houses really need to have "matching" terrain - not necessarily flat.

The question is whether we should test the new OBJT code before making any changes to the wall, fence and roof structures, or whether I should finish the work on those structures before we try another mass test.

Does anyone know of any other restrictions that they believe are required?
Site Helper
Original Poster
#1364 Old 30th Nov 2007 at 5:44 PM
Default Internal data structures
Quote:
Originally Posted by Inge Jones
Ok try this. Let me know if you find OBJTs that don't fit this breakdown.
Thanks, Inge. I'll get this information incorporated in the source code, then run some automated tests and get back to you with any exceptions.

In the interim, I'd like to suggest that you use the technically correct term for strings with byte lengths: 7BITSTR. It only really matters for strings with lengths > 127 (handled by a byte with the top bit unset), but it's more correct and may help people avoid the kinds of problems that the LA had with these strings.
One horse disagreer of the Apocalypse
#1365 Old 30th Nov 2007 at 5:56 PM
Quote:
Originally Posted by Mootilda
In the interim, I'd like to suggest that you use the technically correct term for strings with byte lengths: 7BITSTR.


What - so I lump the count byte in *with* the string and call the whole lot "7BITSTR" ?

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Site Helper
Original Poster
#1366 Old 30th Nov 2007 at 6:33 PM
Default Internal data structures
Quote:
Originally Posted by Inge Jones
What - so I lump the count byte in *with* the string and call the whole lot "7BITSTR" ?
That's right. For examples, you can take a look at the wiki entries for:

6B943B43 2ARY
2A51171B 3ARY
FA1C39F7 OBJT
One horse disagreer of the Apocalypse
#1367 Old 30th Nov 2007 at 6:51 PM Last edited by Inge Jones : 30th Nov 2007 at 7:12 PM.
Ok I see it now. Trouble is I can't make head or tail of those file format pages, so I wrote it in a way that means something to me. It's hard to know what to do, cos if I start trying to copy what my predecessor did, I'll probably start using some of the terms wrong then we'll really be in a mess. When in doubt I tend to document things in plain English lol. I still have to count on my fingers to work out how many hex digits in a byte or a dword. I don't really know what a dword is and what makes it more special than any other 8 bytes (or is it 4 bytes?) Well it's 8 characters I think.

If I do the analysis in English, would it be a lot of trouble for someone else to translate it into Wikilish?

Mind you, I wouldn't have done it like they have, which is to seperate out the bits of the OBJT over several pages. I think it's easier to work out what's going on keeping it all together, because it's sort of nested.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Site Helper
Original Poster
#1368 Old 30th Nov 2007 at 8:02 PM
Other than the 7BITSTR, I think that your format is just fine. A 7BITSTR is actually different than a byte followed by a string, but only for strings > 127 characters. I'm sure that's why Andi's code never crashed until recently.

If you feel uncomfortable with my advice, please feel free to ignore it. I think that it's more important to get the wiki updated with what you've found, than to get the terminology correct.
Alchemist
#1369 Old 1st Dec 2007 at 3:56 AM
Quote:
Originally Posted by Mootilda
I'm still going to suggest that the areas of the lot which will be deleted should be empty. The difference is that the LA will now handle the invisible objects better, which will hopefully eliminate (or at least reduce) crashing....I don't remember who suggested the restriction that shrunken lots should be flat, but there is some evidence that the game will crash if it has a problem resolving lot edges. So, row houses really need to have "matching" terrain - not necessarily flat.
?
I'm happy with keeping the shrinking area empty, I was only meaning that it is better to have less stuff people need to keep track of - "make sure the space is empty" is a guideline people may follow, where a long checklist gives more scope for trouble.

I think we said lots should be flat at the front, because of the road/portal problems. With the smoothing you have added, uneven terrain on the other three sides seems fine - as far as I can see. You may well have other information. (How closely do the terrains need to 'match'?)

I've been playing my shrunk community lot pretty continuously, to see whether any weird stuff develops over time. Nothing so far. When you have a new version ready for me to test, naturally I will do that.

I admit to having left the TOC alone for a bit - it's tedious, and I have been doing other things. I got about halfway.

As for other restrictions on shrunk lots, there was that building list plasticbox or someone wrote out, which presumably still applies.
One horse disagreer of the Apocalypse
#1370 Old 1st Dec 2007 at 9:42 AM
Quote:
Originally Posted by aelflaed
I think we said lots should be flat at the front, because of the road/portal problems.


I have good working lots with non-flat roads. It is *easier* (but not mandatory) to keep the first and last ten tiles flat, but they don't have to be the same height as each other. This is a good way of keeping the terrain contours interesting and should not IMHO be discouraged out of hand. A simple warning about sloping roads making life more difficult should suffice.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
One horse disagreer of the Apocalypse
#1371 Old 2nd Dec 2007 at 10:10 AM Last edited by Inge Jones : 2nd Dec 2007 at 5:08 PM.
Mootilda, I b****edup the original XOBJ breakdown. Quite understandable that I might have thought the ones with the hydrangea GUID in them belonged to the hydrangea, but no, the ones for the hydrangea do not have the hydrangea GUID in them, something else does :mad:

So while I complete the breakdown of the whole XOBJ, I can at least now tell you the instance number of the XOBJ *is* the same as the object in-lot ID which is also the same as the OBJT instance for that object. And both can be cross-referenced from the ref number in OBJM - so the original LE was getting that right.

The ones with the GUIDs in them are the "What's This?" markers.

Later: Well most of the XOBJ contains stack data, so as far as I can see it's still only the previously documented coordinates that need adjusting by the LA. The third coord in the group I have verified to be floor level (1 being ground), rather than height in metres from lot baseline, which is used by the OBJT.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Mad Poster
#1372 Old 3rd Dec 2007 at 7:27 PM
Site Helper
Original Poster
#1373 Old 4th Dec 2007 at 8:50 PM Last edited by Mootilda : 4th Dec 2007 at 9:05 PM. Reason: Clarification
Default Internal data structures: FPL
Quote:
Originally Posted by niol
just updated FPL file in wiki, please help check it.
Suggestions:
- Specify that the Block ID = AB4BA572
- Note that the only known Block Version is 1. Other versions may change the structure of the rest of the record.
- ? Hex offset 48 is a part of the following 7BITSTR and should just be included in the Block Name entry "7BITSTR (offsets 48-57 in hex)". If necessary, you can point out that the first byte of this particular 7BITSTR is the length.
- Count N has hex offsets of 58-5B
- A DWORD is not 8 bits, so it's very confusing for you to say that it is. A bit takes a value of 0 or 1 and a DWORD has 32 bits. However, I don't see the number of bits as useful information, so you should just remove it. The term "DWORD" or even "DWORD (4 bytes)" should be sufficient.

FYI: A half of a byte is called a "nibble", but no one really uses this term. From http://foldoc.org/?nibble
"nibble: Half a byte. Since a byte is nearly always eight bits, a nibble is nearly always four bits (and can therefore be represented by one hex digit)."

- A FLOAT is by definition a single floating point number, so the term "FLOAT (4 bytes / 8 bits)(in Singles)" doesn't seem right. Here are some suggestions: "FLOAT", "FLOAT (4 bytes)", "FLOAT (Single / 4 bytes)".

FYI: A single floating point number is called a FLOAT (or, if necessary, "Single FLOAT") and has 4 bytes. A double floating point number is called a DOUBLE (or, if necessary, "DOUBLE FLOAT) and has 8 bytes.

- I found the following statement a bit confusing: "coordinate dependent on the lot orientation". As far as I know, the only "orientation" that is recognized in SimPE is the Orientation of the lot in the neighborhood, which is not the field that you want. I assume that you're talking about the U11 value, which is not (yet) well documented. Perhaps just "fence coordinate"? We really need to document the U11 value somewhere and how it affects all of the coordinate values in the lot file.
- "GUID ID" is redundant, since a GUID is a type of ID. Use either GUID or ID, but not both.

FYI: GUID is an acronym, meaning a Globally Unique Identifier.

- Can you put each link on a separate line?
- I would rephrase both properties; they are somewhat confusing. How about "Deletable. If deleted, all fence posts on the lot disappear."? The second property is a run-on sentence and needs to be split into several simpler sentences.

Overall, looks good. I hope that you find these suggestions helpful.
Mad Poster
#1374 Old 5th Dec 2007 at 6:13 AM
:slapface:, sorry, I was going boo-boo... for byte-bit interchanges.
Now, I 'll remember clearly... :D

Thanks for your point-outs.
Forum Resident
#1375 Old 6th Dec 2007 at 5:10 PM
mootilda, have you given any thought to the much needed definition of 'what is a safe lot'--or more pointedly: 'what is a safe enough lot to allow us to find testers for it'?

You really can't/shouldn't go on ignoring this forever.....
Page 55 of 97
Back to top