LEX File Exchange
EA Support Files
SC4 Wikipedia
Network Addon Mod
Welcome to SimCity 4 Devotion. Please login or sign up.

March 20, 2023, 12:12:08 PM

Login with username, password and session length


Bugs with Occupant Size.

Started by HappyDays, April 24, 2011, 11:01:06 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


In iLives 1.4, Occupant Size is wiped out when editing ANYTHING in a building exemplar if width, height, or depth are set to particularly long numbers. Furthermore, information on width, height, and depth is inconsistent. For instance:

In CO$$8_3x1_Hashbi_734b60e6.SC4Lot, from the Colossus Addon Mod, the following is shown next to the Occupant Size property:

Width: 42, Height: 87.72309875, Depth: 14.33399963

However, when I actually load the property to edit it, it reads as follows:


Strange, but this isn't the major problem: If any property in the building exemplar file is changed (You enter a property, edit a number, set the changes, and exit the property), the Occupant Size property is set to 0 for all three dimensions. You must refresh the building exemplar page to see this, but it has indeed happened.

In iLives 0.9.3, the first bug (Inconsistent numbers) exists as well. However, I can edit the building exemplar without worry of anything being wiped out.


Happens to me too.  You can change the OS manually in PIMX, as a side note.

Your first issue is no problem.  Perhaps a bug, but we're talking about millimeters here, something that can't be seen in SC4.  Sometime I type in .8 and it shows up as .79999999, no worries.

I would say to use the old version of Reader.  I believe this problem doesn't happen in 1.4 when the Exemplar doesn't have a Type property, but that would have to be taken out and put back in using the old version anyway.  The problem isn't only to OS, but I believe something that ruins the entire Exemplar.


Speaking of PIMX, I believe that's the program used to generate the exacting numbers seen in CAMelots.

Regardless, I am indeed using the older version to get my building tweaks done. Still a solid program despite its age, I think.

Edit: Except, there's one problem.

I cannot edit Parent Cohorts. 1.4 will erase all parent cohort information if I change the instance due to the "Numbers too long" bug, and 0.9.3 doesn't even see them.


You can change Parent Cohort just fine in 0.9.3, the program just doesn't display them connected like in 1.4 or PIMX.

Using the exemplar analyzer I think you can sync to parent cohort as well.  Also in the analyzer there is a cohort finder, where you can change all of the parent cohorts values at once.  You can see my tutorial on how this is done (Link)

PIMX makes Descs and Lots just like MaxisPIM, though the method of creating values is more exact (as you say) by using a filling degree.  MaxisPIM creates a bounding box and determines values from that.  PIMX does the same thing, except that the filling degree is your estimate of how much the model actually fills the bounding box.  Yes, this is how you create CAMelots, but also any other lot.  It also has an LE.   


I've found this problem as well.  Glad I kept 0.9.3 around to fix it.  A bad OS was wrecking havoc with my poor props. :(
All new animated railroad crossing props for networks of all sizes! (Phase 1 complete)-->

Mostly writing pony stories on, but Cities: Skylines is my new best friend.  Anything and everything I made for SimCity 4 is fair game for use and distribution.


Cogeo and I have been having issues with Cohorts not working -His Thread.

For our case, it comes down to the difference between exemplars that come with SC4, and those that we have created in MaxisPIM or PIMX.  Simply, our exemplars are human readable (EQTZ1), and Maxis' are binarized (EQTB1)  (Thanks to Wouanagaine for the phrasing).

Our general understanding is that if you want cohorts to work properly, then the exemplars attached to them need to be taken from SimCity dat.  I have had issues further than that as well, but they don't apply to this.

Today I had similar results with the OS bug.  When I change the OS in an EQTZ1 exemplar, the property results as "Width: 0", one rep.  This does not happen with an EQTB1 exemplar...  As far as I know... I have only set the OS successfully, and not tried to grow in-game.

(Now to see if I wrote a script properly that can massively set OSes from the 0x####0000 S3D.)

Edit:  And we're growing in-game  (and yes it does :), sets the RKT too)


I may have had success dealing with this bug: DatPacker.   DatPacking changes the file type to EQTB1.  I just made a prop with PIMX, changed the OS in Reader 1.4, and re-opened it with PIMX.  I got the OS error report.  I then datpacked the prop, and got the report again.  However, when I opened this prop back up in PIMX, the report was gone.

More testing would be needed, and you would want to datpack before changing any stats with 1.4 (As HappyDays first post points out that changing the OS messes with other stats too).

I can say that it solves the Cohort issues, which makes going from a properly stated PIMX desc/lot to a streamlined cohort tree much easier.