Also an old topic. Last result was "lots of work, won't happen". How exactly was this determined? I looked at the LOUD lua code, and while yes, the changes are significant (especially the weird naming of functions of LOUD) porting it should not be impossible.

Admittedly, the "no actions for n ticks" solution does lower the amount of desyncs, however the user experience is indeed underisable. I would second the suggestion for a "global pause" fix instead.

Well, I overread the statement about the engineering station. It's hell about time. Thanks.

Still, consider to stop BT nerfing anyway, as compensation by "just more engy stations" will harm sim speed - for effectively no real change.

Quite frankly, every single time the balance team decides to "nerf BT" it harms those two factions which evidently scale by far the worst in build power, the most. Namely Seraphim and Aeon. Can we please stop this already?

It should have been evident enough by now, that simple calculation by rate numbers doesn't cut it - given how bad the path finding of the stupid engineers affects actual possible growth.

Admittedly, the "no actions for n ticks" solution does lower the amount of desyncs, however the user experience is indeed underisable. I would second the suggestion for a "global pause" fix instead.

@DragonStrike406 said in Large Unit Clumping and Unresponsiveness:

I found this out the hard way. While the DLL files are a mix of Lua and C++, and the executable itself is C++ only, that is still all I can say. After disassembling I did not find any names I could put to use such as function calls, function names, file names, etc. Everything was in deep x86 assembly, and even when translated to C++, it was basically the same useless code. I say useless because it is. You cannot get anything useful from it, no names, no function structures, no nothing. One big gibberish. It's exactly the same thing with the libraries stored in the DLL files. They too are a massive pile of organized mess with no names.

I can mostly agree with this (which just a few minutes of looking). So far I could get some useful class names, but not really useful function names or implemenations. The decompiled implementations in C++ where pretty much word-by-word translations of the assembly - aka useless.

As to swapping FAF libraries with that of SC2, that will not work either. While yes, the base engine is the same, the two versions vastly differ, which I can say from just looking at how the starting hexes of each executable are laid down. Both are the SpringRTS engine, yes, but one is from late 2007 while the other is from early 2010.

I wonder, what makes you conclude that these both are derivations of the SpringRTS engine?

But it doesn't take going into reverse engineering to notice that the two games are too different to swap any files with each other. If you go to SC:FA installation and check what's in it, then compare it to how SC2's structure is made you can come to a conclusion that they work very differently from each other if your IQ is higher than the room temperature in Celcius.

The initial file layout is not that insanely important. Their linking method might have changed, fooling you into thinking there is absolutely no commonality left - while there is - albeit very limited.
Additionally I never meant "trivial file swapping". I'm a software dev myself, I know things aren't this easy.

TLDR; I did reverse engineering on the FAF executable, no you cannot modify it to make it run better, no you cannot swap files from SC2 because the two games are structured in an entirely different way, it would be easier and faster to remake FAF in some new game engine.

Well, it was an idea. But apparently a flawed one. I did not expect supcom 1 and 2 foundations to diverge this insanely much.

@Katharsas Given how insaenly fast CPUs nowadays are compared to 2007, even in single core, when used properly, I'd not even try to attempt any hacking to "multithreading" in (which wouldn't help much, when the core engine doesn't support it and you end up doing pointless tiny calculations multithreaded without any gain).

Instead, one should attempt to revive the work to modify luajit-GC to make it fit with supcom. This should (at least according o micro benchmarks of luajit) in some cases give up to 4x or even more performance.

I actually take a look at ghidra right now. It's an amazing tool, however making sense of all will take time (and stamina).

Initially I will take a look at both, supcom 1 and supcom 2 mohoengine.dll. If its not entirely easily possible to replace supcom 1 pathing implementation with an own one, maybe there is a way to give supcom 1 at least supcom 2 path finding.

Besides the "typical" (and I mean that in a non-condescending way) "out of our reach response": How much reverse engineering work was acutally done on this? Was the exact DLL and maybe functions and data/objects that deal with or are affected with pathfinding identified? If so, one could maybe attempt an dll inject approach.

Additionally, pathing in Supcom 2 is mostly fixed and both supcom 1 and 2 use the same engine. Can we maybe get clues by diffing their mohoengine.dlls? (symbol table etc.)

You would know a mobile CPU is in use and simply kick its user, because it's somewhat pointless?

Asking to revive a dead project again: Can we maybe ask Jeff Petkau on the changes they did on the lua vm clone and potentially replicate those?

@speed2 When it comes to thermal throtteling one would need to have high load for a significant amount of time to benchmark it. That makes such a benchmark unpractical. Therefore I suggested showing the mere CPU model.

As an addition: I for one would not recommend any FAF focus on AI. AI I would at least assume is a neglectable use case in FAF. The vast majority of us would care about increased performance in multiplayer.