Recent Posts1
Outpost 2 Programming & Development / Still at it - reconstruct first, hang code, streams as tests
« Last post by jonathangoorin on September 10, 2026, 05:00:21 AM »Hey all -
So as I started out with the LLM-decompile idea, I thought it would give me a better starting point. But at some point while working with the agents we came to the conclusion that the gain we could get from that path would be marginal - and that is after an optimistic estimate. So I figured we better start the reconstruct now. For after all that is the main goal, right? To reconstruct it - to get back that lost code. At least that was the dream I set out to accomplish.
Small side note - I did not forget the decompile LLM. I still plan to investigate that branch. The idea of a decompilation engine for old games still sounds very exciting to me. But I need to think about it more. We are not only talking about pretty C or C++ out of a decompiler; we are talking about decompiling whole proper game systems. That is different stuff. I even thought maybe diffusion models somehow - but those are just thoughts in the wind, you know.
So we had this decompile stack: the Ghidra pseudo-code, the asm, and of course the community notes and the Olly and all. And I have to say I am very thankful and grateful for the work you guys did. It is short of a miracle to have such a map, and it is a clear sign of love and devotion. As they say - I stand on the shoulders of giants.
So we (and by we I mean me and my agents) took this decomp stack from the original PE and started to refine it function by function, cross-referencing it with the community knowledge. We called it "hanged code" (don't ask why). And once we hanged all the known addresses from the PE and the DLL, we started to rewrite.
The idea is that the hanged code is this huge blob of reworked pseudo-code. It is much closer to source, but it is still a heap of just functions - it is no game by any means. So the idea is to chunk it up with some sort of heuristic of which game system it is, and module by module rewrite it proper.
In order to actually know that the rewrite adheres to the original, we introduced the idea of streams. A stream is like a value over time - like a movie or video stream - where we record the commands given to the original Outpost PE, and we record the memory values over game ticks. We then use that as a baseline and compare it with the stream from the reconstruct. If they match, we can say with some amount of certainty that the reconstructed module is like the original - at least in a behaviour sense.
We also developed a harness for both the original and reconstruct: boot it up, issue commands, create units as needed - integration tests like in any other game.
In the beginning we wrote just simple "unit test" like scenarios: create unit -> order it -> see it arrives, or do whatever it was ordered. But as we recreate more and more modules, the plan is to create longer and more sophisticated test scenarios and run them through (at x40 speed or even more).
For now the repo is a mess, and there is a lot of old code from the dataset creation and LLM training tests and the QEMU Win2k box I used to cross-compile. So I would like to streamline it first - keep only the reconstruct and the harness stuff around it.
Once I do that and finish at least a first pass, I plan to open it to the public. You would still need your own vols / original assets to play; I am not shipping those. Off-day project, so figure a couple more weeks.
Questions welcome.
So as I started out with the LLM-decompile idea, I thought it would give me a better starting point. But at some point while working with the agents we came to the conclusion that the gain we could get from that path would be marginal - and that is after an optimistic estimate. So I figured we better start the reconstruct now. For after all that is the main goal, right? To reconstruct it - to get back that lost code. At least that was the dream I set out to accomplish.
Small side note - I did not forget the decompile LLM. I still plan to investigate that branch. The idea of a decompilation engine for old games still sounds very exciting to me. But I need to think about it more. We are not only talking about pretty C or C++ out of a decompiler; we are talking about decompiling whole proper game systems. That is different stuff. I even thought maybe diffusion models somehow - but those are just thoughts in the wind, you know.
So we had this decompile stack: the Ghidra pseudo-code, the asm, and of course the community notes and the Olly and all. And I have to say I am very thankful and grateful for the work you guys did. It is short of a miracle to have such a map, and it is a clear sign of love and devotion. As they say - I stand on the shoulders of giants.
So we (and by we I mean me and my agents) took this decomp stack from the original PE and started to refine it function by function, cross-referencing it with the community knowledge. We called it "hanged code" (don't ask why). And once we hanged all the known addresses from the PE and the DLL, we started to rewrite.
The idea is that the hanged code is this huge blob of reworked pseudo-code. It is much closer to source, but it is still a heap of just functions - it is no game by any means. So the idea is to chunk it up with some sort of heuristic of which game system it is, and module by module rewrite it proper.
In order to actually know that the rewrite adheres to the original, we introduced the idea of streams. A stream is like a value over time - like a movie or video stream - where we record the commands given to the original Outpost PE, and we record the memory values over game ticks. We then use that as a baseline and compare it with the stream from the reconstruct. If they match, we can say with some amount of certainty that the reconstructed module is like the original - at least in a behaviour sense.
We also developed a harness for both the original and reconstruct: boot it up, issue commands, create units as needed - integration tests like in any other game.
In the beginning we wrote just simple "unit test" like scenarios: create unit -> order it -> see it arrives, or do whatever it was ordered. But as we recreate more and more modules, the plan is to create longer and more sophisticated test scenarios and run them through (at x40 speed or even more).
For now the repo is a mess, and there is a lot of old code from the dataset creation and LLM training tests and the QEMU Win2k box I used to cross-compile. So I would like to streamline it first - keep only the reconstruct and the harness stuff around it.
Once I do that and finish at least a first pass, I plan to open it to the public. You would still need your own vols / original assets to play; I am not shipping those. Off-day project, so figure a couple more weeks.
Questions welcome.
