araxestroy

Soliloquy "There'll be a Release 10a," he said. "I promise it'll be out soon," he said. "Release 11 will have modding support and a new save file format," he said. Okay, I messed up on all of those. But it's because we kept working on a bunch of other, really REALLY cool things. Pun entirely intended. We've spent the last five months reverse engineering more and more of the game, learning how it interacts internally, figuring out how it draws every individual component separately, and decompiling and reimplementing as much of it as we can. The end result is Release 11, which brings a bunch of new quality of life features and bug fixes as well as some goodies to add what we think are a sort of "vanilla plus" set of optional game enhancements. These are all meant to feel within the original goal of SimCity 2000's design while not necessarily being something Maxis had the time or processing power to implement in 1996. The most visible one, as proudly displayed in the release banner, is the weather effects. Release 11 has a significant reimplementation of the rendering engine, including the 256-colour palette shuffling parts usually handled by the kernel-mode side of Windows GDI, and because of that we've managed to implement a bunch of different effects based on weather and seasons in-game. Trees partially shift colour in autumn and winter, snowy weather causes the terrain, grass, and trees to be lightly coated with fluffy white crystals, and blizzards amp up the blanketing and affect lakes, rivers, and bays. This can, of course, be turned off in the settings if you want your city to appear as it did in previous releases, but we think it adds a neat bit of extra Maxis-like charm to the game. Furthermore, a number of new core features have been added to sc2kfix. Most notably, a better multithreaded sound engine has been implemented using SDL3 and libsndfile, since we already have those in the distribution for FluidSynth, and FluidSynth itself is now the default MIDI renderer. If you don't have a SoundFont handy, don't worry; FluidSynth will default to using the built-in Windows GM soundfont. These together allowed us to add another oft-requested quality of life feature: volume controls. You can now change the volume levels of sounds, music, and overall playback volume in the sc2kfix settings dialog. There's a lot more in this release, so check out the changelog below for full details. I promise Release 11a won't be nearly as far away as Release 11 was, since it'll be much smaller in scope. External Links Download from GitHub: GitHub - Release 11 User Guide: sc2kfix.net - User Guide Changelog This is a major release. Upgrading from Release 10 to Release 11 is highly recommended. The following changes have been made since Release 11: Gameplay Features/Fixes The real-time renderer has been rewritten and enhanced with support for seasonal and weather effects. Different tree shading for different seasons has been implemented, as well as tileset-wide effects for snow and blizzard weather conditions. This is likely to be expanded upon and tweaked in Release 11a. (@af-az, @araxestroy) A new sound engine has been implemented allowing for manual control of volume for sound effects and music. (@araxestroy, @af-az) FluidSynth is now the default music output device for players upgrading from previous versions or installing for the first time. New users will find that their default SoundFont is set to the same one that Windows itself uses, gm.dls. (@araxestroy) Keybindings can be configured from the sc2kfix settings menu to remap game actions. (@af-az) Several sprites from the main tileset have been adjusted to fix pixel alignment issues in the original files. (@af-az) Dark mode has been added for the underground view to save your retinas. (@af-az) Higher quality bulldozer and plop sounds have been restored. (@araxestroy) Naval base placement is now more accurate to the DOS version. The generation of army bases and missile silo fields have also been adjusted. (@af-az) City infrastructure valuation has been fixed to use the correct values for power plants and arcologies. (@araxestroy) Arcologies are no longer tiny in the query dialog. (@af-az) Calculation of the city center has been fixed, and the city center will now display in the map dialog. (@af-az) The budget toolbar button will no longer reset your auto-budget settings. (@af-az) Scenario icons no longer have out-of-place white pixels. (@af-az) Plugin Changes The settings dialog has been rewritten as a tabbed, multi-page dialog, and settings are now stored on-disk as JSON. Existing sc2kfix.ini files will be automatically converted to the new settings.json format, and any missing defaults added since will be filled in. (@araxestroy, @af-az) The Kuroko scripting language has been replaced with Lua 5.5. A partial interaction library has been embedded in sc2kfix. You can play with it through the run lua console command, which will drop you into the Lua REPL. (@araxestroy) The console CLI has been rewritten with Junos-style autocomplete. This is still a work-in-progress and will be enhanced through the Release 11a development cycle and beyond. (@araxestroy) Many enhancements and bug fixes to SCURK have been implemented. Tileset conversion from other platforms has been fully implemented, palette/animation handling has been enhanced, and several new functions have been added to the editor. (@af-az) The placement preview now looks more like the DOS and Macintosh version, as originally intended. (@af-az) A command-line option for enabling experimental code has been added. Use at your own risk. (@araxestroy) Several additional command-line options have been added; see the plugin user guide for more info. (@araxestroy) A sprite browser has been added to the debug menu for testing purposes. (@af-az) Sprite animations now play properly in the query dialog. (@af-az) The console now uses VT100 colour codes for prettier output, and some internal helper functions have been added to better support it. (@araxestroy) The console will prefer using the parent console if launched from the command-line on Linux systems. (@araxestroy) Internal Changes sc2kfix now uses SDL3 and libsndfile natively instead of just as a side effect of loading FluidSynth. As a result, all three are part of the official sc2kfix binary distribution. (@araxestroy) Several parts of the simulation engine have been reimplemented in-library. Some of these are live by default, whereas others are opt-in experiments. (@araxestroy, @af-az) Lots of helper/utility functions from the game engine have been reimplemented in-library for optimization. (@af-az, @araxestroy) Lots of classes have been updated to be more accurate based on reverse engineering work. (@af-az, @araxestroy) Enums and corresponding strings have been added for sprite data. (@af-az) sc2kfix will attempt to detect enforced system-wide security lockdown features that would cause the game to crash and alert the user to the issue. (@araxestroy) The update checker has been made more efficient. (@af-az) The mechanism for embedding tileset overrides has been adjusted. (@araxestroy) The exception unwinder has been made less eager to blame stack frame corruption. (@araxestroy) Several new utility functions have been added. (@araxestroy, @af-az) A better tooltip manager has been implemented for better memory usage and performance. (@af-az) Some issues in the resource files have been fixed. (@af-az, @araxestroy)

If you're already using a virtual synthesizer hooked up to the Windows MIDI sequencer through a MIDI mapper you don't need to use FluidSynth. FluidSynth might be marginally faster at loading MIDIs in some circumstances, but not enough to matter, and since the sc2kfix music engine is multithreaded, any delays cause by the native Windows MIDI sequencer don't affect gameplay. It's more useful for people without a setup like that and for people running on Linux with Wine, as the Windows build of FluidSynth works excellently in Wine, which doesn't have a very good native MIDI sequencer (or, frankly, one that seems to work properly out of the box worth a damn). It's also fun in case you want to quickly see what the game's soundtrack sounds like with different soundfonts. I mostly play with the Sim-Melody CD arrangement in MP3 form these days for the crisp jazz action.

it's here Soliloquy Yeah, I know, I said Release 10 would be out three months ago. I also said six months ago that Release 10 would have a full modding framework, but that's pushed out to Release 11, because I'm terrible at this. Instead, here's a Christmas present! Going forward, our big focus will be a game reimplementation, but additional modding work will be done on the original game to make sure that as many possible advancements we come up with in the realm of SimCity 2000 modding can be done on the original game in the meantime. That means the SC2X file format, while originally slated for Release 10, is going to be a Release 11 or Release 12 job. The format has changed a bunch while I've been working on it and integrating it into a game from 30 years ago without massively inflating the size of the sc2kfix DLL is going to be a challenge. Many of the more experimental native code modding hooks as well as the Kuroko implementation are being pushed back to Release 11, because they're extremely unstable and we want to get something out before the end of the year. So, what's in Release 10? Well, it's a rollup of all the various things we've been working on since Release 9. A large number of changes were done in the Release 9 patch cycle through Release 9d, with Release 10 being a mix of further improvements and a stable marker that we've fixed a bunch of stuff based on our reverse engineering work. One of the major accomplishments is the series of critical fixes to WinSCURK by @af-az, which was accomplished by a herculean reverse engineering effort of the pre-MFC Borland C++ framework used in WinSCURK's creation, resulting in fixes allowing the program to run properly on Windows 11. Similar to the issue where GTA: San Andreas is buggier on Windows 11, WinSCURK makes certain assumptions about the Windows 11 ABI that causes it to behave incorrectly, and @af-az's work fixes this. We believe this marks the squashing of all known major bugs in the game; now it's time to find the unknown ones through further reverse engineering. In addition, we have added several new features to the game. The music engine has been enhanced again with support for FluidSynth, a scenario status screen has been added to make scenario progress more clear, various enhancements to the internals of the plugin have been made, and a prototype modding framework for writing native code mods (DLLs) for the game has been implemented. A small example mod has been added to the repository that outlines how mods work, but full documentation has yet to be written. Work continues on an enhanced scripting system for lightweight modding, which I expect will be more reasonably finished along with the stable mod API/ABI for Release 11. Whenever that is. Happy holidays, everyone, and may you and your Sims have a happy new year! External Links Download from GitHub: GitHub - Release 10 User Guide: sc2kfix.net: User Guide Changelog Gameplay Features/Fixes The new music engine has been enhanced with first-class support for FluidSynth! Dropping libfluidsynth-3.dll from the latest 32-bit release of FluidSynth (2.4.7-winXP) and its requisite libraries into the same folder as the sc2kfix plugin will enable sc2kfix to load FluidSynth as a module and use it in the music engine. You can then select a SoundFont in the settings dialog and FluidSynth will be directed to that SoundFont for MIDI playback. (@araxestroy) SCURK has been fixed on Windows 11 24H2 and newer. Pick-and-place should now work as expected. This was caused by a mix of legal ABI changes (the Windows system call ABI can change at any time) and incorrect usage of the API on Maxis' and Borland's part, and was resolved after a period of reverse engineering of the Borland C++ Windows abstraction layer. (@af-az) MIDI files and MP3 files can now be manually assigned for playback for each music track. If you want to play different songs from your collection of MIDIs or MP3s in SimCity 2000, you can now do so. We recommend keeping the mood the same, though, so you don't end up with an upbeat ska track playing when your city is being invaded by alien monsters from the year 2000. (@af-az) Preliminary native code modding has been added to the game. This is experimental work and you should not play with this unless you know what you are doing. Documentation has yet to be written as the native code interface is still evolving rapidly. If you want to play with this, the sc2kfix Discord server is the best place to chat about it. (@araxestroy) sc2kfix will now automatically fix file associations for .sc2 and .scn files in the registry. This restores the last missing feature from the installer, allowing saved game and scenario files to be launched directly from Explorer once again. (@araxestroy) A bug in the query dialog display of arcology microsim statistics has been fixed. (@af-az) A bug in the query dialog display of transit tiles on the map edge has been fixed. (@af-az) A bug in the save city dialog that can cause scenario files to be overwritten has been fixed. (@af-az) Army base growth has been tweaked to be more accurate to the DOS and Mac versions. (@af-az) Plugin Changes The floating status dialog has been reimplemented to be more accurate to the DOS and Mac versions. (@af-az) The crash dialog and associated stack trace logging has been massively improved. This allows us to more accurately track down crash reasons with significantly less effort than in previous releases. (@araxestroy) The CSimCityApp::BuildSubFrames function (formerly GameDoIdleUpkeep) has been reimplemented in-library. (@af-az) The animation hooks have been rewritten to improve performance. (@af-az) The advanced query dialog now shows tile sprites like the base query dialog. (@af-az) The pipe tool now properly refreshes at max zoom. (@araxestroy) A setting has been added to automatically queue up a new song after one finishes instead of needing an event to occur. (@af-az) A crash related to Air Force base growth has been fixed. (@af-az) Various work has been done to fix bugs in the Interactive Demo version of the game. (@af-az) The debug-related commands in the console have been enhanced to be more verbose. (@araxestroy) The prototype console scripting system has been reimplemented. (@araxestroy) A bug preventing the advanced query dialog from working properly on some system has been fixed. (@af-az) A bug in the music engine has been fixed allowing track 18 to play properly. (@araxestroy) The advanced query dialog has been re-enabled by default. (@araxestroy) Hooks for the Smacker codec library will not be loaded on the (unsupported) 1995 CD Collection version of the game. (@araxestroy) A few console commands have been cleaned up to provide prettier output. (@araxestroy) Separate log files will be created for SimCity 2000 and SCURK so as to not clobber a single log file if you start up SCURK while SimCity 2000 is running. (@af-az) Internal Changes Further reconstruction of the simulation loop has been done in-plugin to improve performance and enable reimplementation and modding. (@af-az, @araxestroy) The MFC 3.x helper file has been separated out and included by default in the native code modding framework. (@af-az, @araxestroy) Helper files have been added for SCURK and the idiosyncratic Borland C++ class system it uses. (@af-az) Several files have been reorganized for structural reasons. The monolith previously known as the mischook file has been split up dramatically into multiple files to make tracking changes easier. Call your cousin Vinnie if you have issues with this. (@af-az, @araxestroy) Further demystification of the game's sprite format has been done and exposed to the plugin API. (@af-az) The console window is now allocated earlier in the plugin startup process to ensure critical logging can be provided on the console. (@araxestroy) The system for expanding AFX_MSGMAPs has been rewritten to make the process more safe. (@araxestroy) Cheats and the Maxis debug menu have been moved to their own file. (@araxestroy) More detailed information about the running system is logged on startup for bug reporting. (@araxestroy) Some of the earliest code has been rewritten to be more sane and less hacky. (@af-az, @araxestroy) The default main branch build (Release) does not include Kuroko, and the alternate build (ReleaseKuroko) does. (@araxestroy)

Hi everyone! It's been a while since I've made a new post here, mostly because we've just been heads down on working on the plugin and the reverse engineering process. Today we've posted Release 9d, which builds on the bulk of the reverse engineering and extensibility framework design to fix about half a dozen bugs in the game as well as restore some content (some of which comes from different versions of the game in the form of easter eggs!), improve performance, improve crash handling, and improve save game resilience. AF has reimplemented a good chunk of the simulation engine inside sc2kfix so we can more easily hook into it for future development as well as future third-party mods to work with. In doing so, a handful of bugs in the original game have been squashed. A couple small bugs on the sc2kfix side have been fixed as well, and the ground work has been laid for more development on the modding side. The floating status window has been rewritten to more accurately represent the DOS/Mac version -- there are still a few small occasional cosmetic bugs with it that we're working on, but it looks nicer than my first go at it and is more extensible. (the word of the day is: extensible. extensible. extensible.) Debugging is another big focus of this release. I've reworked the crash handler and its stack unwinding feature to give us much more useful information in the even that SimCity 2000 crashes, including detection of likely stack corruption. The in-game debug menu has been expanded slightly to make testing suspected cases of growth weirdness a bit easier. Additionally, and more usefully for most users, sc2kfix can now detect certain types of save file corruption and attempt to automatically resurrect dead save files when loading them. I'll try to post more often here, since we're definitely still working on the project. It's just that not much has been particularly interesting to post about. In the meantime, you can grab Release 9d here: https://github.com/sc2kfix/sc2kfix/releases/tag/r9d Happy mayoring!

All good ideas are stolen, so I'm stealing Quake's idea of using a renamed .zip as .pk3 with just a directory structure of game data in it for what will probably become the final format for SC2X saves: Now the JSON output is a lot more sane since it's just the non-map data and saves will be compressed. SimCity 2000 saves already had some compression in them but it's a) a really naive run-length encoding system which b) means there's no dictionary-based compression shared between binary segments, so even after expanding the whole MISC segment out to JSON and nearly tripling its size, the final converted save is about half the size of the original. This will be incredibly useful because we're already discussing how it'll probably be possible to increase city sizes in OC2K. The size of this screenshot PNG is larger than the SC2X file.

Discord server is up: https://sc2kfix.net/discord -- Cori, if you and/or the other admins would prefer me not to have a link to it let me know and I'll edit it out.

Rad, thanks. I'm on a warning-fixing spree but I'll leave military.cpp alone. Working on setting up a Discord server. I already had one spitting spitting out GitHub notifications so I'd know if people opened issues or PRs, so I just need to add some roles and some more channels and stuff and it'll be good to go.

Oh, interesting. I'll put a card in Trello to look into that. Astonishingly stupid game bug I found and fixed: The DOS and Mac versions have a "Maxis Presents" screen that displays after the intro video and before the title screen, but it doesn't show up in the Windows version. It's in the game files, too, so why doesn't it show? Well, two reasons: One, the GameDoIdleUpkeep state after the intro videos show (or fail to show) is directly set to the one for the title screen, not the one for the Maxis Presents screen. And two, they misspelled the filename for the friggin BMP. It should be "presents.bmp", but they accidentally spelled it "presnts.bmp". I genuinely believe that at some point in development, they misspelled the filename on disk, and that was causing it to hit AfxAbort and terminate the game, so they just made the game skip that screen entirely instead of noticing that they had made a typo.

Unrelated to the above: Since there's about a half dozen people doing various SimCity 2000 reverse engineering work and development bits here, I would not be opposed to setting up a Discord server or an IRC channel for more real-time collaboration and general support and discussion. I already have a Discord going that just pings me for new issues and pull requests on GitHub, so if folks here are interested in using it for general discussion I'm more than happy to open it up. Or to set up an IRC channel if people prefer a more 90s approach. I started this project because I wanted to play the 30 year old city builder I grew up with on my modern gaming machine, and now it's gone miles beyond where I thought it would. It's been pretty cool to have finally created an open source project that people are interested in, for sure. Regardless of any other methods of communication this will still be the main thread for ingesting interest and growing the general community. Simtropolis is well known as the one and greatest SimCity community out on the net, and it's where I got my start in modding SC4 and from there where I knew where people would be interested in this project. So even if we have a separate place to talk about things related to the sc2kfix project and SimCity 2000 modding, I'll always be happy to post new and cool things here, because this website is the home of the greater SimCity community, and it's where work on this game should always be announced and discussed.

I'm still working on documentation for the modding framework as I keep expanding it, and one thing I really need to do is reimplement the load/save stuff so we can use the SC2X save format, which will also require implementing new load/save dialogs of course... but in the meantime, here's a post transferred from the devlog on SA. If anyone here happens to be an SA goon, I have a much more stream-of-consciousness and occasionally profanity-laden devlog in the Post My Favorites subforum, and you can also see my grumblings in the YOSPOS "idiot spare time projects" thread, though all the collaborative dev work happens here. This is a lazy post because it's mostly a function listing, but hopefully for the programmingly-inclined it makes some sense. There are some things I haven't written documentation for, which revolve around C++ class imports, but for the most part this is the structure of how you write a mod in C/C++ for SimCity 2000 using the sc2kfix modding framework. It will be expanded constantly as I work on new bits of modding but as it stands right now this is the general way that one would write a mod and compile it so that the sc2kfix mod loader can tell the Windows API to load a mod DLL and then run through the exported hook callbacks and load them into the hook lists. Not included in this: C++ class exports from the sc2kfix core DLL or Kuroko-based mods, which are something I need to sit down and really think about. I still like the idea of having a baked in Python dialect for modding, but also I am a) not a Python guy and b) constantly reconsidering how to work what's functionally a bytecode virtual machine into the crap seen here. My first thought was to have each Kuroko mod be a separate thread waiting on messages being posted to it, but that seems like it might be the wrong way to do things and it might be more sensible for each Kuroko mod to have a startup script that's run in a global context to initialize data, and then each hook gets re-uploaded into the global context before each corresponding hook call. That might be a problem though with how the Kuroko VM handles its instancing, though. A lot of how this C/C++ interface works out is a recreation from memory of how we did things for FLHook back in the day. FLHook was/is a server-side hooking infrastructure for the 2003 game and quasi magnum opus of notable scam artist Chris Roberts. I spent way too much of my life working on that project, but at least it resulted in me being able to do this, I guess. So here's a template for a very simple mod for SimCity 2000 using the sc2kfix framework. All it does is say "happy new year" and tell you how many days it's been since the founding of the city, but hopefully the comments for it are useful enough to explain how the whole modding framework works. // sc2kfix/testmod dllmain.cpp: test/template mod with inline documentation // (c) 2025 sc2kfix project (https://sc2kfix.net) - released under the MIT license // These two lines are mandatory for sc2kfix mods. The first one ensures that all Windows API // calls use the ANSI calls instead of the Unicode calls, which aligns with the way that SimCity // 2000 was compiled. It should be the first preprocessor line of each source file in each mod. // The second is required in **EXACTLY** one file of each mod and no more, and lets sc2k_1996.h // define all of its GAMECALLs and GAMEOFFs so the mod can interact with the game engine in the // same way that the sc2kfix core does. #undef UNICODE #define GAMEOFF_IMPL // Include files go here. The standard order used in the sc2kfix project is to have bracketed C // header files first, then any bracketed C++ header files, and then quoted header files. #include <windows.h> #include "../sc2kfix.h" #include "../../include/sc2k_1996.h" // The stModHooks array of structs define each hook that the mod exports. Each hook is defined // with a string of its full name followed by a signed integer of its priority level. Lower // priorities are called first, so eg. a mod that exports Hook_OnNewCity_After with a priority // of 0 will be called after a mod that exports Hook_OnNewCity_After with a priority of -1 and // before a mod that exports Hook_OnNewCity_After with a priority of 1. sc2kfix_mod_hook_t stModHooks[] = { { "Hook_SimulationProcessTickDaySwitch_Before", 0 }, { "Hook_SimulationProcessTickDaySwitch_After", 0 } }; // The stModInfo structure tells the sc2kfix mod loader about the mod and how to load it. It // contains the version info for the mod itself as well as what version of sc2kfix it requires, as // well as some basic textual descriptions of the mod and info about the stModHooks struct so that // sc2kfix can load the mod's exported hooks. sc2kfix_mod_info_t stModInfo = { /* .iModInfoVersion = */ 1, /* .iModVersionMajor = */ 0, /* .iModVersionMinor = */ 1, /* .iModVersionPatch = */ 2, /* .iMinimumVersionMajor = */ 0, /* .iMinimumVersionMinor = */ 10, /* .iMinimumVersionPatch = */ 0, /* .szModName = */ "Test Native Code Mod", /* .szModShortName = */ "testmod", /* .szModAuthor = */ "sc2kfix Project", /* .szModDescription = */ "A test mod to demonstrate sc2kfix native code mod loading, linking against DLL exports from sc2kfix, and manipulating game data from native code.", /* .iHookCount = */ HOOKS_COUNT(stModHooks), /* .pstHooks = */ stModHooks }; // sc2kfix looks for the HookCb_GetModInfo function when loading each native code mod. You should // never need to do anything in this function other than return a pointer to the stModInfo struct, // as the entire purpose of this function is to initially validate that the DLL that sc2kfix is // loading is actually a legitimate sc2kfix mod. HOOKCB sc2kfix_mod_info_t* HookCb_GetModInfo(void) { return &stModInfo; } // The DllMain function in each hook should be used sparingly and follow the best practices // conventions of the Windows API documentation for DLL entry points, as the DllMain function // is executed while under the global loader lock. See the following link for details: // https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices BOOL APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID lpReserved) { switch (reason) { case DLL_PROCESS_ATTACH: ConsoleLog(LOG_INFO, "MODS: testmod says hello!\n"); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: ConsoleLog(LOG_INFO, "MODS: testmod says goodbye!\n"); break; } return TRUE; } // All game hooks exported from mods are declared using the HOOKCB macro, which expands to // extern "C" __declspec(dllexport). This makes sure that there's no C++ name mangling and imports // on the sc2kfix side are similarly simple. // // This is a "before" hook, and is called when sc2kfix intercepts a part of SimCity 2000's game // engine, and before it lets the engine (or, depending on the hook, a recreation thereof) execute // its original code. Many "before" hooks have a corresponding "after" hook that runs after the // engine completes its designated task that the hook is related to, but before the calling // function in the engine is returned to. HOOKCB void Hook_SimulationProcessTickDaySwitch_Before(void) { // dwCityDays is a game engine variable declared and defined as a C++ reference variable. // Using reference variables lets sc2kfix developers and modders operate on SimCity 2000 game // engine state as if their own code is part of the game engine. Since sc2kfix hooks are // called into from the main game engine thread, this is safe to do from native code without // any multithreading-aware locking or mutex mechanism. if (dwCityDays % 300 == 0) ConsoleLog(LOG_NOTICE, ":toot: Happy new year!\n"); } // This is an example of an "after" hook. sc2kfix intercepts the end of the game engine's // SimulationProcessTick function and calls the Hook_SimulationProcessTickDaySwitch_After exports // from each mod before returning to the calling function (in this case, the default case of the // GameDoIdleUpkeep function). HOOKCB void Hook_SimulationProcessTickDaySwitch_After(void) { ConsoleLog(LOG_NOTICE, "Today was day %d in the glorious history of %s.\n", dwCityDays + 1, *pszCityName); }

Oh, that's neat. I had a feeling it was doable but I have no idea where my VS2005 discs are. It might be worth maintaining a branch of r9_patches for older systems, since everything from Release 10 onwards is going to probably end up with a lot of modular DLL-based components and will use the (still not actually implemented, but on the to-do list) SC2X save format by default if mods are enabled, which at the very least requires the json.hpp module.

The modding framework is coming along nicely on the main development tree. There's a mod loader for loading native code DLLs and parsing what hooks they need access to, and an example mod that I will continue to expand as I implement more modding hooks. The current test mod registers itself to Hook_SimulationProcessTickDaySwitch_Before and posts a happy new year message to the log on every in-game January 1st, which is enough to be sure the hook system and game state manipulation both work. I'm aiming to make it easy to add new ones as reverse engineering proceeds, and hopefully within the next week or so I'll have been able to add hooks for various important simulation engine calls. Each engine hook will have a Before and After hook, with some of them being able to just cancel out the original game effects if needed. Once I get all that sorted out, the next big thing to do is bring in the code for SC2X save files, make sure it works properly for all vanilla .SC2 saves, and extend it to the modding framework. The extended save file format is going to be key to making sure that persistent gameplay mods are actually persistent. Even something as simple as new ordinances will need to use the SC2X save format, because there's no way in the vanilla .SC2 save format to be able to have ordinances added by mods that are arbitrarily compatible with each other. Kuroko modding is going on the backburner a bit. It's going to need a bunch of time spent to make sure that threading works the way I want it to, as well as coming up with a way to synchronize threads nicely so that a Kuroko thread can temporarily take over the execution timeslice of the SC2K game thread. Also making sure that the REPL doesn't clobber loaded mod threads. As it is it's easier to do the work I want to do with native code, and it would be kind of fun to do eg. Rust bindings for sc2kfix modding. I'd like to get Kuroko modding working fully for Release 10, though, so I expect that Release 10 as a final product won't be out until late May, maybe June. I want it working exceptionally well with multiple fully functional mods available in the default install and mod templates for all supported languages before I call it good to go. Release 11 will probably rework the scenario system significantly. I'd love to be able to get the rendering engine reverse engineered by then as well, because I have a vague idea of how to use the existing in-memory map system to be able to swap out tilesets on the fly during the rendering process. The hard part is figuring out exactly how tile rendering works. It's been requested by about a dozen people now that it would be really cool to implement farms etc. and it would absolutely tickle me pink to do that. I have a rough idea of how to do it based on a few unused bits in the map structures, it's just going to be complicated to figure out exactly where we can inject code to do the detours we need to for the rendering. My past life as a Freelancer modding wizard has come back with a vengeance, apparently. Cannon, if you're reading this by some chance: Hope you're doing well, buddy. Glad we both escaped that nightmare.

Thanks to some bug reports and a couple dozen back and forths with some different folks in PMs, I've fixed a pretty gnarly bug (mostly) and released Release 9c with some additional fixes that have accumulated over the last week and change. Changelog: Fixed an issue on certain Windows 10 systems where loading the advanced query dialog would cause the game to crash on startup. Fixed a SimCity 2000 bug where the simulation will would enter a broken state when hitting "cancel" on the exit dialog. Fixed an issue where font initialization was violating recommended practices for code in DllMain, potentially causing a deadlock when loading the game. The crash handler now looks up symbols in modules when unwinding the stack. A -debugall command-line argument has been added to turn all debugging on when the game is launched with it.

I have experimentally fixed the bizarre crash bug for at least two people, so once I get a response from the third person who's reported it I will start packing up Release 9c and go back to working on Release 10. It's been almost a week since I last poked at the main branch so hopefully I'll remember what I was working on. Oh right, it was the run command clobbering the REPL. Crap. Now I need to remember how I was going to fix that.

I found what looks like about 80% complete leftovers for an autosave system. I don't recall any version of SimCity 2000 ever having an autosave system. The more time I spend digging through this game's guts the more it confounds me.