Would combining this with your earlier bugfixes (and maybe other folks' stuff) be in the future?
Someday, I'd love to see a patch that simply cleaned up as many bugs as possible without any frills, that might be generally accepted by our community as a new standard baseline for all .txt and .exe mods to start from.
Out of curiosity, what % of the code is dissassembled ?
https://github.com/b-casey/OpenSMACX
Your readme says you used Visual Studio 2017. I do not see any .sln file or project files in the GIT repository. That means there's no way to replicate your build process.I'm using default settings for a dll. You should be able to copy all source files into a default dll project and they'll compile. While I do have some different settings for my own project, they are purely there to aid with validating code (turning off optimizations, inline functions). I have tested this process and didn't run into any issues. If you do, let me know and I'll look into resolving them. Eventually I'll test compiling source with gcc and make any fix ups as needed. But for now at least, having project files are superfluous.
I took a look on github, it seems files are incomplete. I checked 2 .h files.A lot of the interface code are struct place holders that I'll add to over time. The engine interface code isn't a priority for me except when needed to fix bugs. I have completely finished some of the low level classes related to memory/file IO and text but ones like the button and window classes will be slowly added to as needed. The reason for adding them all in was because I wanted to completely finish the function that parses alpha/x and faction files in. This required setting text for a couple buttons. Bulk of code for this release is in alpha.h/cpp.
I do wonder about different versions of Windows SDK biting you in the ass.I did run into a similar issue with redirecting mem_get() and env_open() between current Windows SDK and the one that SMACX is compiled with. There was an incompatibility that would cause the game to crash on start up. I tracked it down to free() in section of code I hadn't decompiled. That's why I have two additional "_old" versions of those functions inside general.cpp. The classes I've fully decompiled, including destruction, use the non-old versions. I then redirect the exe to call the old version that does a direct call to old SDK version of _fopen and malloc.
It's unclear if this code is supposed to be a pure vanilla reverse engineering project, or something that could be ported to SDL itself.
A project to decompile SMAC/X to C++ with the long term goal of creating a full open source clone.
I'm unsure why glTF specifically is important,
other than to be especially bleeding edge in context to a 20 year old game.
Godot is certainly not the only implementation of glTF 2.0,
The idea of re-implementing the whole game using their Node system seems to me like creating something from scratch using basic game logic derived from reverse engineering, instead of repackaging the reverse engineer code into a cross-platform graphics/audio/input library.
I also appreciate your desire to reverse engineer a proprietary 3D model format.
The idea of using Godot as the basis of a source port is frankly laughable,
If you have an actual source port of the game logic, why would you be hacking around with the binary?
When I speak, I'm not just talking out of my ass about the latest meme tech,
Trying to manage manually patching the function redirects to the dll has started to become cumbersome now that I'm redirecting over 250 functions. I put together a python script that will handle all the patching after imports are added in. That process is also automated (C++ code), although I'll have to modify the program slightly to take input parameters rather than hardcoded import list.
Just implementing binary compatibility with the original game assets is much faster and avoids all the licensing problems.
importing the art assets some way or another would become unavoidable.
3. Gaians gain +1 nutrient in forest squares.
I'm very happy with this project, Scient, largely in the hope of getting more features. Please, keep us updated regularly. I don't really understand it, though. What do we have to learn to actually edit the decompiled code?
There are a few things I'd like to incorporate in my next mod. Will list them here in order to talk about feasibility.
1. Support in excess of social engineering depletes energy rather than minerals.
2. All formers deplete 1 mineral from home base per turn, independently of social engineering. (One of Yitzi's ideas before he disappeared.)
3. Gaians gain +1 nutrient in forest squares.This would be in crop_yield() which is used to calculate nutrients. There is already logic branch for tree tiles related to Hybrid Forest. So adding in an additional check for specific faction would be easy.
Another thought: scripting in additional starting units, so factions begin with extra colony pods and free formers. This is currently possible with txt but each unit added in this way takes up limited faction customization slots.
Without good terrain, farms are essential because bases provide 0-0-0 resources as a default.
#RESOURCEINFO
Ocean Square, 1, 0, 0, 0,
Base Square, 2, 1, 1, 0,I understand you plenty , and it would be a shame you stop for my fault : the proyect is, and always will be open source. You has no wasted 2 years.
As you can see on the post I created, I did no write anything about a bounty.
Some lazy Saturday morning reading led me to a potential bug fix here:
https://github.com/b-casey/OpenSMACX/blob/defe36bdb1604c738f9cdf842ce1c8caabc456f1/src/faction.cpp#L222
Circumstantial evidence suggests that this Psi Gate prereq check in the climactic_battle function is legacy code left over from when Psi Gates apparently had some role in a Transcendence Victory. I wonder if it makes the AI unduly agitated too early at the arbitrary tech of Matter Transmission?
See this thread on reddit regarding the evidence: https://old.reddit.com/r/alphacentauri/comments/iua8v2/miriams_psiicide_put_in_another_light/
https://github.com/b-casey/OpenSMACX/blob/d7cf7140dfa5e24cd3462f7d37b0b65c2c591159/src/game.cpp#L106 (https://github.com/b-casey/OpenSMACX/blob/d7cf7140dfa5e24cd3462f7d37b0b65c2c591159/src/game.cpp#L106)
Are turns 1-indexed? This line leads me to believe they are, as does the fact that games begin in MY 2101 even though alphax and the opening narration suggests 2100. I want to clarify something on the wiki if so.
Honestly, voxel classes (Caviar/CaviarData) aren't that complex in the grand scheme of things (from my cursory look through functions). It won't be too difficult to break them down."