SC4Fix: third-party patches for SC4

[Girafe 1,729]

there is one well known CTD which is quite annoying for modders and reproducable quite easily.

The game crashes automatically when using infinite Mayor Mod Ploppable items.

By infinite MMP I mean : when clicking once 1st object is appearing (Examplar 1), twice 2nd object ...

All the examplars are linked to the next one in the .dat file. However the last examplar is not linked to any other. Then the cycle stops.

It would be amazing to link the last examplar to the 1st one to have a complete cycle however the game crashes at this stage.

 

[vortext 573]

30 minutes ago, Girafe said:

It would be amazing to link the last examplar to the 1st one to have a complete cycle however the game crashes at this stage.

 

It would indeed be seriously amazing if this could be tackled, I imagine it'd open up new possibilities for tree controllers as well. . 

[rsc204 21,862]

Agreed, that's something that would make working with MMPs much easier. No more finding the wrong orientation, you could just cycle until the right one appears.

[Gn_leugim 858]

The infinite mmp loop was something I've tried before and would be awesome. "one mistake? just keep ploping. one bad oriented prop? just keep ploping".

Also, I would like to see the multi-core processor issue tackled, I feel like I only use 1/4th of my pc all the time

Anyway, seriously, congratulations on this amazing job! (so amazing you made me log in to comment! )

 

[T Wrecks 10,210]

I'm wondering what it actually is that prevents transit-enabled lots from being plopped right next to another in the direction of traffic flow, and if there would be a possibility to overcome this limitation. It would open up the way to functional modular railyards, functional modular alleys and parking lots, etc. that would be extremely simple to create for many users with basic lotting/TE'ing knowledge - as opposed to SAM overrides or PED Mall puzzle pieces etc.

[rsc204 21,862]

Off the top of my head, it doesn't cause a CTD, something in the code prevents the pathing from working through both lots simultaneously.

[OrSpeeder 72]

Random information on the multicore issue:

SC4 create threads, mutexes and whatnot (you can see using any task manager app, "Process Explorer" being my favourite).

But seemly it only uses them to allocate and deallocate memory, meaning it has multi-threaded safe loading of files, but nothing else, thus why it is "mostly" stable with multicore.

 

On my machine at least it crashes a lot with multicore enabled  I guess because SC4 can't handle the infamous gettick bug, and my laptop is prone to cause that bug.

 

Info on the gettick bug:

 

You can ask the processor, for the current time with nanosecond precision... for  this to work, the processor itself must count time, instead of using the system clock, this of course is unreliable (ie: over time it become more and more offset from the real time).

 

This is not a problem for a single-core app, it will always get the same number, but when it is a multi-core app, each core will reply with their own clock, that might not necessarily match (for example: my laptop when overheating slows down one of the cores first, running it at 3Ghz while the others at 3.2Ghz, the core is probably not aware of this immediately, and might count 200Ghz slower).

 

Some apps handle this badly... I for example found out about this bug when making a game that used physics, the physics engine needed the precision clock to calculate with precision how much to update the physics (the engine instead of updating per frame, updated per time, using classical physics formulas, for example that position = initial position + velocity * time), my game outright crashed when it happened.

There is details about this happening on file writes too, a guy was debugging his server that kept crashing in a particular IBM mainframe running windows, and found out about this bug, because as each processor worked on writing down files, each file had a different timestamp, sometimes the timestamp was up to 4 miliseconds in the future, and this crashed the server.

[TakemeThere 5,834]

Just an FYI to all, there is one TE crash this mod won't stop. Do not hover the NAM disconnector over any TE lot. Found this out the hard way in the last couple of days, multiple times... Seems I've gotten complacent since getting the mod, but that's all on me - still going to vote for this one as mod of the year.

Maybe simmaster07 can take a look at this particular item?

[simmaster07 1,221]

On 1/9/2016 at 1:08 PM, takemethere said:

Just an FYI to all, there is one TE crash this mod won't stop. Do not hover the NAM disconnector over any TE lot. Found this out the hard way in the last couple of days, multiple times... Seems I've gotten complacent since getting the mod, but that's all on me - still going to vote for this one as mod of the year.

Maybe simmaster07 can take a look at this particular item?

It's on my radar.

[jaredh 195]

Just a note...there is a guy over on SC4D trying to reverse engineer the code...you might want to chat with him.

[simmaster07 1,221]

1 hour ago, jaredh said:

Just a note...there is a guy over on SC4D trying to reverse engineer the code...you might want to chat with him.

I saw that thread, and it's an interesting effort. I actually had reverse-engineered small parts of the Windows 640 EXE by using the symbols in the Mac version and identifying code, inheritance and references that were the same in Windows. The thing is that it'd be very illegal for me to share my findings about that here and on SC4Devotion due to the Maxis/EA EULA.

[NCGAIO 562]

22 hours ago, jaredh said:

Just a note...there is a guy over on SC4D trying to reverse engineer the code...you might want to chat with him.

just for clarify

Although the topic thread say "reverse engineering" in fact he suggests discussing exactly the same as here.

It's get to the real use of  proprietary  Maxis objects COM (GZCOM) to load DLLs that modify the execution of game code loaded into memory therefore not trying to change your original code

Although also restricted by the EULA this is much more flexible in the interpretation of legality

see what says the own P. P.

"We Implemented a simple DLL loading and querying interface-system, so anybody Could easily write a DLL provided new objects that the main executable Could easily load and treat like native objects."

Well ... in fact  "could easily write" but  for using ....   better if  you was maxis member.

Reading the document is interesting ....

http://pisa.ucsd.edu/cse125/2006/Papers/Game_Development_in_C++.pdf

 

[Mister Giggles 310]

On 1/22/2016 at 11:06 AM, simmaster07 said:

I saw that thread, and it's an interesting effort. I actually had reverse-engineered small parts of the Windows 640 EXE by using the symbols in the Mac version and identifying code, inheritance and references that were the same in Windows. The thing is that it'd be very illegal for me to share my findings about that here and on SC4Devotion due to the Maxis/EA EULA.

You're already knee deep in illegality, if using that logic. You're altering the game's code during run time. You've also created a system that purposefully breaks functionality designed to protect the integrity of the game's code. Pandora's Box is already open.

I wouldn't worry about it, honestly. While EA technically has a legal interest, unless you're breaking the disc-check mechanisms, I don't see a reason for them to spend the ten minutes necessary to send out a cease and desist. They're too busy being evil.

[matias93 7,535]

I commented this yesterday in the SC4D prop pox thread: maybe a DLL could be used to override the size limit for compressing the prop file into the .SC4 file, thus avoiding the ocassion that allows corrupting of props. This could avoid the ocurrence of prop pox in healthy cities, even when using poxing props. Of course this couldn't repair poxed cities, but it would be a great advance and an almost complete solution to one of the biggest problems in the game.

[Mister Giggles 310]

The size-limit for decompression is a function of the compression scheme used by the game, according to a post in the Prop Pox thread. What would be easier is fixing the error that occurs during decompression, causing Prop Pox.

If you will, it's the difference between cutting out a piece of diseased scapula and removing the whole scapula. Whatever THOSE are.

[LivingInThePast 364]

I can't tell you how promising this mod could be. Besides fixing bugs, I hope modders can find ways to enable the upgradeable City Hall.

On 1/6/2016 at 5:52 AM, T Wrecks said:

I'm wondering what it actually is that prevents transit-enabled lots from being plopped right next to another in the direction of traffic flow, and if there would be a possibility to overcome this limitation. It would open up the way to functional modular railyards, functional modular alleys and parking lots, etc. that would be extremely simple to create for many users with basic lotting/TE'ing knowledge - as opposed to SAM overrides or PED Mall puzzle pieces etc.

Well, functional railyards were supposed to be included with Rush Hour (source: old official SimCity 4 website) but were scrapped for whatever reasons.

[T Wrecks 10,210]

15 hours ago, LivingInThePast said:

I can't tell you how promising this mod could be. Besides fixing bugs, I hope modders can find ways to enable the upgradeable City Hall.

Good idea! Yeah, I second that.

[longhorn 25]

On 1/26/2016 at 6:20 PM, Mister Giggles said:

You're already knee deep in illegality, if using that logic. You're altering the game's code during run time. You've also created a system that purposefully breaks functionality designed to protect the integrity of the game's code. Pandora's Box is already open.

I wouldn't worry about it, honestly. While EA technically has a legal interest, unless you're breaking the disc-check mechanisms, I don't see a reason for them to spend the ten minutes necessary to send out a cease and desist. They're too busy being evil.

I can't imagine they'd be too pissed.  What he's doing has the potential to cause an uptick in sales of a 13 year old game.  If he manages to fix issues and add functionality while still requiring people to buy the original game, EA's getting added value at no cost to them.

[Calvss 27]

I love this fix! Especially since my cities are so tram-heavy. However, I've noticed a compatibility issue with the SC4launcher, for some reason having the DLL installed causes a problem with the autosave feature. Specifically, it gives a "sc4 is not running" error in the log. I suspect this is due to the sc4fix DLL renaming the window to SC4Fix Pre3.

[simmaster07 1,221]

Hey @weekendgamer, thanks for the heads up! I'm pretty busy with finals at the moment, but when I get a chance I'll upload a new version that doesn't change the titlebar to avoid creating these kinds of conflicts.

[Flat Raver 59]

Is this fix compatible with the Extra Cheats DLL?

 

EDIT: I checked it, and it does! It bloody works!

[matias93 7,535]

Indeed, simmaster07 even did a clone of the extra cheats, with even more codes. It's on his uploaded files.

[Rady 94]

Although this thread has been quite for some yearsnow, may I ask a question: does this fix also include the prop pox problem that has been generated by Pegasus' lots? I remember last time I played, and my city got infected, that one of the advises was to not use Pegasus' lots ..?

[matias93 7,535]

The newer version also includes a fix for the Prop Pox, indeed, but there are some instructions on how to make it work.

[rsc204 21,862]

On 11/02/2020 at 10:17 PM, Rady said:

does this fix also include the prop pox problem that has been generated by Pegasus' lots? I remember last time I played, and my city got infected, that one of the advises was to not use Pegasus' lots ..?

Personally, I find this advice to be both generic and terrible in almost equal measure. It grossly overstates the nature of the problem, whilst preventing many users from using a wealth of some of the best coastal and other content around, which is sad really.

Obviously with SC4Fix this may no longer be an issue, but for the record only one file by Pegasus was ever identified as potentially causing problems, PEG-OWW2_BDK_RESOURCE.dat. If you avoid that file and the maybe two or three downloads that require it as a dependency, Prop Pox should never be an issue anyhow. Likewise, a simple bit of modding, removing a couple of the Exemplars from that DAT, is sufficient to prevent the issue.

[Raymond7cn 6,775]

2 hours ago, rsc204 said:

but for the record only one file by Pegasus was ever identified as potentially causing problems, PEG-OWW2_BDK_RESOURCE.dat

Dear Robin, Excuse me for interrupting, May I ask more details about PEG-OWW2_BDK_RESOURCE.dat, Since I downloaded and collected all of PEG's works, I want to make more clearer of it even I haven't use it. Are you saying If some Lots's dependency include this file, Then we'd better don't use them due to Prop Box? Then I'm a little bit confuse about 'removing a couple of the Exemplars from that DAT', Since I thought this issue could be deal with adding something.

I'm sorry to bother you with these questions. Thank you.

Yours Sincerely,

-- Raymond

[Rady 94]

3 hours ago, rsc204 said:

Personally, I find this advice to be both generic and terrible in almost equal measure. It grossly overstates the nature of the problem, whilst preventing many users from using a wealth of some of the best coastal and other content around, which is sad really.

Obviously with SC4Fix this may no longer be an issue, but for the record only one file by Pegasus was ever identified as potentially causing problems, PEG-OWW2_BDK_RESOURCE.dat. If you avoid that file and the maybe two or three downloads that require it as a dependency, Prop Pox should never be an issue anyhow. Likewise, a simple bit of modding, removing a couple of the Exemplars from that DAT, is sufficient to prevent the issue.

Sorry if I might have been misundertood ... as I stopped playing SC4 quite a long time ago, my recent post was just about what I remember briefly from back then regarding the prop pox. And this was that PEGASUS lots (wich by then I used almost completly) seemed to be part of the problem, of course amongst others. 

So it's great to hear that it seems to have been narrowed down to just some files :-)

[twalsh102 1,601]

I'll rehash some of the history of this matter for those that may not be aware of it (and hopefully not reopen some old wounds in doing so).

"Prop Pox" has apparently been around since the early days of modding.  For obvious reasons, there was an extreme lack of information back then on how to properly mod files, probably resulting in many mistakes.  Several early players had reported "disappearing props" over time, but no one could identify what might have caused it.  The problem eventually acquired the name "Prop Pox."  Over time, some people were able to narrow down THEIR occurrence of "Prop Pox" to some undefined file created by Pegasus.  This lead to the terrible advice alluded to by @rsc204 to avoid all Pegasus files (which I imagine probably didn't make Pegasus very happy).

Eventually a member of the BSC Team over at SC4D (bap) conducted a number of experiments that narrowed down the problem to the one specific PEG file mentioned by @rsc204.  bap even isolated the most likely cause being that in this file, Pegasus modified several prop exemplars and changed them from being static props to timed props.  The mistake is that the modified props were left with the same IID, thus overriding the default Maxis Props.  The problem apparently was that timed props required more room to be recorded in the savegame file than static props.  This apparently led to an ever-increasing cascading corruption of the savegame file, causing the missing props.  bap even described a way to fix the problem by either modifying or just removing the offending props from this file. 

The greatest problem was that if you ever had the unmodified Pegasus file in your Plugins folder, even if it was never used, you were subject to getting the Prop Pox eventually.  The fix described by bap was only useful if you used it BEFORE placing the offending Pegasus file in your Plugins folder.  bap then published his findings.  I won't get into the virtual war this created between Pegasus and the BSC team over at SC4D because Pegasus apparently refused to accept the possibility that one of his files was the culprit, claiming the reports of Prop Pox predated his release of the mentioned file.  The problem was further exacerbated by people either not completely reading or misunderstanding bap's research, causing further calls to avoid ALL Pegasus products.  The truth is that other than this one file, almost all of Pegasus' work was brilliant.  This problem has never been found in ANY other Pegasus file (and I can guarantee that because of the furor created by this finding, EVERY Pegasus file has been examined under a microscope).  No one has ever disputed that there probably WERE files available on some of the very early exchanges that contained the same problem (causing the early reports), but none have ever been identified (probably because they were updated at some point or just disappeared from the exchanges).

Along came the brilliant programmer @simmaster07 and his SC4Fix.dll.  The original version fixed a well known problem with Maxis programming that caused CTDs.  Then he discovered that he could further modify the ,dll to deal with the Prop Pox issue, prevent it from occurring, and in most (if not all) cases actually reverse the effects of the Pox.  Which is where we are today.

[xxdita 1,097]

Just out of curiosity, has the one file that has been determined to be the cause of prop pox been corrected yet? Or is there some sort of warning posted on the download page, with a link to SC4Fix? 

This is a fairly serious bug that does not have to ever be a problem for any player again. 

[simmaster07 1,221]

I don't think a patched version of that plugin file hasn't been released. I also believe there are other plugins with the same flaw that haven't been positively identified yet - I remember players reporting that they'd gotten prop pox even when they weren't using that one Pegasus file.