Large Unit Clumping and Unresponsiveness
-
ok go code better pathfinding for us
good luck
-
What Ftx said.
People expect things to work smoothly, and hopefully, they give some leeway for a game from 2007. You talk like you just got out of grad school with your CS degree in ruby on rails... welcome to retrofitting. That's not an insult, we'd love to see what you describe. Many of the players are capable developers who have similar dreams. The grumbly "this is just the way it is" is not from a lack of desire, just a lack of time, or a paid full-time developer, or the ability to break into the source code, or a combination. If you want it to be done, join the dev team and see what you can do. Good luck. Seriously.
Just to make sure we have all the information: when you say "formation," do you mean holding a right-click? If so, formation moves are slow anyway. If for some reason I want a long-right-click formation I usually give a fast right-click to as near as possible where I want the units to end up, then shift-long-right-click.
I can't say that I have had noticeable lag with just short (regular) right-clicks. Maybe I'm too immersed in hundreds of robots doing my bidding to notice they have a slight delay in my sending them to their deaths.
-
I don't know why you insist that your proposed changes are easy to do when multiple people have told you they are not.
You even disregarded the attempt to get the source code as half-witted, just because it didn't work. maybe it didn't work because square enix in fact does not have the source code? No amount of money will change that.
I advise you to do some research about compilation and decompilation of code and especially about the problems of the latter to get a better understanding why your proposed changes are not realistically possible. Everybody wants better pathfinding, it is not developers "playing hard to get".make clients an input output engine focused on graphics
this is essentially a rewrite of the engine anyway, and that requires manhours worth millions of dollars.
-
I urge you to research reverse engineering. A first time develop of something cost a much large around because they are stabbing in the dark and making first time implementations of things. Also source codes can be "decompiled" ask any military or intelligence expert. Its not exactly rocket science here, we have a functional model working on peer to peer. It needs to be run server-side simulation to cut out all the extraneous layers of client to client preparation, streaming, and error correction. This last sentence surmizes everything that is going wrong with this title.
Do what's necessary to fix these problems and you will likely very rapidly move from #4 to #2 on the top RTS list on google.
Holding out the source code vs the larger body of the company is illegal. I'm not in that company and I wasn't around during lay offs, but I can smell a bit of a fish here and some sort of mediation would be preferable. If not just brute force the box open as much as possible and remake functionality (which is much easier to replicate than design as we already see the intended end product in action)
-
Joining in the discussion here - what you are asking requires some hefty engineers (expertise) and a ton of time. Solutions, such as the UI freeze when pausing are here not because we want them to be but because there is no alternative that is valid given the constraints.
An lead engineer on Supreme Commander mentions the majority of functionality that you mention - they didn't do all of it because they didn't have the budget nor the time (and perhaps: lacking the experience / expertise) to get it all done. And they had more expertise, more time and more budget than we do. For more information on the video:
-
@Spy_Emanciator said in Large Unit Clumping and Unresponsiveness:
I urge you to research reverse engineering. ... Also source codes can be "decompiled" ask any military or intelligence expert. Its not exactly rocket science here.
I urge you to do some work on the game instead of just making forum posts imploring other people to do so because apparently it's really easy.
YOU find a military intelligence expert that wants to donate their time to reverse engineer the game for us. That would be great!
-
lemme help u out a bit mr businessman
-
You are wasting your time here and telling everyone here "what to do and how easy it is" without putting any of the work your self.
If you want to help there is a really good video explaining what would make you helpful and productive member of FAF community.
That is if you really are here to help out the community.https://www.youtube.com/watch?v=ZraD244VywA
"FAF Contributor Tutorial - How to get engaged" -
Spy asks for some glint of support for a good idea, then gets peppered with internet salt and unfettered anger by mostly unqualified and unidentified forum trolls.
We'll let the adults read through this mine yard.
-
If formations are the problem, would it be possible to simply delete the datafile or entry that stores formations in the first place, or replace formations entirely.
Also if you are looking for a solution to pathfinding to 'remove' formations, when a move order is issued, instead of pathfinding the formation, post-process a stop command followed by a set of move commands individually for each unit matching the end formation structure. That way we can keep the rough structure of the unit formation, without the back engine trying to calculate the pathing as if it were a formation.
Formations in this game serve 0 purpose. I have no fucking clue why the developers even added this feature.
Also if you want to get rid of shit tier bumbing mechanics, just make units have phase so that if they are within a certain distance of another unit, they lose their collision or becoming a flying unit for a minute amount of time and have this have a cooldown to avoid bugs/abuse per unit.
If you want to improve engineers being shit, improve their turnrate. Its garbage.
On a side note:
Has anyone asked Chris Taylor for the sourcecode? There's no way he wouldn't have a copy.And yes everything sounds easy until you try and implement it, that is where the real challenge begins.
-
@Spy_Emanciator said in Large Unit Clumping and Unresponsiveness:
Spy asks for some glint of support for a good idea, then gets peppered with internet salt and unfettered anger by mostly unqualified and unidentified forum trolls.
We'll let the adults read through this mine yard.
Spy asks for people to put all the work in to make his dream become a reality, without doing or having done any work himself. When people suggest they might listen to him if he was willing to do some of the work himself, he responds with ad hominem.
-
@Pearl12 I think his complaint was more of the fact that he made a suggestion and the response was garbled "engine limitations", which itself merely means too long didn't read, and more often than not is just parroting other people that give it as an excuse for not doing something, because they either don't have the knowledge and expertise, or they do have the knowledge and expertise but not the time.
At no point did he say he wasn't going to code something. I think this was more an airing of ideas, to see if people had any other solutions or suggestions or if anyone would be interested in doing it with him.
Which is why i posted a number of suggestions/possible solutions that might be worth considering.
But the amount of shitposting he does, whose fool am i being?
-
"It is possible to code this correctly, someone has chosen not to. "
Translation:
I won't do it, but somebody else should have done it, in their free time, shame on them that they didn't."Has anyone asked Chris Taylor for the sourcecode? There's no way he wouldn't have a copy."
Yes, he has literally personally sad in the interviews that he is very sad that he didnt keep the source code. And the current owner of FAF trademark has personally tried to buy the source code for a massive amount of money a lot of years ago.
This kind of suggestions and demands appear constantly in the forums, and this is why people are giving this kind of tired response. "Unit Unrepsonsivness" has been brought up by tons of people over the years. Everybody agrees that it is not nice. But its not gonna change if the 14335th person goes into the forums and complains about it.
We should make a FAQ list of all of the engine related issues and that getting the source code has been tried and suggested over and over.
- Staggered movement of unit clumps
- No Multithreading, bad simspeed (some of this might be fixed in Lua, but limited)
- Pathfinding lag in general
- Player input (commands) not getting registered sometimes
All of these are not going to get fixed unless YOU, random forum person, personally start with it. So try it, and when you relize how hard it is you will come back as a more understanding, humble, grateful person. Or you actually make progress, then you will very likely find people that would love to help you.
I suggest to OP to download Ghidra and try to learn some reverse engineering. There are tutorials and example crackmes, easy to find.
-
wow, first two replies explains exactly what's going on. OP ignores it and starts ranting regardless then expresses surprise when shit posting starts.
-
Simple... The Command Queue of the game is flooded. It usually not the terrain, surpisely. It mostly command queue being flooded. That's why the worst the simspeed is, the worst the game's units just don't respond at all. Which makes the game even slower. The game is trying to process all this unit movement, effects, etc.
-
Id say 50/50 after say a correction of issue placed within SupCom 2, which was fine, but still seemed to be lacking something for the gain to say.
-
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.)
-
@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.
-
I recently picked up reverse engineering the FAF executable and libraries.
If you want credibility to my claims, I worked on two game reverse engineering projects in the past. One on Robocraft, where I had my part in deobfuscation of a massive C# assembly, and the other was the HAWaKENing project where I assembled a team which goal was to make Hawken run on PC again. This was no easy task because the game was only multiplayer, and was shut down on January 2nd 2018. We had to not only disassemble the executable and find out how it's inputs work, we also had to make a login and services server from absolute scratch. We did succeed to some extent, we are yet to get actual multiplayer working but we did manage to get the account server running and player can now even play against bots.
That's for my background, and as someone who works with IDA, Snowman Disassembler, and writes some of my own tools to help me in the process of making old software run again, I can attest that it would be much faster to remake the game using current-day technologies than it would be to improve the executable.
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.
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. In that period of time, Square Enix could have easily implemented an entirely new compiler and change a lot of engine functions themselves to better suit their needs for the game. And they certainly did so, because one major difference that can be pointed out right out of the gate, is the fact SC2 benefits from running on multiple threads, while SC:FA's engine does not run the simulation this way.
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.
All this amounts to a one conclusion. Reverse engineering and recompiling the game with new technologies is not impossible, but one would have to spend roughly 5-6 thousand hours of work on it. What is affordable and could actually work, is remaking the game from scratch, based on what we know, and how it plays. Engines like Unity, Unreal Engine 4, or Godot have the potential to make this real. However that said, I personally believe Godot would be the most suitable engine to do it, simply because how simple it's structured, how easy it is to learn, and how full of content it is. With Unity you will need more than just unity, because the engine by itself does not have an IDE, and more often than not, you'll have to use a lot of middleware to achieve your goal. Unreal Engine 4 is a great tool for FPS games, and not so much for everything else, which shows in how the engine wants you to structure your game, and how many prefabs are oriented around FPS style of gamedev. Godot itself comes with it's own IDE, physics, 2D and 3D graphics, Visual Scripting for non-programmers to make code, and is very simple in how it handles game design. Not only that, but it's completely free. No royalties, no pay-up-fronts, no per-seat licences. Of course, if you want to you can make a game in whatever engine you want it to run, or even make your own engine from scratch too.
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.
-
@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.
