As the source code of SMAC is not available, these changes have been accomplished by disassembling the binaries, analysing the code, and writing fixes in place within the binary, also in assembly code.
In late 2014, PlotinusRedux released a new kind of patch for SMAC. This patch provides a number of user interface improvements that would have been extraordinarily difficult or tedious to implement in assembly.
PRACX installs a small patch into SMAC's core code, getting it to call an external library written in C++. This library then patches the running SMAC binary further, overriding calls to a number of functions with calls to new C++ implementations provided by the library.
See also: Installing patches, Category:Unofficial patches, Disassembly
## Future work
Yitzi continues work on his patch following the disassembly method. For many bugs and small, engine features, this is a practical way to work, and Yitzi has proven himself to be very good at it.
In late 2015, scient announced that the Mac version of the game had been compiled without obfuscating function names. This is of great help when documenting or trying to understand a disassembled program! A project began to document the game code better and to complete the job of decompiling it. We hoped that we might be able to produce a compilable code base for SMAC, or, if that were not possible, to greatly aid future PRACX-style modifications and reimplemtations of the game.
You can PM me if you like, but better to just talk in the open, in this thread.I don't mind if no-one else does, but... As a newbie, the questions I have are nearly endless, and so I thought it would be better to read some material on my own than keep this thread perma-bumped, heh.
If you really want to get into enhancing the AI, I suggest we talk about how you want to do that at an abstract level first, rather than jumping straight to code.Ah, do you mean formal AI design patterns? I'm interested in this if there's resources on it out there, but the "model" I have in my head is hardly formal. It's the product of an outsider's speculation on how to design AI. More or less, I wanted to create an AI which mirrors my own strategies and tendencies as closely as possible, and does it well.
What in particular do you think is deficient with the SMACX AI? What kind of things would a competent player do instead?Off the top of my head - nothing in particular, actually. I should have been making notes, perhaps. It's merely many instances where a human player is able to apply a specialized strategy where the AI cannot, netting them a large advantage. I've found in most 4x games, AI factions or empires with an innate production bonus tend to be the most powerful, simply because it allows the AI to persist through brute force, minimizing weaknesses in strategy. Yang certainly might qualify!
If you're interested in the theory (and trying not to scare you off): there are a variety of approaches to game AI, from very primitive heuristics based models up to full blown epistemic planners (a fancy name for planning based on knowledge, with particular connotations). What approaches do you know about? What do you feel comfortable learning?I'm very interested! However, I'm unfamiliar with any of these approaches, as mentioned. Book recommendations would be great. This epistemic planning in particular sounds a bit similar to what I've been getting at :)
scient talked to ANYone five months ago and I'm only hearing about it now?
Glad you're not dead, sir. :Dscient talked to ANYone five months ago and I'm only hearing about it now?
Like Rumpelstiltskin just say my name and I appear (maybe with a bit of delay haha). I'll do a more in-depth post in one of other threads related to my work on SMACX.
For learning RCE, I suggest writing small basic programs in C/C++ and then popping the compiled debug binary into IDA/debugger. OllyDbg is great debugger for beginners. For disassembly, IDA is industry standard. There are some others like Hopper for mac. IDA also had a great decompiler plugin that is quite helpful with SMACX code. This way you have your own original source code and can see what's going on under the hood.
Great books under Reverse Engineering section here:
http://dfir.org/?q=node/8 (http://dfir.org/?q=node/8)
The x86 binary (windows) was compiled with an older version of Microsoft Visual C++ (5 or 6).
So I've been talking with DrazharLn about sharing the database like a week ago. He reached out to me via email, my life has been hectic. I have a little bit of time before things get busy again so I'm currently working on cleaning a few things up and merging notes into the database. There is much do to with understanding data structures as well as what certain globals or enums do. I have tried to identify as much as I can as I work on it. Either way, it makes it a lot easier to say find specific combat, base or diplomacy code than blindly look around. Want to understand something related to global map? Just see all references to g_MAP in database. Things like this. It makes finding patterns and understanding code flow more manageable.
Once I finish a draft ready for public, I will host it on here as reference and maybe if people identify more stuff merge that info in future draft. If I run out of time and don't finish want I wanted to, will post it anyway. Either way, it will get posted by first week in June.
scient talked to ANYone five months ago and I'm only hearing about it now?
Like Rumpelstiltskin just say my name and I appear (maybe with a bit of delay haha). I'll do a more in-depth post in one of other threads related to my work on SMACX.
For learning RCE, I suggest writing small basic programs in C/C++ and then popping the compiled debug binary into IDA/debugger. OllyDbg is great debugger for beginners. For disassembly, IDA is industry standard. There are some others like Hopper for mac. IDA also had a great decompiler plugin that is quite helpful with SMACX code. This way you have your own original source code and can see what's going on under the hood.