- Site Map >
- Modding and Creation >
- Sims 2 Creation >
- Modding Discussion >
- Research & Development >
- Discussion: Lot Size, Orientation, Rotation, etc.
- Site Map >
- Modding and Creation >
- Sims 2 Creation >
- Modding Discussion >
- Research & Development >
- Discussion: Lot Size, Orientation, Rotation, etc.
#1351
28th Nov 2007 at 6:31 PM
Posts: 4,403
Thanks: 10659 in 115 Posts
[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.
Advertisement
#1352
29th Nov 2007 at 3:03 AM
Last edited by Mootilda : 29th Nov 2007 at 3:22 AM.
Reason: Add title
[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. |
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. |
#1353
29th Nov 2007 at 3:25 AM
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. |
#1354
29th Nov 2007 at 7:45 AM
Last edited by niol : 30th Nov 2007 at 12:37 PM.
Posts: 4,403
Thanks: 10659 in 115 Posts
[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.
#1355
29th Nov 2007 at 9:36 AM
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1356
29th Nov 2007 at 2:09 PM
Last edited by Mootilda : 30th Nov 2007 at 4:44 PM.
Reason: Added title
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. |
#1357
29th Nov 2007 at 2:19 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1358
29th Nov 2007 at 7:39 PM
Last edited by Mootilda : 30th Nov 2007 at 4:39 PM.
Reason: Add title
Shrinking restrictions
Quote: Originally posted by Inge Jones
Oh! I thought the user advice was to only shrink empty lots. |
#1359
29th Nov 2007 at 7:46 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#1360
29th Nov 2007 at 9:22 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
Ok try this. Let me know if you find OBJTs that don't fit this breakdown.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Attached files:
OBJT.zip (6.6 KB, 20 downloads) - View custom content | ||
40448 11-29-07 21:13 OBJT.doc -------- ------- 40448 1 file |
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Alchemist
#1361
29th Nov 2007 at 10:19 PM
Posts: 2,894
Thanks: 17927 in 66 Posts
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.
#1362
30th Nov 2007 at 5:46 AM
Last edited by niol : 30th Nov 2007 at 1:17 PM.
Posts: 4,403
Thanks: 10659 in 115 Posts
[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.
#1363
30th Nov 2007 at 4:36 PM
Last edited by Mootilda : 30th Nov 2007 at 4:38 PM.
Reason: Clarification
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. |
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?
#1364
30th Nov 2007 at 4:44 PM
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. |
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.
#1365
30th Nov 2007 at 4:56 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
#1366
30th Nov 2007 at 5:33 PM
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" ? |
6B943B43 2ARY
2A51171B 3ARY
FA1C39F7 OBJT
#1367
30th Nov 2007 at 5:51 PM
Last edited by Inge Jones : 30th Nov 2007 at 6:12 PM.
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
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)
#1368
30th Nov 2007 at 7: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.
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
1st Dec 2007 at 2:56 AM
Posts: 2,894
Thanks: 17927 in 66 Posts
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 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.
#1370
1st Dec 2007 at 8:42 AM
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
#1371
2nd Dec 2007 at 9:10 AM
Last edited by Inge Jones : 2nd Dec 2007 at 4:08 PM.
Posts: 11,682
Thanks: 9680 in 11 Posts
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)
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)
#1372
3rd Dec 2007 at 6:27 PM
Posts: 4,403
Thanks: 10659 in 115 Posts
[info update in wiki]
just updated FPL file in wiki, please help check it.
http://www.sims2wiki.info/wiki.php?title=AB4BA572
just updated FPL file in wiki, please help check it.
http://www.sims2wiki.info/wiki.php?title=AB4BA572
#1373
4th Dec 2007 at 7:50 PM
Last edited by Mootilda : 4th Dec 2007 at 8:05 PM.
Reason: Clarification
Internal data structures: FPL
Quote: Originally posted by niol
just updated FPL file in wiki, please help check it. |
- 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.
#1374
5th Dec 2007 at 5:13 AM
Posts: 4,403
Thanks: 10659 in 115 Posts
:slapface:, sorry, I was going boo-boo... for byte-bit interchanges.
Now, I 'll remember clearly... :D
Thanks for your point-outs.
Now, I 'll remember clearly... :D
Thanks for your point-outs.
#1375
6th Dec 2007 at 4:10 PM
Posts: 682
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.....
You really can't/shouldn't go on ignoring this forever.....
Who Posted
|