Got into a 4 man game just a little while ago. Never had a laggy choppy experience like this what so ever. Anyways, to draw short conclusion the reason the game was so laggy and choppy was beacause one of the players in the game is using a building stacking technique, that allowed him to create 25 bots every 5 seconds. He had 2 stacks of 25 bot factories. That's right two stacks of 25, total of 50 factories in the space for 2 factories. Right after he destroyed my colony withing the first 5-6 minutes of the game... Fair enough.. I saw that he was producing 25 units per building every 5 seconds. I called him out on it. This player asked me how i could see what he was doing. I just told him spectator mode when destroyed... But with the mass number of bots he was creating it caused almost complete server failure. I don't see how this is actually the way game is supposed to be played... Are there fixes coming to prevent players from ruining the game like this? I know it's Alpha and there are lot's of things to do and work on. Just curious as to how or what is known about this type of playing style. It completely ruined any fun I would have had, because players can just run any exploit they like and ruin it for the others that are actually playing the game to enjoy it.
Not an exploit, just a bug that allows building units on top of each other. He still had to have the resources to do so. See FS#1433 - Can still stack buildings in .49900
Metal spots won't be much longer and they will drastically cut down on stuff like this. Thought we had the unit stacking fixed but apparently not.
You can't stack on top of already built units, but you can queue up units on top of each, and the fabbers will happily build them.
Let me guess, the code which checks for a valid build location is at the build-order instead of the construction start?
Even worse. (I don't know if the following is still true in the current build, but it was for sure in the previous build.) The server side validation code is at the start of the movement section of the build order when it is queued. So engineers which can't (because they got stuck) or don't need (because the are in range) to move for any reason can build wherever they like. Even on the "real" moon. Well, you can't be "in range" if you want to build on the moon, but getting stuck still works. The no-stack validation appears to be broken to, it is only ever validated when queuing the command, but not at the point of execution. It should have been the other way around - let player queue whatever they like (only enforce restrictions in the client), but skip invalid steps during execution. After all it CAN happen that the order would have become valid during execution of previous orders in the queue....
Bad idea, this means that you could end up slightly misaligning buildings that would not be build because of it. It should check while placing against real buildings and planned building. The scenario of an invalid command becoming valid because a building disappeared might be possible, but it isnt something a player would plan for normally. So no need to include it. Also the reaction to an invalid build command is a bit annoying right now as it cancels the "to be build" selection of the engineer. It should just not allow placing the building instead.
Not a bad idea at all, if it was the CLIENT who performed the test first. The client should already know about blocked space or not, after all it will need to have to information anyway to give immediate visual feedback on the plausibility of the building location. (You know, that "blueprint tinted red when location is invalid" stuff.) Placing the building without immediate feedback and hoping that the server accepts it as a command is a bad idea. Verifying if an order can be issued is not the responsibility of the server, the server should only ever check if the command can be executed once the command gets active. The only validation at the time the order is issued should check is if the command is well formed and the user is entitled to queue an order for the specific unit. Right now, it appears like ALL(!) validations are performed at the time of issuing the order ONLY. During order execution, not even the reachability of the current way point is verified if it has changed since it was issued. While this does safe quite some computing power when issuing commands to large crowds (only a single flowfield needs to be generated when the command is issued, and all validations are only performed once per GOAL, not per unit entering a certain step), it does have an negative impact on the flexibility. I guess we are going to see the full problem with this system once someone tries to merge multiple order chains, e.g. assigning a new factory's waypoint to the middle of an existing command queue. Or even simpler: If the goal becomes unreachable after it has been issued, e.g. because someone has build a wall in the only possible path. Units get stuck right now in this situation and they won't skip the waypoint due to lack of validation upon entry of the command.
I agree with exterminans. The client should check if an order can be issued, the server should check if the order can be executed with it needs to be executed. This will give the server more resources to be used for other tasks. With extreme lag it is possible the client checks are not in line with reality and thus incorrect.
The Server still needs to know when orders are issued, not just executed. For example, in games where there's more than one player per army, you'll want to be able to see what your fellow player(s) have queued up. Also, not communicating with the server when orders are issued means that if you drop & reconnect, all your orders will be lost.
Commands are still issued to the server, it's not like that was going to change. But the client needs to provide visual feedback BEFORE the order is issued, at least an estimation whether the command will be executable or not. The command is then queued on the server and communicated to all players who should be able to see it, but no extended validation is performed for now. Extended validation only ever happen when the command is executed, this is also the point in time where additional resources for the command are allocated (once per command), e.g. the flowfield for navigation. The command gets a flag set which marks it as "in use", so resources generated for the command are not evicted by garbage collection. If the command is invalid (either because it was from the beginning or it is temporarily due to changed conditions), the command is skipped or removed, depending on what happened. Unreacheable goals are to be skipped, no longer valid goals (e.g. construction of an already finished building or attack order on an already destroyed target) are to be removed.
What should client state rewinding (I think you mean the chronocam?) have to do with this? EDIT: I think I've got it. You mean that you should be able to revoke the last issued orders in the reverse order they have been issued? Not a bad idea, canceling missplaced waypoints or buildings has always been a bit tricky in SupCom, a simple and intuitive shortcut to do so could have saved a lot of trouble.
Yeah, something like that. It seems to me that you can improve the appearance of performance by having a little server locally that pushes the game along according to 1) the recent orders that haven't made it to the server and back yet, and 2) what information the client already has. But eventually, that little server is going to make a mistake (because something new will be sent that it didn't anticipate). It'll need a tiny bit of Chronocam to re-wind and apply the new state changes (or just apply the state changes outright). MWO implemented this, and it help laggy connections (ala. Australians) greatly.
