Possible engineering fix for dashboarding
-
Guys, I think you are missing the point of my post. I was trying to lay out a technical wayof how they could implement a technical fix. Some better exception handling code could fix the issue technically, which would give them many different avenues for how they could further play this out. The way I mentioned about the hand-off was just one way, but there are others. They could also clone the result object of any hit, saving one copy local and sending one over the network. If a network connection occurs (dashboard), they could re-send the local copy of the data result to an SDS server the next time the user logins. This could give you the stats and the win, just with a possible delay. This is another possible technical fix. Cloning a memory structure before sending it over a network would not add a substantial, meaningful display, especially when all your are seeing is the result displayed....the sending console already knows what happened. The result was known by the sending console before it went over the lt onetwork. The sending console can just re-send the result to an SDS server for the stat collection. Now, they would probably need to setup a new. small server that just received disconnected results to input into the backend database/datastore, yet that shouldn't be hard/too much different than what they currently do. I assume they are using a NoSQL database on the back end, so they could craft a results payload pretty easy, with the previous game's result prior to disconnection, without causing any issues. It's not brain surgery or rocket science, it's just saving data structures and sending the updates again, similar to a network retry.
So, I gave SDS another option about how to get the game results up. They can send the results prior to the disconnection, and no additional game needs to be played. You guys now have what you want, both ways.
-
@crimson_monk said in Possible engineering fix for dashboarding:
Or put a 1 hr punishment for first dashboard per week, then 12, the. 24 then the rest of the week until the week resets.
That's what i've been sayin. Just ban em from servers. If they leave due to disconnect then there is a grace period to re-connect if they can't re-connect b/c internet is out well they wouldv'e lost anyway. Rocket league does this in competitive mode. Send the message nip it in the but! Cut the snake off at the head!!
-
I'm coming in late to the conversation, but here's how it likely works and why we can't fix it.
Once the ball is in play, there is still a roll because the distance of the park dimensions have to account for the result of HR or ball in play. It's not until the collision of the ball on the ground occurs that when both clients are processing the result. For instances where a connection is terminated, the coding logic must defer back to the last resolved play received from both clients in order to populate the stat retention on SDS servers.
Ultimately, the only way to fix dashboards is to punish the disconnects post dashboard.
SDS gives you a token for dropped collection in the form of a collectable. A simple query for X number of disconnects and a human referencing the games for a pattern of losing or being tied for said disconnects in excess of X times over a period.
Find the repeat offenders and punish.
Another solution is to limit the number of allowed disconnects during online play to 3 every 24 hours. If your internet is causing the issue, fix it or stop playing online. If you are dashboarding, 3 strikes and your out for 24 hours.
-
@hoboadam_psn said in Possible engineering fix for dashboarding:
I'm coming in late to the conversation, but here's how it likely works and why we can't fix it.
Once the ball is in play, there is still a roll because the distance of the park dimensions have to account for the result of HR or ball in play. It's not until the collision of the ball on the ground occurs that when both clients are processing the result. For instances where a connection is terminated, the coding logic must defer back to the last resolved play received from both clients in order to populate the stat retention on SDS servers.
Ultimately, the only way to fix dashboards is to punish the disconnects post dashboard.
SDS gives you a token for dropped collection in the form of a collectable. A simple query for X number of disconnects and a human referencing the games for a pattern of losing or being tied for said disconnects in excess of X times over a period.
Find the repeat offenders and punish.
Another solution is to limit the number of allowed disconnects during online play to 3 every 24 hours. If your internet is causing the issue, fix it or stop playing online. If you are dashboarding, 3 strikes and your out for 24 hours.
Other games have done this with quitters I don’t see why not. There shouldn’t even be a quit option in a ranked online game.
-
@x814xmafia_psn said in Possible engineering fix for dashboarding:
@tvsectog_psn said in Possible engineering fix for dashboarding:
I thought about the dashboarding issue for a few minutes, and a possible way to fix dashboarding (which we all hate due to trying to prestige players).
If a network connection drops during a game, the game then switches to a local game at legend difficulty to finish the game locally. Each player on both ends of the dashboard has to finish their now local game and the one who scores less runs or loses gets the loss. If both lose against the CPU to finish the game, then the one who lost by more runs loses. This penalizes dashboarders, and still would allow stats to count toward prestiging players.
The code would work like this.....
-
Network not responding withing x amount of time
-
Instead of exiting out to the main screen, spawn up another instance of the game and populate it with the current stats of the game, including the last instance of the game that occurred. The console knows whether the home run that was dashboarded was a home run before it was displayed (the amount of time the console knows about the outcome before it is displayed to the user is input lag), so it would be easy to save and reply the data into a new clone image (similar to database replay logs), and thus keeping the stats of what just happened.
-
Both players on both side of the dashboard either update the server at the end of their game immediately, or the win/loss stats don't get updated to the server, yet the player stats still get updated.
If one player does not complete the game that is now local/and or can't reconnect to the network for a few hours the stats are saved local, and then a local job running via cron uploads the stats the next time it detects a network connection (or the next time they login to play DD...any queded data gets uploaded to the SDS servers.
Anyway, just an idea of how to possibly fix the issue. I don't know the memory footprint of The Show and above might not be possible on the older consoles, yet a solution like above would be possible on the next consoles as they are fast enough and have enough memory where something like above could be added to protect the game and spin up another instance as needed to combat the 'dashboard affect/dashboard penalty'.
Just a thought/possible solution.
I absolutely love threads like this one.
Anyway, there are two sure fire ways to stop someone from Dashboarding:
1: COMPLETELY get rid of Prestiging cards. I would say that 99.9% of the time the Prestiged version isn't that much better than the reg version. Plus after you prestige someone; now there's another card that don't be used.
- Allow Prestiging to happen OFFLINE
I wasn’t a fan of prestige cards either
-
-
@hoboadam_psn said in Possible engineering fix for dashboarding:
SDS gives you a token for dropped collection in the form of a collectable. A simple query for X number of disconnects and a human referencing the games for a pattern of losing or being tied for said disconnects in excess of X times over a period.
The collectible tokens come with 'quits' for sure, done from the menu (impossible during live action game play), but for sure do the tokens come with dashboards? I've never dashboarded so I don't know what happens when you just exit the application via the PS menu and then come back in later. Does a screen come up showing you the token before you get to the DD menu? Or does it just add one to the collection for you?
If disconnects are ever going to be 'punished' it would be nice if they separated quits out from disconnects, actually. They aren't the same thing. They both result in a game ending early but a quit via the menu doesn't kill anyone's stats. I've never dashboarded but have quit early a couple of times.
I know I'm setting myself up to look pretty pathetic at this game, but for at least the third time since I started playing back in December, I yesterday struggled through a RS game and was no-hit for 9 innings. It's not a nice feeling if anyone out there hasn't experienced it yet, but I honestly try not to quit these 9-inning games early even when it's going badly. I've won about 175 online games and honestly most of those wins have been 1 or 2 innings because I got off to a good start and was dashboarded. It's crazy how few 9-inning wins I've achieved.
Anyway, point is, I agree, I would love it if they would come up with a solution for dashboarding, and honestly it probably hasn't affected me as much as others simply because I don't hit that well. I've lost 2 or 3 Trout HRs but... I'm still way off the prestige card so it's negligible impact, I guess.
-
Anytime you quit or get disconnected, you get the collectable.
-
@hoboadam_psn said in Possible engineering fix for dashboarding:
s to punish the disconnects post dashboard.
SDS gives you a token for dropped collectioBoth consoles would know the park's dimensions ahead of time, as that would go into the hit equation, so that is not the issue. The consoles also know the result prior to it being displayed on the display, so the consoles have plenty of time to resolve this before a user would see it.
A no-doubt home run is not hitting the ground so the sending console already knows the result before it is displayed on the second console.
The issue is that the exception code to handle network disconnects is working in a binary manner, at the moment. Either the connection is connected, or gets lost. You see this through the delay, which is a network timeout. After x amount of seconds (the preset network timeout wait time), the code assumes a disconnect. Further work on the exception handling code could help here.
-
@eatyum_psn said in Possible engineering fix for dashboarding:
@crimson_monk said in Possible engineering fix for dashboarding:
Or put a 1 hr punishment for first dashboard per week, then 12, the. 24 then the rest of the week until the week resets.
Except it is impossible for the game to tell the difference between somebody dashboarding, and somebody disconnecting because they lost internet or something. So it wouldn't just be punishing dashboards.
Well don’t play when there is a storm or just wait til the next week starts. Play offline mode or another game til the week resets
-
@crimson_monk said in Possible engineering fix for dashboarding:
@eatyum_psn said in Possible engineering fix for dashboarding:
@crimson_monk said in Possible engineering fix for dashboarding:
Or put a 1 hr punishment for first dashboard per week, then 12, the. 24 then the rest of the week until the week resets.
Except it is impossible for the game to tell the difference between somebody dashboarding, and somebody disconnecting because they lost internet or something. So it wouldn't just be punishing dashboards.
Well don’t play when there is a storm or just wait til the next week starts. Play offline mode or another game til the week resets
Lol that is not a good solution, SDS would be getting flamed by people sending emails about their power went out etc. Not a realistic answer at all.
-
A admin locked this topic on
