Release Candidate 2023?. Don't learn...

R

Ruben Cerlem

Registered
Since the last event of the Virtual Lemans, with the ridicule of the massive falls of teams having paid 2000 pounds to participate, they not only blamed the teams, but instead of announcing that they are going to work hard exclusively to improve the online , because they are dedicated to launching release candidate. They are not working on their own system, but they are not working on improving the servers for future events, which are only for the privileged, since only these can run because they are closed windows. In the end it is true that the gentlemen of Motorsport Games have turned it into a clown show.
 
Uninstall the gamr and problem will be solved for you. No more clown show.

RC is probably work already achieved more or less. That doesn't probably presume in any way of what the core team is working on actually ...

Massive falls ? That was probably the most eventful E-Sport simracing event of 2023. Just that ...
 
Ruben Cerlem said:
Since the last event of the Virtual Lemans, with the ridicule of the massive falls of teams having paid 2000 pounds to participate, they not only blamed the teams, but instead of announcing that they are going to work hard exclusively to improve the online , because they are dedicated to launching release candidate. They are not working on their own system, but they are not working on improving the servers for future events, which are only for the privileged, since only these can run because they are closed windows. In the end it is true that the gentlemen of Motorsport Games have turned it into a clown show.
Click to expand...

The Le Mans issues happened last week. Surely you know they've been working on the content in this RC for quite a while before that?... Releasing this RC has nothing to do with whether or not they're working on improving those issues.
 
mantasisg said:
Am I the only one having trouble following logic of OP ?
Click to expand...
To sumarize:
The OP is upset that the new Release Candidate did not include any fixes AND major improvements to the online Racing/eSports. Apparently he is under the impression the Q drop was not the result of months & months of work, but expected some sort of hotfix to correct whatever gunked up the 24hr Virtual event.
 
davehenrie said:
To sumarize:

The OP is upset that the new Release Candidate did not include any fixes AND major improvements to the online Racing/eSports. Apparently he is under the impression the Q drop was not the result of months & months of work, but expected some sort of hotfix to correct whatever gunked up the 24hr Virtual event.
Click to expand...
As I said, gibberish!
 
davehenrie said:
Not gibberish, difficult to read due to languages I'll grant you that, but it is WHOLLY and TOTALLY UNREALISTIC expecting first an investigation and then a completely tested and sorted fix in about 1 week.
Click to expand...

Sorry, that's what I meant, the Idea that all his issues could be resolved in an RC tat must have already been months in the making is just nonsense.
 
davehenrie said:
Not gibberish, difficult to read due to languages I'll grant you that, but it is WHOLLY and TOTALLY UNREALISTIC expecting first an investigation and then a completely tested and sorted fix in about 1 week.
Click to expand...
What isn't totally unrealistic is to have a fix ready on Monday morning and for it to still miss a Friday release. People often underestimate how long development work takes. Like in a common workflow it might be:
  1. Someone raises a problem or requirement.
  2. There is AT LEAST one meeting to discuss the requirement and potential solutions.
  3. It gets prioritised in, usually for after a developer or team has wrapped up another piece of work.
  4. The actual work gets done and a request goes out for other team members to review the changes.
  5. Possibly there's feedback from someone in the team which takes us back to step 4 again until everyone is happy.
  6. The work gets merged.
  7. Days before the actual release, regression testing is carried out. This might raise some new bugs or the return of old ones which could need fixing ASAP. Alternatively the fixes could be too lengthy so you might instead rip out the change to try again in a future release once finished.
  8. Around this time I'm guessing Paul Jeffrey here (or someone) might get a list of changes in the release and go about writing something that regular users can read to understand the changes.
  9. Actual release.
I think software gets knocked out pretty quickly really. But people still have to temper what 'pretty quickly' actually is. This thread is an obvious case of over estimating that.
 
This is a possible fix so it doesn't happen again (implementation logic):

If the player is Max Verstappen don't disconnect him ever, and always predict the best outcome for him. If disconnection is inevitable (network issue), use AI at 200% and invulnerability on.

My preferred fix (implementation logic):

Don't invite Max Verstappen and disconnect him as soon as he enters his name. No practice allowed either.

Both fixes are pretty quick to implement, I think.
 
@Owen Pyrah is spot on but... there is one step missing; reproducing the problem.

If the Dev Team can't do this then no matter how many times an issue may raise it's head in real life, they aren't going to be able to come up with a fix. And if they can't break it, then they won't know if their fixes will solve the problem.

I work for a software company and when an issue is reported we have to first establish what is being done, what the environment is ( operating system, hardware, etc. ), test ourselves to get it to go wrong, and then create some notes that we can give to the Dev Team so they can investigate the code.
 
trichens said:
@Owen Pyrah is spot on but... there is one step missing; reproducing the problem.

If the Dev Team can't do this then no matter how many times an issue may raise it's head in real life, they aren't going to be able to come up with a fix. And if they can't break it, then they won't know if their fixes will solve the problem.

I work for a software company and when an issue is reported we have to first establish what is being done, what the environment is ( operating system, hardware, etc. ), test ourselves to get it to go wrong, and then create some notes that we can give to the Dev Team so they can investigate the code.
Click to expand...
So annoying spending hours trying to re-create something and failing, only to turn out it's something to do with their firewall or something. Or something so bizarre it only happens when the stars align. An old colleague used to say "ahh that's a subtle one" when we would find the cause of incidents like that. It's stuck with me because 'subtle' is a good way to describe it.

I think also in this case you have two things sort of out of the devs hands anyway. In terms of what Ruben is talking about.

Firtstly, rF2 give users the tools to setup their own servers. It is up to the user to then host it properly. So in the case of DDoS or whatever, that is infrastructure setup which is out of S397's hands. iRacing have spent years mucking up large events until they finally have a handle on running stable servers. If you want to host an iRacing server you have to rent it directly from iRacing as they don't expose the tools to create your own. On the one hand it's extra money for them. On the other it is maintaining control over the quality of hosting to ensure it's configured properly.

If the problem was DDoS then I really think it's not likely to be an issue for most people. The Le Mans VLMS finale was a huge event and one that would look worthy of attack to some little scrote. So I guess if that was the issue, next time out the server could be better hardened for that race. But likely no actual development needed in rF2 as no one else sees these issues.

Secondly, there was talk about the hour by hour weather scripting plugin having issues. If you want this granular control over weather in an official event - let's face it, the inbuilt scripting is fine for shorter races but maybe too coarse for 24 hours - the current option is to use a third party plugin. So I guess rF2 could try to protect against this for next time by expanding the built in weather scripting? Avoiding the need for the plugin altogether.

But yeah, even in this example I bet it's a time when people are wishing they had more logging to help recreate. You don't want to make a guess and then worry next year if the same thing will repeat.
 
You must log in or register to reply here.
Back
Top