How does that quick opting in and out of beta works? I suppose only few MBs of binaries download and all my settings are preserved (video settings, json tweaks etc...) ?
It's easy filip literally flick of a switch a few gb downloads or whatever the new Content is and way you go. Don't like switch back and original game and settings is restored.
Same as builds now I would say. Your settings files aren't part of the game files, so verifying files or changing builds doesn't affect them.
Bit disappointed with the UI announcement, i thought it might come in beta but at least for all, not in another build, so that means they'll be releasing it in alpha stage probably... i understand why they're releasing it, people are pressing too much, but by this time it should come already in a "ready" state for default use...
@Rujasu yes, I try to avoid the bait by chanting "Serenity now, serenity now," insanity later a few times. It may be a bit before your time.
@Rui Santos I understand your thoughts here. I expected it to be here much sooner than it has been; although I had told my league members not to expect it until 2020. We are very close to that date none the less. The truth of the matter is that they are a small team. ISI used this "excuse" too and it irritates me significantly to have another team use it as and "Excuse" as well. But to be fair, they have come a long way further than ISI from where they began. Especially considering they had to re-write then entire code from scratch because ISI used old code from rF1 and did not correctly build from it. All ISI did was build on the old code instead of making new code. The old code was what was holding rF2 back from becoming a proper modern sim. Frankly it sounds as if it was a spaghetti of code, with one change effecting various other non-related parts. S397 has also release licensed mods (some DLC and some Free Addons) that have been beyond anything we have seen in any sim thus far. The quality of releases have been above reproach in my opinion, even if I dont race the content (Formula-E, Reiza cars, Etc) As frustrated as I am about the slow pace of this rebuild I can't fault S397 too much for having picked up this steaming pile of $h1t and make it into what is expected to be an iRacing competitor. I just wish they would put more people on the task.
I know that mate, i'm one of the members that allways defend S397, but it's about time to get things right, rF2 is taking too long to be "finished" and too many things in "standby". They're losing a bit of momentum here, imagine that AMS2 comes with great features and physics in March, a real simulation, it might be a big problem for S397 plans...
You haven't been coding. All companies build on the existing software stack. Nobody is rewriting code from scratch unless they port over to use a different technology or platform. Software stacks that have been worked on for decades are huge, ISImotor code has probably thousands of work hours behind it, so there is no way to rewrite it in three years even if they tried. A rewrite would be a futile exercise anyway, as most code in ISImotor works perfectly fine, which is why it's licensed to Reiza, SMS and others. C/C++ coding for example is much the same since 1985, it's not like Linus Torvalds one day decided to rewrite his entire Linux kernel code from scratch.
Sometimes the code is so badly written that maintenance costs outweigh rewriting it from scratch. Or when performance is so bad and doesn't scale. Or it's written in write-only language like perl
So the current application is split in two: a Launcher, which is there primarily to interact with Steam to manage content and some basic parameters; and the Sim, which has a UI to manage sessions (select car/track/conditions) and within the session (driving, setups etc.). So the new UI, is going to overlay all this, and it still needs to 'talk' to the underlying sim code. For example, UI has a widget to allow you to change the front spring stiffness, that has to be read from the current value in sim and then 'write' back the update when you increment/decrement the value. What they've struggled with is the interaction between those pieces of code, because the underlying sim code was not 'thread safe'. They've had to find a way to pass data between the two layers; for every single parameter of every thing they want to control in the UI. Just go to the player JSON, and see how many parameters they have within the underlying code. No wonder its taken them a long time. Someone also mentioned Agile, and its one of the things that most grind my gears about how people say you should develop software, in that it applies in all cases. Well, it doesn't. You could imagine a UI where say the change to spring stiffness was possible in NewUI, but damper values only in OldUI. That's what you'd get with Agile, because you have to define the scope of what gets rapidly developed to being able to roll it out. In this case, the size of that is probably ALL car setup values; or ALL session condition values (wind, rain etc.). You could do it so you could do basic wind and rain constant for a session; but now you've lost the ability to have a time-based variation. In this sort of scenario, you end up losing lots of existing functionality until you've replaced it all. That's not what Agile is good for. When SMS did the original PCars, those who contributed could see the entire development cycle, every weekly build. It was fascinating. I can tell you they completely rewrote the UI, 3 times. This wasn't simply a layout change: they completely changed the method of selecting cars/tracks etc. And this was in a monolithic app, not with two very different technology layers. So the question is, what has been the end goal in what they've tried to develop? And someone hit the nail on the head, and said its as a competitor to iRacing. I really think that's what the goal was - online competition, but using the underlying technology they already had. They've already stated when you enable the new 'beta' UI, the underlying server code etc. won't change and they are compatible across both. iRacing have been doing their own 'beta' UI, for at least 2 years. They still don't have all the functionality migrated. They also completely changed the underlying code/middleware that enabled it, because the one they first selected couldn't hack it performance-wise. Chuckle-worthy, its gone from trying to do all that in a single monolithic app, to going back to two components - one a launcher, the other an underlying sim/session code. The garage setup, for example, hasn't changed and isn't HTML-enabled like the launcher and session configuration/selection code. I'm keen to see them complete this part of the coding. This would then free up resources for them to put into overhaul of some of the underlying sim code; but probably, that'll require different resources with different skillsets than the ones who have worked on the UI. And there will still be lots of UI work to be done on the competition side of things (results display and suchlike). Quite frankly taking resources and putting them on projects like the Grand Tour wasn't helpful; it did give them revenue they could point to for the owners, but it really caused RF2 project to get badly delayed.
I very true statement. I dont know anything about coding. I did however read S397's road maps and other information in discord and the forums. This is where I took my information and drew my opinions.
They have re-written the UI from scratch, that was the easy bit. It’s extracting the old UI from the game code and adding in an API for the UI that’s taken all the time. I did something very similar in the phone software you’re all using, inserting APIs round the various subsystems in the stack where interfaces had grown organically* over the years. That involved hundreds of engineers and took two years - even at the end of that there were teams resisting making changes because they were terrified of breaking something. I likened it to doing a major service on an airliner, while it was flying, loaded with passengers! Refactoring rFactor is a much simpler task but S397 have only a fraction of the resources. *Technical term for shit caused by short-term design decisions from software engineers under continual pressure to "Release! Release! Release!"
Yeah, you are probably correct about this, the only point I wanted to make was that nobody is rewriting an entire code base from a software that has been built over 20 years, that would literally take 10 years at least. The graphics engine and UI were probably the major things that they edited as far as rewriting goes. I have a hunch that ISI was more at home with building gMotor engine and everything else they created (content, UI, package system, online interfaces) was let's say not as good, both technically and from user perspective.
...bingo. It's very easy to criticise someone else's work when you're not actually part of the process. Unless people on this forum have an intimate understanding of exactly what the developers have been working on, how large the scope is and technical details of _all_ of the problems, dependencies and inter related issues that have cropped up as a result of that, not to mention how much testing is required and the feedback from that testing - well you're pretty much just guessing and making uninformed comments. That might sound harsh, but it's the reality of it. I have worked my entire career in IT technical support, which does not involve coding and program development, but even with the project work I have done (some of it has been global in scope and for large government organisations), you quickly learn you can't please everyone, nothing is ever done fast enough and you will always get flak from people who are not involved. My advice to people is appreciate what you have got and when updates come, be thankful. Also try and think about things from the perspective of the people who are actually doing the work. How much do you understand exactly what they are doing and the problems they have had ? I really like the direction Studio 397 is going with development work. My 2 cents worth is I'd rather have them release things slowly, that have been well tested, than rush things and have issues.
I’ll bet that they didn’t realise what a ball-ache it was going to turn out to be, I mean, it sounds so simple, doesn’t it? Unstitch the old UI from the code and graft in the new one with a clean API. "Yeah, there’ll be a few gotchas along the way but we’ve scoped it out in a lot of detail and it’s do-able..."
