CTD when loading

[samisu84 2]

Hello everyone,

I have an issue using Scoty modular parking everytime this file presence in Plugins folder the game CTD while loading the city and when I remove it the game works fine, any suggestion that might help resolve this issue with MAC user.

[rsc204 21,817]

Most likely it's related to the problems outlined in this post.

@hugues aroux: Any chance you could take a look at fixing this issue? If you need any help I'm happy to assist.

[hugues aroux 3,811]

2 hours ago, rsc204 said:

Most likely it's related to the problems outlined in this post.

Hi, I am aware of this problem. As indicated in the ScotyModularParking doc, this was fixed before the ST edition, hence my inability to provide help. One thing to test: empty the plugins directory, and leave only the SMParking + scoty_MP_textures + Scoty_MP_essential files and run a city ... problem on dependences ??
I'm willing to look at each TE just in case, but ... patience !

[rsc204 21,817]

I just checked on my Mac and with only your download installed, indeed the game won't start. Note, this issue is probably NOT related to the TE switches, since those problems usually only cause problems when trying to place the Lot in-game.

Therefore, it is more likely an errant Float32 Property with a single rep but the rep count set to 1 not 0, essentially this:

On 22/05/2020 at 6:32 PM, rsc204 said:

If any Property in an Exemplar is a Float32 value that contains only 1 Rep, the Rep. value MUST be set to 0 or Mac users see problems.

Fixing this problem requires iLives Reader, a 32-Bit Windows application (a problem for users without access to Windows), we can just update the faulty values, save the affected file and all should be fine (instructions in previously linked post).

Here in Reader is one of the files (by Spa - Since Patched), identified to contain such problem values:

Note how once more the Float32 Property is used for the highlighted values and that again they contain one Rep but not the correct 0 Rep. value. Long and short, we don't yet know how far this problem goes. If it can be caused by both Buildings and LotConfiguations Exemplars, why not Prop, Flora or pretty much any Exemplar Type, which might have the incorrect value. The change seems to be that when compiled as a 64-bit App, it's suddenly essential this value is set correctly.

I'm looking through all the files myself to try and track down the error, since I can test it here, which I'm guessing you can't, that gives me an advantage. But I had to DATPack the mod, because I can't look at that number of individual files in a time-efficient manner for a problem like this. I'll report back if I find the issue.

[rsc204 21,817]

@hugues aroux

Quick update, I've found the 26 affected files, thank god I remembered DataNode (by Rivit) has been updated to flag these issues, or I might have been ages looking for them manually. Once those 26 files are removed from the set, sure enough SimCity 4 loads without error. I'm just in the process of patching/testing those now, so don't waste your time working on it too, I'll send the fixes on once I've had a chance to verify them.

[hugues aroux 3,811]

il y a 18 minutes, rsc204 a dit :

PAS lié aux TE

in fact it is all the parking entry files ... TE FILES! I just checked my 110 files and, mea culpa, 6 or 7 of them had escaped my control when the plugin was published. I sent to Samisu84 a corrected package for testing.

[rsc204 21,817]

Yes, I did find 4 TE issues, but that's NOT the main problem here, it's actually in the LotConfig files... see my previous quote.

[hugues aroux 3,811]

27 ??

[hugues aroux 3,811]

arrgh ... we write at the same time so I didn't have time to translate your message ... wait a minute ... so ... oh I didn't know this problem of Rep in Lotconfig ! On my side I corrected the exemplar building !

[rsc204 21,817]

No worries, all fixed and tested, game starts fine now. Like I said, about 4 or 5 TE bugs remaining, but those won't cause the Mac game to CTD on startup... whereas the other issue does. But DataNode showed me where to find the problems and if you update the attached 26 lots, everything should now be fine .

ScotyFix.zip

[hugues aroux 3,811]

Oh!! thank you!! It was really nice of you to take this time. On the other hand ... in fact ... 2 questions
- where does this error come from ? Is it with PIMX, sc4tool, reader 1.5.4 .. ?
- How did you find this error in Datanode ?

[rsc204 21,817]

We know the TE Rep bug comes from SC4Tool and happens every time you save a TE Lot.

I tried to get people to see that the LotConfig issue was a different thing, even though the root problem (a 1 where there should be a 0), looks the same, they are not the same bug and lead to very different results. Sadly, certain other people tried to drown me out and take over everything, rather than work together to find a solution that didn't involve them only, in other words it all got political.

As a result, I don't believe any coordinated effort took place to track down the cause of this second problem, which so far I've only seen for the same three properties as in the quoted screenshot above. Indeed, those were the problem for the 26 files in question here, if I had to guess, I would say that's probably coming from SC4Tool as well. PIM-X seems to hold up really well and whilst I tend to stick to Reader 0.93, it seems odd that someone would break something like that updating it.

For now, the best thing to do is simply to run a DataNode scan before you release any works, especially for large packs like this. Select TGI View / Faulty and all such exemplars come up in Purple:

But I warn you, as is often the case many other things which may not actually be a problem come to light during the scan. For example in the screenshot, many lines are shown with the ArrayType used, 0 Reps expected error, but only three of these actually cause problems. It also flagged 399 errors from the Buildings Exemplars in the set, which I just ignored and I'm fairly certain nothing that would cause problems is lurking in there. The point being, you have to know how to sift through the data, to pinpoint the problem. Between that and the fact I have a Mac to test the issue, I figured it was just easier to handle the fix for you, it's really no problem.

[hugues aroux 3,811]

Wow, great info! Thanks RSC!

Well, when I make Lots again, I'll try not to forget this and test at the various stages of my making process, you never know if I might spot something.
I did notice that you didn't correct another float32 [filling degree]. I hope you are not the only Mac-User to test other people's plugins... you are not done yet ;-). I am glad to know that everyone can use my plugins. This little effort is worth it.
@samisu84... sorry ... forget my previous post and watch Scoty's modular parking page ... I'll publish the correction made by RSC204, and mine, as soon as possible today or tomorrow morning (Paris GMT)

[rsc204 21,817]

9 minutes ago, hugues aroux said:

I did notice that you didn't correct another float32 [filling degree].

Yes, I wonder if that's what flagged the 399 Buildings Exemplars, this is a Property used exclusively by PIM-X and the game doesn't read the data, so it's a non-issue.

[samisu84 2]

1 hour ago, rsc204 said:

No worries, all fixed and tested, game starts fine now. Like I said, about 4 or 5 TE bugs remaining, but those won't cause the Mac game to CTD on startup... whereas the other issue does. But DataNode showed me where to find the problems and if you update the attached 26 lots, everything should now be fine .

ScotyFix.zip

Thanks a lot , all fixed and tasted works fine now.

[rivit 3,391]

15 hours ago, hugues aroux said:

- where does this error come from ?

 

15 hours ago, rsc204 said:

I don't believe any coordinated effort took place to track down the cause of this second problem

I think this problem is mostly inadvertantly caused when incorrectly using Reader to add a new property in an exemplar.

Maxis did something confusing in defining NREPS=0 to be a simple variable, but NREPS>0 is a (potential) array of values. 

The Reader property lookup generally defaults to the correct NREPS. For a lot of properties this is 0 which, by definition, means store 1 value in a simple variable. If one overwrites this to be a 1 thinking that is what is meant to be then it implies an array of 1 value is to be stored, when actually only a simple variable is enough. In general leave the default as is - its seldom wrong.

In Datanode I've checked for these from the outset, but as a lot of them do not trigger problems because SC4 is pretty defensively programmed, I suppressed the messages. I didn't flag these issues until the CTD problem arose for FLOAT32 in the MAC environment. Here when a FLOAT32 with no reps is expected, and its stored as an array (REPS>=1) but there's only one value to read the CTD happens. This was found to be the default mode in TE saves in SC4Tool. In effect its the same thinking error as I described above.

If the Filling Degree (from PIM-X) is provably ignored by the MAC version I can suppress these errors for that Property if necessary - but it's still a simple variable (you cant have multiple Filling Degrees) and should have NReps=0.

 

[rsc204 21,817]

50 minutes ago, rivit said:

If the Filling Degree (from PIM-X) is provably ignored by the MAC version I can suppress these errors for that Property if necessary - but it's still a simple variable (you cant have multiple Filling Degrees) and should have NReps=0.

I assure you it's not a problem, otherwise much of my content would trigger issues. Of course, being Apple, just wait for an update to screw that one asunder. Since PIM-X adds this to every Buildings Exemplar, it'd be better to suppress the error IMHO, since it's one less edit modders might feel compelled to make.

50 minutes ago, rivit said:

I think this problem is mostly inadvertantly caused when incorrectly using Reader to add a new property in an exemplar.

Whilst I can see how that would be an issue, certainly there are specific properties where such behaviour can be observed, it doesn't fit with the specifics of what I'm seeing. If you look at the LotConfig Exemplars, in all the cases I've so far found, including a couple of my own downloads, the Rep error has always been confined to the same three properties:

MinSlopeAllowed
MaxSlopeBeforeLotFoundation
MaxSlopeAllowed

Whilst it's not inconceivable that modders would manually add these properties, I don't think it's highly likely either. Since every lot comes with them by default, it's not usually necessary to do anything more than edit the values. I'll add too, in every case I've seen, all three of these values always has the error, I've never come across one where not all of them are bad. That would lead me to think it's a save error rather than a result of user meddling... I really should just mess around with SC4Tool and see what happens when saving lots there. But it tracks that this would be the main culprit for me, since we know it messes up the TE Properties too, it kinda fits that there is a more general issue with how it saves these data types.

[rivit 3,391]

Interesting...

I just checked the Datanode code and I had already made an exception for Filling Degree - this because its always written only by PIM-X and with as NREPs=1. (incorrectly!)

Also Only FLOAT32s will be flagged as a Faulty TGI file even though all the others are coloured in the display at the property level.

I havent got any of those flagging in my Plugins - but I dont have a huge set. I'm very inclined to agree with your view that they're not properties many would manually add. Is it possible that the Properties you've named above could also result from PIM-X? ( in addition to SC4Tool?). I dont use PIM-X so can't actually test that and starting a new lot would probably be the best way of testing it - it may actually preserve the NReps if used to edit an existing Lot.

I'll check if cloning/editing a lot (with those properties wrong) in LotEditor propagates that error, or even starts it from LE. Cloning in Reader is trivially easy and does exactly that - if it was wrong it stays wrong. What other Tools other than Reader,and SC4Reader can edit those properties I wonder?

EDIT

LotEditor  does not propagate these min,max properties errors - it always set them back to nReps=0

[rsc204 21,817]

1 hour ago, rivit said:

Is it possible that the Properties you've named above could also result from PIM-X?

Maybe, they are but aren't editable in PIM-X, which is hard to explain, but I'll come back to you privately on that one.

I just edited the Properties in question for a handful of lots with SC4Tool then saved them. I am not seeing any signs to suggest there is a consistent error happening there, so indeed we may need to look elsewhere.

What about LEProp?, a lot of folks still use that I imagine? Again, with the same tests as SC4Tool, no sign of the issue and I am fairly certain you can't edit the specific values in question using this tool either.

I think PIM-X is fine with the exception of the Filling Degree which isn't really an SC4 Property anyhow. I say this because the sheer amount of content created using it, but of course the same could be argued of SC4Tools? As mentioned, only after the issue came to light did I find two of my own files affected, but despite knowing how I do my modding, I wasn't able to pin it down to a specific app given all the time that has passed since creating them.

[hugues aroux 3,811]

I don't know if this can help, but in my case: all (SMParking) Lots were created on PIMX, LEprops, then some passed in SC4Tool for transit ... and my only "manual" intervention was for the two transit values...[cost|capacity] in IliveReader 1.5.4! I swear ... I didn't touch my LotConfig files ;-)

Most of the files spotted by rsc were files that went through the SC4Tool !
I often had writing errors in PIMX and LEprops uh ... and Reader too ... actually!

 

[rsc204 21,817]

3 minutes ago, hugues aroux said:

I didn't touch my LotConfig files ;-)

One thing we can say with certainty, this isn't a modding error or something attributable to particular users. Clearly some combination of tool/app + specific change is causing these incorrect values. As a Windows user, like all modders, the odds you'd find these problems are somewhere around 0. Whilst the TE bug is easy to check if you know about it, practically speaking who's checking hundreds of lots that work fine in-game? But that's why it's good we have DataNode, it's a good 'final sanity check' that can spots things that otherwise remain hidden.