Large Unit Clumping and Unresponsiveness
-
Setting aside the fact that pathfinding cannot be changed by us: if the movement path needs to be a "U" shape to go around something (ex. first going south even though ultimate destination is north), how much calculation do you propose to make sure the "dumb" direction is actually a helpful one? And at what point does that become enough calculation to just finish and get the final path?
-
@Pearl12 Watch about 10 seconds of Starcraft 2 gameplay on Youtube. It is possible to code this correctly, someone has chosen not to. No one would play Starcraft 2 if the back half of every formation had to be pre-pathed forward before the front half to get proper group movements. This needs to be hashed out, and the people playing hard to get with modifying the core code are doing the entire game a disservice, and disgracing their own title.
Right now the process is bottle necking to prevent computation overload at the time of the movement command. All that needs to be changes is to have the logic of that bottleneck reworked around movement first, then create a table of distance values and the proposed unit formation based on units in selection, and make a "hot calculation" that picks placements on the move and doesn't expect to do this all at once. This fixes the problem and keeps the choking down.
Also remember that in Starcraft II there is zero unit formations. That would honestly be preferable in certain instances just to get the absolute most smooth movement, and if you could toggle off the formation this would save on game resources. Again a lot of this revolves around the grudge work centered on running all the game's gears separately on each client then running error correction between them. Get this running on a single server shard and make clients an input output engine focuses on graphics, and performance goes through the roof (discussed in this post:)
https://forum.faforever.com/topic/196/faf-spin-off-title-plans-to-take-supcom-to-the-next-level/11
Gamers, young gamers, competitive gamers, and incoming players expect things to work smoothly. I've been hearing a lot of grumbles from the old guard about how "this is just the way it is" but this isn't some cheesy 1980's record. Its 2020 and we can expect things to get better over time, aseptically when all the tools are before us to make those changes.
-
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.
