Missing textures and objects after saving

[xxdita 1,097]

18 minutes ago, CorinaMarie said:

Disclaimer first: I have only a passing acquaintance with PIM-X.

But, the logic here has me confuzzled.

• SimCity selected = about 19 lots
• SimCity + PEGPROD selected = the same 19 lots

Doesn't that indicate that no new lots appear when adding Peg's folder to the start up search? In other words, wouldn't that actually be showing none of them in Peg's is now using that prop?

I think you're missing the point. Yes, the PEG lots are opened by both props, when the PEGPROD folder is selected at startup. 

But why would a newly created prop have any connection to a Maxis lot? If I had to guess, I'd say someone tried to take a shortcut to fix the files, instead of actually creating a new and unique prop, so the connections have not been fully broken. 

What I see in PIMX does not give me any confidence that the file has been properly fixed. 

[CorinaMarie 29,578]

22 minutes ago, xxdita said:

I think you're missing the point. Yes, the PEG lots are opened by both props, when the PEGPROD folder is selected at startup. 

It's more likely I completely missed the implications of your point. That's why I asked. The logic of it doesn't seem to hold water.

 

23 minutes ago, xxdita said:

If I had to guess, I'd say someone tried to take a shortcut to fix the files, instead of actually creating a new and unique prop, so the connections have not been fully broken. 

Prolly best to not guess in this case. Rest assured as we said here:

25 minutes ago, Cyclone Boom said:

We have complete faith in the modding abilities of the highly skilled person who created these patches, and they assured us of the method's technical correctness.

 

27 minutes ago, xxdita said:

What I see in PIMX does not give me any confidence that the file has been properly fixed. 

What about checking with Reader since it's the ideal tool for that?

[xxdita 1,097]

If the files have been properly fixed, then PIMX would not be confusing the props as one and the same. If PIMX is doing this, I believe the game will as well. 

I can't say what that would actually do, good or bad in the game itself. I have never come across this before. 

However, the way I would correct these files would be to completely remove the timed props and create new instances for each one. This is as Tibi suggested earlier in the thread, and would require a bit of relotting to get the timed prop used on PEG's lots instead of the Maxis prop. This is the only way to be totally certain that Prop Pox cannot happen moving forward, although it is still a real possibility for anyone that may already have the original PEG timed props in their cities that chooses to update the files. Outside of SC4Fix, there is little that can be done about that. 

I have presented the information to you as I know it. I really don't know what more I can do on this matter. If you choose to ignore the issues I've raised, then that's on you. 

[CorinaMarie 29,578]

1 minute ago, xxdita said:

If you choose to ignore the issues I've raised, then that's on you. 

Noted.

We'll consider this done unless someone else has the technical expertise to prove the safety of the patched files either for or against.

[Tyberius06 12,184]

Yepp my confusion and the initial confusion came from the fact that the download page doesn't show that anything has been updated since 2015. Therefore people who might have the faulty one will not see a reason for updating their copy. 

The second confusion with @xxdita's experience in PIM-X is coming from the fact that the new prop using the same prop family IID as the original one (since it is a copy), and pim-x has the feature to open up every building examplar with a prop/family IID was being used. Since the new one now is sitting next to the old one in the same prop family that's why the maxis lots came up.

Best would be to remove the prop family property from the new prop. This is a default maxis family anyway. That act would also prevent further confusions.

- Tyberius

 

[rsc204 21,806]

9 hours ago, xxdita said:

To clarify, if the IIDs have been changed, then for all intents and purposes, these are now new props completely?

Honestly, do you really need me to tell you a third time? I have twice already stated this to be the case?!?

8 hours ago, xxdita said:

So even with the new IID, PIMX is showing that this newly created prop is in use on original Maxis lots. I see nothing that suggests that the Maxis lots have been redone, to replace the Maxis prop with the newly updated PEG umbrella. 

This statement is a paradox.

On one hand you are telling me, that despite now using unique IDs, these new props are showing up on Maxis lots? But on the other hand, you are suggesting we need to remake the Maxis lots to use said new Props?

It can't be both, so all I can do is address both sides.

If as you state, the original Maxis Lots are using the Props from this fixed version with unique IDs, someone would have had to made modified versions of said Lots. They are not included in the released files and more amazing still, how would anyone know the ID's used by these Props to make them?, which hitherto had not been released. That's before you consider how such edited lots could have made their way into your Plugins folder, without your knowledge?

The simple answer: whatever you think you are seeing, it not what's happening at all. You simply must be either misinterpreting the results or otherwise have another copy of the modified Maxis Prop, with the original IDs, somewhere in your Plugins folder. There are literally no other possible explanations I can think of, for what you have described. It certainly doesn't fit with what I'm seeing in PIM-X on the Maxis Beach:

Clearly this is the old Prop, it neither contains the Timed_ prefix, nor links to PEG's dependency, instead to simcity_1.dat, as we'd expect when no override was present. Now let's compare that to one of the adjusted OWW lots, PEG-OWW2_3x3_Beach. We can clearly see the new Prop, denoted by the Timed_ prefix. We can also see that no Maxis equivalent is here either:

We can also clearly see where this Prop comes from, the BDK files as expected. These were thoroughly checked by myself in 2017 and a quick spot-check today, confirms that indeed all six affected lots, which have been updated, all no longer use the Maxis Props/IDs.

Whatever you are seeing must therefore be something unique to your setup and therefore nothing to do with the patched files.

============================================================================

Updating the Maxis lots is probably not a good idea, but certainly outside the scope of this fix. Ultimately, if a user already has used the faulty file, there is nothing we can do retroactively in terms of fixes/patches to change that. Whether moving forward you use the fixed files or not, nothing is changed in terms of the potential for Prop Prox. At least from here on out, those using these files will never see new instances of the problem, it's literally the best possible outcome that we can implement.

The simple fact is, right now the files hosted on the STEX, no longer contain the problem. Are you really suggesting that it's better not to fix the files, which I note you yourself have supported in this very thread? Yes, those who have used the broken version, will still suffer the consequences. Those people should try SC4Fix, which has a good track record for allowing cities to be restored. We're just making it so that this isn't necessary any more to deal with the problem. We have only made things better, within the limited confines of what is possible.

7 hours ago, CorinaMarie said:

Doesn't that indicate that no new lots appear when adding Peg's folder to the start up search? In other words, wouldn't that actually be showing none of them in Peg's is now using that prop?

The file in question is simply a dependency, indeed you will see no new lots if you just install the PEG-OWW2_BDK_RESOURCE.dat file alone. It was this dependency that overrode some original Maxis Props, 4 of which, were changed from RKT1 to RKT4 originally, which is thought to be the culprit behind Prop Pox. In total there have been 4 Props that were affected, all of which no longer override the original Maxis ones, if using the patched files they are now unique/independent Props.

This is also why the two packages using those Props, (obviously not including other content which used these Maxis Props), needed updating to link to the new ID'd Props also. The original Maxis ID'd Props still exist, but now are no longer being overriden and function again as they did originally for any lots using them. The only content that uses the new Props are from the updated PEG packages that have been switched to use them instead of the original Maxis ones. I.e., six lots from the following files:

• PEG-OWW2_BDK_Beaches_110.dat
• PEG-OWW2_3x3_Beach-Hut_101.dat
• PEG-OWW2_2x3_Beach_Bathrooms_100.dat

This is necessary since only the newly IDd props function as intended, i.e. the beach gear disappears at night.

All these changes can be observed in Reader, exactly how CB shows in the above posting. Here is how the updated dependency looks in Reader:

We can see items 11 through 14 have been edited along with the DIR file from CB's screenshot. Here you can clearly see the Instance IDs, comparing that to the original is really not complex to do. Likewise, you can see the other change where the prefix Timed_ was added, to each of the Exemplar Name properties, which differentiates them in LE from the original Props.

8 hours ago, mattb325 said:

Based on that piece of information, whether the file update is an over-ride or new lot actually takes a back seat: if it is an over-ride, existing cities may have their save file poxxed and the solution is the SC4Fix+the updated file. If it is a new IDD, then the SC4Fix is still required for existing cities. This of course, is what xxdita's initial post non-specifically referenced, but you didn't quote that part.

If you install the fixed files, SC4Fix is no longer necessary to prevent new instances of Prop Pox. Of course, there is nothing wrong with installing SC4Fix, I agree it's a good idea and have nothing but praise for what this .dll file does.

None of this is the point, it never has been and still is not the point of my argument, which is really, really simple. Therefore, I am struggling to comprehend why I am still having to repeat myself?

You can not go around accusing people of making faulty mods, i.e. a fix that causes or continues to cause Prop Pox. This is especially unacceptable when the person doing it, clearly doesn't understand enough to make such a statement or hasn't even bothered to look at the fixes. These are facts borne out here not with my words, but those of others, yet the original information remains and still there seems to be an air of questioning the validity of these fixes?

10 hours ago, mattb325 said:

If your only beef was pointing out potential ambiguity in xxdita's post, you've chosen a mightily circumlocutive way to go about it.

On 28/04/2020 at 1:12 AM, xxdita said:

Sadly, by 'fixing' the problematic file, you have created further prop pox issues for anyone that updates to the new version, if they already have the prop in place in existing cities, even if preventing new players from having to face it. So I would encourage anyone already using the file to keep the one they have. 

No Matt, there is no ambiguity in the statement, that's the entire problem. Extending from the quote to the entire post, does not bring about any ambiguity either. Xxdita clearly states here that not only have we created further problems, which is not true. But also that he encourages everyone not to used the fixed files, which doesn't hold up to scrutiny. If you are finding ambiguity in that statement, then I don't think any words I can use would change your perception.

============================================================================

No one here wants to stifle the ability of the community to peer review any such fixes or content in general, but I don't believe anyone benefits from ignoring facts or making accusations that don't stack up. In this respect, those who choose to act so recklessly are being disrespectful to the author of the fixes and doing a disservice to the wider community. If you state opinion as fact, then prepare for the facts to be continually pushed back at you. Note that having an opinion, is not the same as stating it as fact, this is key to my problem with some people's behaviour.

On the other hand, if someone actually does find a problem, we're only too happy for them to alert us to the situation, after all what is the point of updating these files? To ensure that there is no chance of people getting Prop Pox by using them. If it were not for how political this issue has been, I seriously doubt it would have taken this long. In other words, people making such a big deal out of something, has actually had a detrimental effect overall. Finally we have the courage to deal with the problem, only for people to come and unfairly question the fix. This is exactly the sort of situation that was in mind, when the last time this issue came up in 2017, prevented us from updating the files. Doing so is supposed to draw a line under the issue, not to continue speculating and inflating the issue.

When prominent community members continually suggest something is faulty or wrong, users will continue to have doubts and I believe this is at best counter-productive. If you can be bothered, I mean who doesn't like reading 30+ pages of archived threads, read the Prop Pox thread on SC4D entirely. I have and can say without question, Prop Pox is a problem that's been continually blown all out of proportion. These fixes should represent a chance to finally draw a line under the whole debacle so everyone can move past it. But, if regular users can't be confident of the fix, then it just continues to add fuel and speculation to the issue.

It's exactly why it's so dangerous to allow incorrect speculation, specifically in this instance, to go unchallenged.

The simple fact is, if you want to challenge the legitimacy of these fixes, then it is up to you to provide the evidence to support it. I've not seen one instance of that here, just a lot of very misplaced logic, that doesn't ever get to the heart of the matter, but instead confuses it further.

If fixing these files is only going to bring the whole matter to the fore once more, then the goal behind the action is seriously compromised. Honestly, what are we supposed to do, revert the fixes and restore the problem files? Just take down these files from the STEX completely, so no one can enjoy some great content? Because if people can't have faith in the quality of this, one of those two scenarios is the logical end game here.

I'll add too, that the fixes here were made based on the following information:

Quote

Original Post: https://www.sc4devotion.com/forums/index.php?topic=7066.msg224892#msg224892

If you want to avoid the above described cause of Prop Pox, you have the following choices:

1-    Refraining from using Pegasus CDK3-OWW2 lots (the beach resource file contains a couple of SSH files used by the other OWW2 lots). Wait Pegasus to release a patch to his package correcting the problem props.

2-    Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, delete the items 11, 12, 13 and 14 (exemplar names R1x1x2_BeachChair_29B2, R1x1x3_PatioChair_290D, R1x2x2_Recliner_2911, and R2x3x2_$$Beachumbrella_2900), and save the file again. The three first props will no longer be time-dependent (the umbrella will still be time-dependent, appearing only during day time). But the lots will work fine. With no Prop Pox.

3-    Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, change the exemplar name (p.ex., add a PEG_ before each name) and the instance of the items 11, 12, 13 and 14 (mark each one and select “generate new instance”), and save the file. Load each of the beach lots into LotEditor and replace each occurrence of these props by the corresponding new PEG_* prop and save the lots. Replace the original lots by the modified ones. They will work exactly as designed, but will no longer lead to Prop Pox.

So, not only are people questioning the validity of the works by the author, but also the very person who's probably done the most to deal with Prop Pox. Information which has gone unchallenged for 11 years, now suddenly people are questioning it? This is a form of madness and simply cannot be tolerated. Either the release of these fixes, which I can verify follows all the information outlined by BAP, is accepted as the end of the matter, or it will end some other way which is probably far less desirable.

[rsc204 21,806]

11 hours ago, xxdita said:

What I see in PIMX does not give me any confidence that the file has been properly fixed. 

10 hours ago, xxdita said:

If the files have been properly fixed, then PIMX would not be confusing the props as one and the same. If PIMX is doing this, I believe the game will as well. 

I can't say what that would actually do, good or bad in the game itself. I have never come across this before. 

However, the way I would correct these files would be to completely remove the timed props and create new instances for each one. This is as Tibi suggested earlier in the thread, and would require a bit of relotting to get the timed prop used on PEG's lots instead of the Maxis prop. This is the only way to be totally certain that Prop Pox cannot happen moving forward, although it is still a real possibility for anyone that may already have the original PEG timed props in their cities that chooses to update the files. Outside of SC4Fix, there is little that can be done about that. 

I have presented the information to you as I know it. I really don't know what more I can do on this matter. If you choose to ignore the issues I've raised, then that's on you. 

So you mean to say that you've never come across Prop Families before and do not understand how they work?

Again, once more with feeling, Prop Pox has only ever been known to happen when Props are overridden, altering the RKT types. So, the new Props, whether or not they are in a family with the originals, provided they are new, unique instances, DO NOT meet this criteria.

You are just simply wrong and at best speculating I believe with the intent of undermining the work done to fix the issue. But don't take my word for it, open the file PEG-OWW2_BDK_RESOURCE.dat and simply delete the Prop Familes from the 4 Prop Exemplars. Now you will see that none of the "linking" you are using to tenuously slur the quality of the modding done, simply no longer occurs. Quite how you do not know this I am at a loss to explain. But you know what, I've made those changes and attached the file, which can be verified by anyone.

Of course, I await your inevitable response with some other spurious reasoning, where you continue to undermine the work of others. Rather than try to be constructive in any way. None of this changes how you've now gone from not being OK with the fixes. To being OK with them. To finding fault with them once more. It says a lot about your process that you are being so wishy-washy and one can only speculate about your motivation here.

PEG-OWW2_BDK_RESOURCE_NoPropFam.dat

[T Wrecks 10,209]

*siiiigh*

Way to turn a user's question into a big mess.

Why guess and speculate, though, when things can be tested? Helpful people have provided test cities precisely for the purpose of testing for prop pox. The ones in the first post of Simmaster07's thread are still freely available for everyone.

Want to prove a point? Take the allegedly non-functional fix, apply it to the test city and grow the test city beyond the critical save game size and look at the save game: does it or does it not show prop pox symptoms? Feel free to share the save game here for public scrutiny. It's as simple as that, really - provided one's honest intention is to be certain.

[xxdita 1,097]

I never had any intentions of using any of PEG's files. PEG was made fully aware of the problem his files caused, and refused to do a damn thing about it. Instead, he blamed anyone else that he could think of, including NAM. 

So you're damned right that I am going to be cautious about any supposed fixes to these files. It still boggles my mind that TPTB were handed a fix and sat on it for three years before uploading it. But what we're seeing in this thread is light compared to how it was when PEG was actually around, so I don't blame the staff for not wanting to get involved in this crapfest. 

[Tyberius06 12,184]

5 hours ago, rsc204 said:

The simple answer: whatever you think you are seeing, it not what's happening at all.

5 hours ago, rsc204 said:

Again, once more with feeling, Prop Pox has only ever been known to happen when Props are overridden, altering the RKT types. So, the new Props, whether or not they are in a family with the originals, provided they are new, unique instances, DO NOT meet this criteria.

You are just simply wrong and at best speculating I believe with the intent of undermining the work done to fix the issue. But don't take my word for it, open the file PEG-OWW2_BDK_RESOURCE.dat and simply delete the Prop Familes from the 4 Prop Exemplars. Now you will see that none of the "linking" you are using to tenuously slur the quality of the modding done, simply no longer occurs. Quite how you do not know this I am at a loss to explain. But you know what, I've made those changes and attached the file, which can be verified by anyone.

It was happening due to how the PIM-X handles the props/families. The original lots don't use the prop family, just the old or new prop as individual, while if you keep the prop family in the new prop, the original maxis lots which will grow after the BDK fix and using that particular family would use this new timed prop too. It's not a problem, since it has a new IID, but the cleaner way if the update contains the above attached PEG-OWW2_BDK_RESOURCE_NoPropFam.dat, so the maxis lots won't use the new prop and the PIM-X won't read all the maxis lots with this prop family. 
Everybody wins, everybody is happy!

The fix is good, the last attached file is even better (someone should make it into the original upload), thanks for it, it was time to do it. I still think, that an official update (uploaded new version with change log etc... not just with a sidenote) would be more clear and clean, than a hidden fix, which won't be noticed by anybody who didn't care to read this long and boring topic, but at least the new comers won't have this sideeffect...

Can we move on and close this f... up chapter finally? That would be soo nice... 

- Tyberius

[mattb325 28,880]

On 02/05/2020 at 3:11 PM, rsc204 said:

You can not go around accusing people of making faulty mods, i.e. a fix that causes or continues to cause Prop Pox.

I have never said that the fixes outlined by BAP are incorrect in any way shape or form. Nor have I said that the fix from 2017 using BAP's methodology is incorrect.

BAP's work was meticulous, and, like PEG's has been scruitinised for the best part of a decade.

My statement supporting the listing of the SC4Fix as a dependency is effectively an either/or statement; you've chosen only to address the 'or', which I already knew. To address the 'either' part of that statement, most players will not go looking for a fix until their cities are poxxed, and then, in your words (in that same post), SC4Fix "has a good track record for allowing cities to be restored". 

That is why the SC4Fix should be listed as a dependency together with the corrected exemplars.

On 02/05/2020 at 3:11 PM, rsc204 said:

Sadly, by 'fixing' the problematic file, you have created further prop pox issues for anyone that updates to the new version, if they already have the prop in place in existing cities, even if preventing new players from having to face it. So I would encourage anyone already using the file to keep the one they have. 

This is quite incorrect. You have gone from a post to just sentences, and worse, you have highlighted words which you believe pertinent: ignoring words in that same sentence that offer a different and supportive stance. If your emphasised words are what drove you to say the things you have said against Xxdita in this thread, then that is a choice you have made. Xxdita's initial post, which you have only ever quoted in snippets remains ambiguous.

@Cyclone Boom and @CorinaMarie

Despite your post telling everyone to discuss the topic not each other, it is disturbing to see a number of ad hominem attacks which are in breach of the site rules (paragraph 6): "Any inappropriate or unwelcome attention, harassment, solicitation, or sexually orientated comments or behavior directed towards another member, either publicly or privately, should be immediately reported to a Simtropolis Staff member".

The following posts contain a staff member attacking an individual and make for uncomfortable reading to say the least. Even if the staff member felt that their explanation was being attacked, that is no reason for the following derogatory remarks:
Post #25: everything from and including the second quote is a personal attack.
Post#37: the first sentence after the quotes and the entire last paragraph is a personal attack.

Could I ask you as admins to please edit these out (or compel the original poster to do as much)? It reflects very poorly on the site if a moderator breaches fundamental rules of engagement with other members.

Lastly, as others have said, it will be great to put this issue to bed after all these years, and point users to a fixed file.

 

[Tyberius06 12,184]

Now what? Really? @mattb325  
I don't know if I should cry or laugh... I'm tired of this argument and I hasn't been even involved that much deeply.
Matt, there is a problem with the first bolded part in that quoted sentence. It is NOT true in that form. The city save file is already corrupted by the original PEG file, so the "you have created further prop pox issues for anyone that updates to the new version", is simply NOT true. There are no further prop pox issues with the new updates, because the prop pox issue is already in the city save file. It will prevent newcomers to have this issue, but doesn't matter for those who already had the file. They can safely update to the new version or keep the original one, it doesn't matter, their situation won't be better or worse anyhow, for those people the only solution is the SC4 FIX. So the "So I would encourage anyone already using the file to keep the one they have. " line is sure, but it doesn't matter again. The only reason why it matters for them NOT to keep the original one and rather updating to the new one is because, if they start a new region and build a new plugin folder up for it, then they will have the clean and proper/fixed version instead of the old/broken one. So in any case encouraging anyone to update would be preferable. And also using the SC4 FIX for sure. 

There were mistakes being made on every sides in this situation (including myself), and I can understand partially every sides, because everybody managed to add something new sh... into this situation making it worse, than it was supposed to be. The only thing which was not a mistake, that finally these files have got their fix. Hurray! And regardless that the quality of the fix have been questioned, which started the s... storm, this is the best working option (well, @Cyclone Boom and/or @CorinaMarie the really best would be using the PEG-OWW2_BDK_RESOURCE_NoPropFam.dat, after it has been renamed to match with the original one). 

 

[xxdita 1,097]

I'm not trying to pick apart the fix. But as it is not my file, I have not done any testing of it. More importantly, I have seen no evidence that anyone has actually tested it. I can't say that such testing hasn't been done. It may not have been published, or I may have overlooked it. I do see that bap tested a similar fix back in 2009, and the updated files do match up with his suggested fixes. 

So we can be confident that new players, and in fact all new cities using the updated PEG files will be free and clear of Prop Pox going forward. This is a tremendous victory for everyone. 

But as bap said in his testing:

Even if the cause of Prop Pox is no longer in your game folder, if your city has been saved while the pox “virus” was there, you are infected and will get Prop Pox.

So anyone who has a city that has any of the PEG override props already written into the game save file will continue to be at risk for Prop Pox, regardless of whether they update the affected files or not. The damage is already done, and there seems to be nothing outside of SC4Fix that can correct that. 

[Cyclone Boom 16,854]

Oh dear.

On the whole, the unfolding events of this topic indeed haven't been pleasing to see. Deeply disappointing in fact, but it's kind of what was expected when such a sensitive subject of Prop Pox comes into the fray. It is a shame when misinformation can spread, and then the difference of opinion are what causes disagreement, frustration, and conflict. That's the way things go, and it sure would be nice if everyone could just get along. The way the world is, and we're here arguing about technicalities of a video game.

We don't believe it's helpful when people jump to conclusions, but again it seems like it's all our fault for not making known the files were updated with the 2017 internal dates. In hindsight we should've made this absolutely crystal clear when replying initially, which would've likely avoided the patching process being challenged like we'd made matters worse. The person who created these patches knew what they were doing, as explained in detailed form. That's how things have gone, and it's unfortunate when trying to help make a situation better and all that ensures is a another fine mess.

This explains our reluctance to implement the patches 3 years ago. We knew this was coming, but decided for the greater good of the community to bite the bullet and see how things go. The resulting downwards-spiral is quite regretful really, but let's move on.

There have certainly been unwanted attacks in this thread. That is a shame to see, and isn't conductive to the friendly and welcoming community we want ST to be. There are violations of Rule 6 by more than one participant, which means it's no longer productive for this to continue. We don't feel this needs blowing out of proportion, so no further action will be taken at this time. What has been said has already been said, which is sad, but it is what it is.

It is understandable when frustration stems from a subject like this, and I think ultimately we all want the best outcome reached. Everything else is a distraction away from that greater goal, and it's our hope that everyone who has participated in this discussion shares this common ground. Maybe it can be learned from also?

To the OP of this topic, we apologise for how this has unfolded, but hope that the patched files combined with SC4Fix (if needed) will help others in future. Maybe with other files that might need fixing too, how that can be done using the valid established procedure which has been proven to work.

This has run its course now, and is clearly leading to no good. So based on that, regretfully...

Thread Locked.