It feels magnific to me. I think this could really be holy grail to SMAC(X), just like OpenXcom was to X-COM.
Funny you should say that. When I was first starting out the project, I did use OpenXcom as a reference guide. Great project. I'm hoping this will be exactly that for SMAC/X.
Interesting, I should totally give it a spin when I have some time. Would love to help with bug-testing.
Definitely! I've been pretty meticulous about running the decompiled code through multiple regression tests (even found some bugs in original code this way). While working on it, I compare original compiled assembly to my decompiled compiled assembly in dll to ensure everything lines up. However, there have been 1-2 things that slipped past me that I only noticed later on. Granted, these were missed pretty early on and I've since altered my testing procedure to catch issues like the ones I missed. Eventually once the project is further along, I'll probably do an audit of all existing code base looking for regressions.
But having more folks besides myself testing it would be great. Best way to track down issues and improve the process. The whole reason I went with a dll redirect is so that players could get instant benefit versus waiting a million years for a useable exe. I would like to start populating GitHub issues section to track bugs/fixes outside of implementing existing ones from my unofficial patch (and other's patches).
Retool strictness ability? I remember Spartans didn't pay extra for prototypes, is there something more to it?
Spartans have FREEPROTO faction flag set. In the vanilla game, this flag is only used in two places. One, to bypass alpha/x.txt
prototype cost value and the other to prevent the faction from
building Skunkworks. Skunkworks has an
undocumented functionality of giving the base 'free in category' retooling (switch between facility to another facility, or unit to another unit doesn't cost anything). My unofficial patch essentially added an additional check if faction has FREEPROTO flag set and the faction has Skunkworks prerequisite tech ("Advanced Subatomic Theory"), they would also get this undocumented ability. Since it seems like the idea behind this flag is to give the faction (Spartans) essentially a free Skunkworks. I had forgotten all this so I had to refresh my memory on the rationale behind it. There is a thread discussing it more
here. I'm going to re-implement it inside code with note and detailed explanation in OpenSMACX README. This is one of the less cut and dry issues but does seem like an oversight. In a similar vein to
Sealurks getting a movement penalty in sea fungus. Then again, SMACX code base had a lot of more glaring oversights/bugs compared to SMAC.
What about
kyrub's AI Patch? I think he built it on top of yours. That one is a big hit here, due to Codex being kind of vanilla purists. Hmmm... talking about that, you think it would be hard to make a "SMAC within SMAX" mode using your code? Essentially, SMAC, but with some features of SMAX, like the fixed energy maintenance.
I totally get that. That's why I'm trying to have as light a touch as possible with any changes/fixes that deviate from vanilla (and why I'll probably add a compiler flag for these changes at some point). I'm currently only maintaining and testing using the SMACX binary. Trying to do both at the same time would slow things down significantly. All my analysis using an IDA database has been on the last official SMACX binary. A future state item would be to map some of that analysis over to SMAC. It would be useful in tracking changes between binaries and putting together a more complete SMAC within SMACX.
There is a boolean flag that gets set at start of WinMain of SMACX binary that toggles expansion mode. Throughout the code, it is referenced in various checks for SMACX specific features like
here or
here. It likely isn't 100% and may have just been for debug and testing. However, I think once I have most of game mechanic code done then there could be a review looking for instances where SMAC/SMACX differ that are missing this flag to add additional handling to. Then you could have a button on main game menu that would switch between SMAC and SMACX mode.
SMACX binary with flag set to false:
Why you think PRACX is easier?
I was mistaken. I didn't realize how many changes were made to binary with PRACX. However, I did some cursory tests and they seem to work together. You would just run OpenSMACX patcher script as the final step. Since most of PRACX changes are related to fixing outdated engine code and my current focus of OpenSMACX is game mechanic code, they should complement one another. I have started to break down some of core engine classes, but none of the more complex UI related ones that PRACX likely alters.
Oooh, that's cool! So the dll overrides the alphax.
Did you say... creating new abilities? Now that is SUPER-cool!
The dll takes over all processing of alphax.
This was my goal for initial 0.1 release to decompile all text file processing. You can't go completely crazy yet and alter everything until all references to these structures are decompiled. But you would have the ability to add new stuff and then reference the new stuff in existing decompiled code.
The way abilities work are a sequential
32-bit bitfield that is checked in other parts of code. There are currently 3 bits at the end that are unused. If you wanted, you could create a new ability that gets
parsed and reference it in other parts of code to do whatever you want.
Hmmmm... I see. It makes sense, not finding out all references first could backfire badly.
Yep! There is a delicate balance with my dll hooking into existing memory address of structures of the exe. Once more code gets decompiled, I can remove these restrictions by handling them in memory of my dll.
Talking about caps... what about the one big flaw of the game, which we have never been able to change? Namely... the number of factions. We have all been wanting to play a 14-faction SMAX game for quite a while, now. Its the biggest flaw in the game, and one of which we have never found a way to mod out.
If I remember right, I think someone (you? Yitzi?) said that the value for that was a 8-bit integer, where the eighth number was for the native life, just like how Civ2 had eight civs, with the eight being the barbarians.
Of course, I suspect the game would require graphics changes in order to account for extra faction slots in a number of situations, like selecting factions in a game, the diplomacy tab, the Planetary Council interface...
I've wanted this for a while too! This along with other hard caps on bases and units is what drove me down the full decompile path. There is so much code that assumes that there are only 8 factions (7 factions and alien AI) that this will likely be a much later addition. That sounds correct. There is only memory allocated for 8 factions in the Player and PlayerData structures as well as so many code assumptions on only having max of 8 players. I've made an effort not to use the value 8 in any of decompiled code but a
constant variable. The same goes for other caps. That way it should be easier to alter in the future without a lot of code rework.
I would love to play a 14 faction game on a massive map!
C++? Aaaah man. I was kinda hoping for C Sharp myself. I don't know a thing about C++.
Ahh shoot! This is probably largest C++ project I've worked on so a bit of a learning process for myself. I have a lot more experience with assembly, python and C. But original code is compiled with ancient version of MSVC++ so I figured it would be easier to convert into original language.
