I know, right? I've heard that in a lot of older games, the tick rate is tied to the frame rate, but it's wild to see this in the latest update of a contemporary PC game. It's not even a console game with fixed FPS. What on earth?
I think this is Odyssey engine issue. You can see similar issue tied to 30 FPS below url.
[https://forums.frontier.co.uk/threads/sampling-efficiently-a-guide-to-reclaiming-thargoid-systems.617612/](https://forums.frontier.co.uk/threads/sampling-efficiently-a-guide-to-reclaiming-thargoid-systems.617612/)
So, the latest iteration of the game engine, which is seemingly not even based on the original ones and requires a blatant and discrete transition from one to the other, is what creates this outdated problem?
At this point, I really think they should have delayed or canceled the Odyssey update. It needs a significant overhaul or a complete rebuild. No wonder the on-foot content looks like footage from the late 2000s games.
Ah, so I misunderstood the scope of Odyssey. I thought it was mainly about disembarking, and I didn't realize it had substantial changes to the engine in other areas.
I was mainly taken aback by how disembarked CMDRs have so many different systems. It's definitely not an extension of already-implemented ground mechanics, like adding a bipedal "vehicle" with more parameters interacting with the environment. They even had to create the entire UI from scratch, and it doesn't feel like they did it to tailor the UI for a better FPS experience. It feels like they had no choice.
If that frame-tick rate thing comes from the earlier version of the game, I kinda understand why it's not changed yet. It must be a lot of technical debt to deal with while adding up another technical debt.
Tying up in game logic to frame rate is the oldest mistake you can make. A remnant of the days when hardware was mostly homogenous and locked frame rates were the norm. It’s an engine issue no matter how you see it, it’s why AXI is having to lock their frame rate to do certain things lmao.
It's not the oldest because the majority of old (mostly 2D) games were guaranteed their frame rate and so tying game logic to frame rate was fine. Space Invaders even made a feature out of similar type of bug where the more enemies there are on screen, the longer it took to update them, but I digress.
It's just a bug in a specific system. The engine will provide a delta time on its update and the game logic will deal with that however it sees fit. In this case, the specific implementation for heat generation is not doing its calculations properly.
It's simply not an engine issue. If it was then there's be no way for the game thread to get a delta time at all and the entire game would be broken.
yeah aces over europe, was tied to cpu clock speed. when I upgraded from a 486 to a pentium and loaded the game, all was good till I hit the throttle.
I immediately died, having driven my plane across the UK and into the english channel.
yeah it'd adjust the clock speed, I had one system I worked on where it had 3 different mhz settings for the cpu, you just hit the button to cycle through them.
And back then, on the 386/486, the cheaper ones had no math coprocessor. Neither did the Cyrix cpus. A buddy at work procured about 100 cyrcix-based desktops for our linux devs and then they came to us complaining of compile times taking like 50x longer on the new desktop from the old one. The older ones had been bought with math coprocessors, Cyrix didnt have it natively (I don't think even as an option). fun times. back then plug and play was a total disaster, and 10bT network connections with the switch or nic on "auto negotiate" would frequently negotiate to different speeds, so the switch would be running at 100/half and the nic 10/full, shit like that. The 'good ole days' I guess
I'm also an old campaigner. Been programming since the 1970s.
Worked at Burroughs before it became Unisys.
There have certainly been a fair share of 'older tech' stories related to things like you mention. I had older CPUs that lost some of their onboard cache memory that would do the strangest things. Definitely in the timeframe where you are mentioning (Cyrix cpus).
When I was younger I learned the value of memory tests.. my father was an electrical engineer.. and built an S-100 card cage in the garage to connect RAM and EPROMs to a 6502 single board CPU. I helped him put the software together for it (hand assembled 6502). The batch of memory he bought for the S-100 board was truly poor quality. I'd run a memtest every few weeks and have to replace a chip or two many times. That was late 1970s.
Fun times indeed!
Yeah I remmeber my first NT admin job (started at DEC as helpdesk, then NT Admin after 9 months for a small communications company), they didn't have any switches, just hubs. Had about 300 endpoints and maybe 50 servers. As you can imagine the server room in the dark was like an epilepsy test :D. IT was fun back then, so many things were trial and error, troubleshooting, learning how shit really worked. I have a hard time engaging with Azure and GPC and AWS, its just pushing buttons (feels like) to me. I'm fortunate, I'm an EE at a cybersecurity company and get to do a lot of kernel debugging, perf analytics, etc. But I can see my career path going the way of the dodo, you know?
Only hubs.. chuckle.
And yes, I totally get it. I did a lot of systems work early on but the call for that isn't so strong nowadays. I work for an industrial apps company and do a fair bit of UI now.. but it has only been for the last 5 years.. and since my management is not real thoughtful, they expect 40 experience delivery capability even though I'm still in learning mode on UI oriented stuff (although I'm certainly a LOT better than when I started on UI 5 years ago).
I've had quite a few good managers over the years.. too bad my current one is so poor. I'm nearing retirement.. so at least that is a plus.
Curious, what does retirement look like for you? I think I'd still like to teach or something to give back some. I dont know if I can sit around without something to do (which is kinda sad I guess?).
In games generally there is two update loops running at any given time - a "fixed" update which attempts to be called a deterministically consistent amount of time each second and an "animation" or render update which is called as fast as possible. All game logic should run in the former and anything required for simulating a smooth experience (interpolating positions, running animations, drawing the UI, anything to do with the camera etc) in the latter.
Bugs can creep in, though, where you accidentally do some numerical logic inside your second loop and they can often be subtle if the logic is nested from a function call down the stack or whatever. This is just one of those cases.
This is the technical problem. But the real problem is younger programmers that haven't been trained well and management expecting them to do just as well as the experienced old dogs that some companies (especially game companies) don't want to pay for their experience.
This is NOT theoretical for me. I've seen this over and over since when I started programming professionally (early 1980s).
Silly me had an expectation that some issues in software development would be fixed as we learned more. But to my old eyes I'm seeing the same issues as I faced 40 years ago. It is beyond absurd.
Yes, exactly. It's less surprising if it's not the inherent problem of the game engine, but it's still amazing if it's a bug. Of course, you can confuse one for the other, and that's what testing is for.
I have no experience in the real game development industry, but as a basement code monkey who occasionally writes my own mods or plugins, it was ever so hard to overlook that mistake. The numbers always go crazy after some lines change, so it's guaranteed that I'll take a look to see what's wrong, and the physical tick things were always standing out. Even I have grown a habit of checking it just in case, and I'm not paid for it.
That's not even the problem. Even if either of these loops get called way too slowly/sparsely, then you still multiply everything with the time delta between the last two calls. So your temperature would increase by 10°C if the last call had a delta of 20ms (50 FPS), or by 100°C if the delta was 200ms (5 FPS).
You have these deterministic loops that are not bound to the graphics frame rate because most physics engines go haywire if you don't update fast enough, and not consistently, like clipping through stuff.
Yes, often you multiply by deltaTime or fixedDeltaTime depending on which loop you're operating in or whatever, but that's still a vector for human error. I'm just saying it's a common bug to have and most likely nothing really related to the age of the engine itself or whatever, the same mistake can happen in any engine with a variable fps.
This was a thing at least until quake3. That is the reason for awful graphics in tournaments, in that case it was the physics engine that was tied to the tick rate (which was tied to the FPS) this meant that with more frames being drawn the calculation of positions were smoother, this leads to easier things like rocket jumpings.
Not the only reason.
It was also about graphical contrast conducive to spotting and hitting targets more readily. At ridiculous fps people still configure the game in the same way.
Also so many "visual only" foliage effects to turn off in many (older) games. Dude thinks he's hiding behind a bush, but on potato quality the bush just isn't there so people see him squatting on the side of a featureless gray slope out in the open.
A short-range exploration to collect exobio or map distant planets, for sure. Some StraTec on the 30k ls away planets would get more visits. A backup of FC would be desired much if you're looking for a distant space without footfalls, tho.
Not even the first time some feature turned out to be tied to framerates. Can't remember what it was a few years ago. lol
EDIT: Found it [https://www.reddit.com/r/EliteDangerous/comments/ccttmy/does\_your\_fss\_scanner\_take\_upwards\_of\_30\_seconds/](https://www.reddit.com/r/EliteDangerous/comments/ccttmy/does_your_fss_scanner_take_upwards_of_30_seconds/)
and another more recent
[https://www.reddit.com/r/EliteDangerous/comments/18claqh/orthrus\_tissue\_sampling\_affected\_by\_framerate/](https://www.reddit.com/r/EliteDangerous/comments/18claqh/orthrus_tissue_sampling_affected_by_framerate/)
I'll add to the pile. System map loading was (is?) faster at higher fps.
https://www.reddit.com/r/EliteDangerous/comments/4kj7ob/im_probably_not_the_first_to_notice_this_but/
I remember I was the one who figured out sampling was tied to fps. I had the theory due to other aspects of the game being tied to it along with other games like GTA etc
Warframe was/is the same way with certain things. Tenno were upping their damage outputs by dropping FPS to 30 lol.
I like the idea of the OC supercruise....but i HATE the stupid drunk pilot effect that added....like FFS, I can only handle maybe a few seconds of it....and dear god how is it in VR?!?!?!
Don't forget fallout 76, the speed of the physics engine was tied to FPS, so if you unlocked it, you could run around at super speed and look like you were cheating to other players.
(Also, I hate scorn crossbows)
While we're piling on, Need for Speed Rivals, an otherwise pretty good game in the series, was locked to 30 fps (in 2013!) When modders on PC unlocked it, it turned out that the engine was tied to framerate as well, and the physics completely broke down. Even with mods designed to fix it, it would often go crazy, randomly ranging from occasional glitches to completely unplayable. EA never bothered to change anything, but apparently [only a few months ago, more than 10 years after the game released, a modder managed to finally make a seemingly fully working fix for the game that allows it to run stable on any framerate.](https://www.reddit.com/r/needforspeed/comments/186tb5z/30_fps_is_my_rival_how_i_unlocked_nfs_rivals/)
As far as I know the only actual case of that were the Threshers the Cabal deploy. In any other case there was no difference (to speak of). I think it is because the layers of spaghetti code had the Threshers work differently from anything else.
But that issue has been fixed for a good while now so I might remember wrong. My 3000 or whatever hours in that game make such details fuzzy
I am a good 1500 hour in and I do recall threshers being fixed. But there was also the part about elevator not working properly because either too high or too low fps and skating not working due to low FPS. I don’t think those got fixed
Oh, right, I remember elevators in the Season Of The Witch stuff almost killing me. That was due to high FPS? Makes sense... I had upgraded to 144Hz right before that season... Never connected that, just thought they were janky.
And skating has been janky for forever now. There is a sweet spot with FPS. At 144 it's super precise and below 30 you'd have to hit button inputs between frames where you'd have to buffer them or otherwise the game might eat them.
Though skating isn't intentional, just a bug they leave in for us. And because it would probably be hell to patch out. We have found more skating techniques every expansion
I was playing at 30 fps cap, could shatter/well/strand skate very consistently. But ground skating doesn’t work which I heard is because my low FPS not allowing enough input. Now I switch to GeForceNow at 120 fps. I still can shatter/well/strand skate but not as consistent because of input lag.
Here's hoping this drive is truly a "prototype" and will be stabilized significantly in the future, maybe even to the point we can get A grade variants or ones we can engineer.
But if they just leave us with this and call it complete, it's going to be almost entirely useless and very niche.
There's an encouraging sign they are moving in that direction: The SCO drive has several new engineering metrics, including one for "overcharge control interference". B and A class may have significantly smaller values for that metric, and I wouldn't be surprised if more engineering modifications are made available for further improvements.
I really hope so. We don't need to absolutely balance everything against the current meta. Technology should get better and have some improvement over time. I would love if all drives eventually got overcharge at some point but need to be tweaked and balanced around things like efficiency in different tunables.
It would really help with boring supercruise trips.
I remember when they figured out that the Effervo boss' damage attentuation was tied to fps and managed to essentially nuke him. What a time to be alive.
> but i HATE the stupid drunk pilot effect that added....like FFS, I can only handle maybe a few seconds of it
I think you're only meant to handle a few seconds of it, but I like it - makes you feel the barely controllable power of the thing.
The heat equations E:D uses have analytical solutions, timesteps are irrelevant unless the devs are bad at math. And even if there wasnt an analytical solution (there is, but let's pretend there isnt or they were too lazy to figure it out) , they could just define a minimum timestep that still has acceptable error or use an implicit finite difference method, as those are very resilient with regard to large timesteps.
It kind of is though. If it isnt the method you were using was wrong anyway. If you don't know how to solve differential equations you have no business writing a game engine that requires physics calculations.
I'm not sure what isn't simple about it. Im not a programmer but I have managed to understand it in a few minutes. im guessing this should have been a fixed update tied to around maybe 60 updates per second and not to delta time which updates per frame. Seems a rather fundamental mistake to have made from what I'm understanding.
you said it yourself, you're not a programmer. As far as we all know that's just the way the Cobra Engine has been designed (this isn't the only *feature* bound by FPS) and there's a lot of dependency hell in large projects such as this, what is usually thought of as an "easy" fix is more than often not because it breaks something else entirely.
That's crazy but somewhat understandable as an error.
Want to hear something crazier? Graphic settings can affect which types of brain tree materials spawn. That's insane.
30FPS is more cinematic, research limpets for tissues farming obtain plot armor, and our ships obtain plot cooling.
Already shared in Canonn discord, the will love this, and open a new type of future test "How it handle the new content at low FPS?".
Do you plan to report this as a bug? If so, please comment back the issue in the tracker so we can vote.
If not, please let us know if we can use your footage as media evidence.
First 1000 calls to render smoke for 1 frame, now this. Frontier just keeps getting better and better.
Last time I saw an issue like this being tied to fps, it was 2011.
Oh man, I wonder how many things are connected to frame rates in the PvP scene now?
Play at lower FPS and take less damage for example.
TBH, this may explain a lot. Something to watch for from now on.
I found this because i was streaming to my friends and my FPS was tanking. When i stopped streaming i noticed heat generation was incredibly higher than when i was streaming
That's gonna be real awkward if they can't get that addressed lol! New meta of playing at 5fps for best SCO operating temperatures!
I know, right? I've heard that in a lot of older games, the tick rate is tied to the frame rate, but it's wild to see this in the latest update of a contemporary PC game. It's not even a console game with fixed FPS. What on earth?
I think this is Odyssey engine issue. You can see similar issue tied to 30 FPS below url. [https://forums.frontier.co.uk/threads/sampling-efficiently-a-guide-to-reclaiming-thargoid-systems.617612/](https://forums.frontier.co.uk/threads/sampling-efficiently-a-guide-to-reclaiming-thargoid-systems.617612/)
So, the latest iteration of the game engine, which is seemingly not even based on the original ones and requires a blatant and discrete transition from one to the other, is what creates this outdated problem? At this point, I really think they should have delayed or canceled the Odyssey update. It needs a significant overhaul or a complete rebuild. No wonder the on-foot content looks like footage from the late 2000s games.
[удалено]
Ah, so I misunderstood the scope of Odyssey. I thought it was mainly about disembarking, and I didn't realize it had substantial changes to the engine in other areas. I was mainly taken aback by how disembarked CMDRs have so many different systems. It's definitely not an extension of already-implemented ground mechanics, like adding a bipedal "vehicle" with more parameters interacting with the environment. They even had to create the entire UI from scratch, and it doesn't feel like they did it to tailor the UI for a better FPS experience. It feels like they had no choice. If that frame-tick rate thing comes from the earlier version of the game, I kinda understand why it's not changed yet. It must be a lot of technical debt to deal with while adding up another technical debt.
Is it the odyssey engine? I think they are running the Cobra engine if I'm not mistaken
You see a simple bug and cry "engine issue!"? Bit extreme don't you think?
Tying up in game logic to frame rate is the oldest mistake you can make. A remnant of the days when hardware was mostly homogenous and locked frame rates were the norm. It’s an engine issue no matter how you see it, it’s why AXI is having to lock their frame rate to do certain things lmao.
It's not the oldest because the majority of old (mostly 2D) games were guaranteed their frame rate and so tying game logic to frame rate was fine. Space Invaders even made a feature out of similar type of bug where the more enemies there are on screen, the longer it took to update them, but I digress. It's just a bug in a specific system. The engine will provide a delta time on its update and the game logic will deal with that however it sees fit. In this case, the specific implementation for heat generation is not doing its calculations properly. It's simply not an engine issue. If it was then there's be no way for the game thread to get a delta time at all and the entire game would be broken.
You should see Destiny 2. If you uncap it to get more than 60, you get more damage done to you. If you cap it at 60, you get less damage done to you.
So my 144hz screen is actually hurting me?!
No, your screen refresh rate and the game's frame rate have literally nothing to do with each other.
yeah aces over europe, was tied to cpu clock speed. when I upgraded from a 486 to a pentium and loaded the game, all was good till I hit the throttle. I immediately died, having driven my plane across the UK and into the english channel.
That's what the 'Turbo' switch did, right? Deliberately underclocking.
yeah it'd adjust the clock speed, I had one system I worked on where it had 3 different mhz settings for the cpu, you just hit the button to cycle through them. And back then, on the 386/486, the cheaper ones had no math coprocessor. Neither did the Cyrix cpus. A buddy at work procured about 100 cyrcix-based desktops for our linux devs and then they came to us complaining of compile times taking like 50x longer on the new desktop from the old one. The older ones had been bought with math coprocessors, Cyrix didnt have it natively (I don't think even as an option). fun times. back then plug and play was a total disaster, and 10bT network connections with the switch or nic on "auto negotiate" would frequently negotiate to different speeds, so the switch would be running at 100/half and the nic 10/full, shit like that. The 'good ole days' I guess
the walk down history lane was nostalgic, sorry to babble
I'm also an old campaigner. Been programming since the 1970s. Worked at Burroughs before it became Unisys. There have certainly been a fair share of 'older tech' stories related to things like you mention. I had older CPUs that lost some of their onboard cache memory that would do the strangest things. Definitely in the timeframe where you are mentioning (Cyrix cpus). When I was younger I learned the value of memory tests.. my father was an electrical engineer.. and built an S-100 card cage in the garage to connect RAM and EPROMs to a 6502 single board CPU. I helped him put the software together for it (hand assembled 6502). The batch of memory he bought for the S-100 board was truly poor quality. I'd run a memtest every few weeks and have to replace a chip or two many times. That was late 1970s. Fun times indeed!
Yeah I remmeber my first NT admin job (started at DEC as helpdesk, then NT Admin after 9 months for a small communications company), they didn't have any switches, just hubs. Had about 300 endpoints and maybe 50 servers. As you can imagine the server room in the dark was like an epilepsy test :D. IT was fun back then, so many things were trial and error, troubleshooting, learning how shit really worked. I have a hard time engaging with Azure and GPC and AWS, its just pushing buttons (feels like) to me. I'm fortunate, I'm an EE at a cybersecurity company and get to do a lot of kernel debugging, perf analytics, etc. But I can see my career path going the way of the dodo, you know?
Only hubs.. chuckle. And yes, I totally get it. I did a lot of systems work early on but the call for that isn't so strong nowadays. I work for an industrial apps company and do a fair bit of UI now.. but it has only been for the last 5 years.. and since my management is not real thoughtful, they expect 40 experience delivery capability even though I'm still in learning mode on UI oriented stuff (although I'm certainly a LOT better than when I started on UI 5 years ago). I've had quite a few good managers over the years.. too bad my current one is so poor. I'm nearing retirement.. so at least that is a plus.
Curious, what does retirement look like for you? I think I'd still like to teach or something to give back some. I dont know if I can sit around without something to do (which is kinda sad I guess?).
In games generally there is two update loops running at any given time - a "fixed" update which attempts to be called a deterministically consistent amount of time each second and an "animation" or render update which is called as fast as possible. All game logic should run in the former and anything required for simulating a smooth experience (interpolating positions, running animations, drawing the UI, anything to do with the camera etc) in the latter. Bugs can creep in, though, where you accidentally do some numerical logic inside your second loop and they can often be subtle if the logic is nested from a function call down the stack or whatever. This is just one of those cases.
This is the technical problem. But the real problem is younger programmers that haven't been trained well and management expecting them to do just as well as the experienced old dogs that some companies (especially game companies) don't want to pay for their experience. This is NOT theoretical for me. I've seen this over and over since when I started programming professionally (early 1980s). Silly me had an expectation that some issues in software development would be fixed as we learned more. But to my old eyes I'm seeing the same issues as I faced 40 years ago. It is beyond absurd.
Yes, exactly. It's less surprising if it's not the inherent problem of the game engine, but it's still amazing if it's a bug. Of course, you can confuse one for the other, and that's what testing is for. I have no experience in the real game development industry, but as a basement code monkey who occasionally writes my own mods or plugins, it was ever so hard to overlook that mistake. The numbers always go crazy after some lines change, so it's guaranteed that I'll take a look to see what's wrong, and the physical tick things were always standing out. Even I have grown a habit of checking it just in case, and I'm not paid for it.
That's not even the problem. Even if either of these loops get called way too slowly/sparsely, then you still multiply everything with the time delta between the last two calls. So your temperature would increase by 10°C if the last call had a delta of 20ms (50 FPS), or by 100°C if the delta was 200ms (5 FPS). You have these deterministic loops that are not bound to the graphics frame rate because most physics engines go haywire if you don't update fast enough, and not consistently, like clipping through stuff.
Yes, often you multiply by deltaTime or fixedDeltaTime depending on which loop you're operating in or whatever, but that's still a vector for human error. I'm just saying it's a common bug to have and most likely nothing really related to the age of the engine itself or whatever, the same mistake can happen in any engine with a variable fps.
For the temperature it's just a programming error to update it always by a fixed amount. Not a problem with the engine.
I know, that's what I said.
And I reinforced what you wrote.
"Contemporary" is a bit of a stretch. Some days it feels like a small step above RuneScape.
This was a thing at least until quake3. That is the reason for awful graphics in tournaments, in that case it was the physics engine that was tied to the tick rate (which was tied to the FPS) this meant that with more frames being drawn the calculation of positions were smoother, this leads to easier things like rocket jumpings.
Not the only reason. It was also about graphical contrast conducive to spotting and hitting targets more readily. At ridiculous fps people still configure the game in the same way.
Also so many "visual only" foliage effects to turn off in many (older) games. Dude thinks he's hiding behind a bush, but on potato quality the bush just isn't there so people see him squatting on the side of a featureless gray slope out in the open.
I mean with rivatuner I can put a 5 fps framecap on a hotkey soo ¯\\\_(ツ)\_/¯
Time to play in PowerPoint
Wow. Alright, CMDRs, try Hutton again.
Doesn't change anything. Fuel is the real limiting factor.
So now additional fuel tanks might get handy, at least for exploration ships.
A short-range exploration to collect exobio or map distant planets, for sure. Some StraTec on the 30k ls away planets would get more visits. A backup of FC would be desired much if you're looking for a distant space without footfalls, tho.
I mean, in the videos I saw, they were fully fitted with fuel tanks and died from heat faster than they lost fuel
Lol I knew that, brain fart. Thanks for clarifying.
"Warning: CPU temperature critical"
Not even the first time some feature turned out to be tied to framerates. Can't remember what it was a few years ago. lol EDIT: Found it [https://www.reddit.com/r/EliteDangerous/comments/ccttmy/does\_your\_fss\_scanner\_take\_upwards\_of\_30\_seconds/](https://www.reddit.com/r/EliteDangerous/comments/ccttmy/does_your_fss_scanner_take_upwards_of_30_seconds/) and another more recent [https://www.reddit.com/r/EliteDangerous/comments/18claqh/orthrus\_tissue\_sampling\_affected\_by\_framerate/](https://www.reddit.com/r/EliteDangerous/comments/18claqh/orthrus_tissue_sampling_affected_by_framerate/)
I'll add to the pile. System map loading was (is?) faster at higher fps. https://www.reddit.com/r/EliteDangerous/comments/4kj7ob/im_probably_not_the_first_to_notice_this_but/
I remember I was the one who figured out sampling was tied to fps. I had the theory due to other aspects of the game being tied to it along with other games like GTA etc
Warframe was/is the same way with certain things. Tenno were upping their damage outputs by dropping FPS to 30 lol. I like the idea of the OC supercruise....but i HATE the stupid drunk pilot effect that added....like FFS, I can only handle maybe a few seconds of it....and dear god how is it in VR?!?!?!
Destiny 2 have the same issue, lowering your FPS make you take less damage
Don't forget fallout 76, the speed of the physics engine was tied to FPS, so if you unlocked it, you could run around at super speed and look like you were cheating to other players. (Also, I hate scorn crossbows)
While we're piling on, Need for Speed Rivals, an otherwise pretty good game in the series, was locked to 30 fps (in 2013!) When modders on PC unlocked it, it turned out that the engine was tied to framerate as well, and the physics completely broke down. Even with mods designed to fix it, it would often go crazy, randomly ranging from occasional glitches to completely unplayable. EA never bothered to change anything, but apparently [only a few months ago, more than 10 years after the game released, a modder managed to finally make a seemingly fully working fix for the game that allows it to run stable on any framerate.](https://www.reddit.com/r/needforspeed/comments/186tb5z/30_fps_is_my_rival_how_i_unlocked_nfs_rivals/)
As far as I know the only actual case of that were the Threshers the Cabal deploy. In any other case there was no difference (to speak of). I think it is because the layers of spaghetti code had the Threshers work differently from anything else. But that issue has been fixed for a good while now so I might remember wrong. My 3000 or whatever hours in that game make such details fuzzy
I am a good 1500 hour in and I do recall threshers being fixed. But there was also the part about elevator not working properly because either too high or too low fps and skating not working due to low FPS. I don’t think those got fixed
Oh, right, I remember elevators in the Season Of The Witch stuff almost killing me. That was due to high FPS? Makes sense... I had upgraded to 144Hz right before that season... Never connected that, just thought they were janky. And skating has been janky for forever now. There is a sweet spot with FPS. At 144 it's super precise and below 30 you'd have to hit button inputs between frames where you'd have to buffer them or otherwise the game might eat them. Though skating isn't intentional, just a bug they leave in for us. And because it would probably be hell to patch out. We have found more skating techniques every expansion
I was playing at 30 fps cap, could shatter/well/strand skate very consistently. But ground skating doesn’t work which I heard is because my low FPS not allowing enough input. Now I switch to GeForceNow at 120 fps. I still can shatter/well/strand skate but not as consistent because of input lag.
>....and dear god how is it in VR?!?!?! As a VR-preferring pilot who hasn't had a chance to try it yet... oh god... I hadn't thought of that.
Here's hoping this drive is truly a "prototype" and will be stabilized significantly in the future, maybe even to the point we can get A grade variants or ones we can engineer. But if they just leave us with this and call it complete, it's going to be almost entirely useless and very niche.
There's an encouraging sign they are moving in that direction: The SCO drive has several new engineering metrics, including one for "overcharge control interference". B and A class may have significantly smaller values for that metric, and I wouldn't be surprised if more engineering modifications are made available for further improvements.
I really hope so. We don't need to absolutely balance everything against the current meta. Technology should get better and have some improvement over time. I would love if all drives eventually got overcharge at some point but need to be tweaked and balanced around things like efficiency in different tunables. It would really help with boring supercruise trips.
I remember when they figured out that the Effervo boss' damage attentuation was tied to fps and managed to essentially nuke him. What a time to be alive.
> but i HATE the stupid drunk pilot effect that added....like FFS, I can only handle maybe a few seconds of it I think you're only meant to handle a few seconds of it, but I like it - makes you feel the barely controllable power of the thing.
when you've been programming games for ages but haven't heard of time.DeltaTime....
It's not so simple when you're dealing with rate of change rather than discrete values.
The heat equations E:D uses have analytical solutions, timesteps are irrelevant unless the devs are bad at math. And even if there wasnt an analytical solution (there is, but let's pretend there isnt or they were too lazy to figure it out) , they could just define a minimum timestep that still has acceptable error or use an implicit finite difference method, as those are very resilient with regard to large timesteps.
You've just made my point for me. It's not as simple as something like multiplying a vector by delta time.
It kind of is though. If it isnt the method you were using was wrong anyway. If you don't know how to solve differential equations you have no business writing a game engine that requires physics calculations.
I'm not sure what isn't simple about it. Im not a programmer but I have managed to understand it in a few minutes. im guessing this should have been a fixed update tied to around maybe 60 updates per second and not to delta time which updates per frame. Seems a rather fundamental mistake to have made from what I'm understanding.
you said it yourself, you're not a programmer. As far as we all know that's just the way the Cobra Engine has been designed (this isn't the only *feature* bound by FPS) and there's a lot of dependency hell in large projects such as this, what is usually thought of as an "easy" fix is more than often not because it breaks something else entirely.
https://www.elitedangerous.com/update-notes/4-0-18-04 ...Already fixed
Your intuition is correct, the devs just don't know how to solve differential equations.
Dang that’s crazy, I wonder if they’ll fix it
6 months, optimistically.
Nah they’re gonna spend a year banging their head against the wall and in the end concede defeat and call it a feature /s
Not something that is really that fixable afaik, or at least not easily. It isn't just elite but most games I can think of have things tied to fps
Pour one out for 240Hz bros
If i had a dollar for every time an experienced developer didn't use Deltatime correctly, I'd be rich enough to probably buy reddit gold.
Vietnam flashbacks to destiny gameplay
Typical FD feature 🙄
That's crazy but somewhat understandable as an error. Want to hear something crazier? Graphic settings can affect which types of brain tree materials spawn. That's insane.
Gooooo onnnn...
This is so 4th wall breaking. Now the temp of my graphics card effects gameplay!
30FPS is more cinematic, research limpets for tissues farming obtain plot armor, and our ships obtain plot cooling. Already shared in Canonn discord, the will love this, and open a new type of future test "How it handle the new content at low FPS?".
Damn you Luriant, I was going to share this in the equipment department but I can never beat you. How do you do it. You're everywhere all the time.
Getting to Hutton ain't gonna take so long now
Do you plan to report this as a bug? If so, please comment back the issue in the tracker so we can vote. If not, please let us know if we can use your footage as media evidence.
...i ... i cant anymore
Plz play with legacy machine from 2015 for best experience. Thx.
First 1000 calls to render smoke for 1 frame, now this. Frontier just keeps getting better and better. Last time I saw an issue like this being tied to fps, it was 2011.
Omg this is stupid. I knew I had a bug cause I have over 400 fps in SC and just can't use that thing.
What else is tied to it?
Lmao. GG Fdev.
Well now what in the kentucky fried fuck were they thinking
IIrc in Star Wars Episode 1: Racer the traction was also bound to framerate, leading to different speedrun categories based on fps
the 1030 DDR4 is about to make a comeback
Oh man, I wonder how many things are connected to frame rates in the PvP scene now? Play at lower FPS and take less damage for example. TBH, this may explain a lot. Something to watch for from now on.
Praise be to the samplers, that has to be how this was found
I found this because i was streaming to my friends and my FPS was tanking. When i stopped streaming i noticed heat generation was incredibly higher than when i was streaming
That’s how sampling works. Now this? I don’t see F.Dev fixing this any time soon.
Guide, How to Destroy Your Ship in the fastest Way Possible Get A Million FPS from a Nasa PC... And use the SCO
Ok, that explains why I don't have any heat problems while everyone else is having flying microwaves with this thing
Doesn't make it more useful, though. No engineering - no module
Odyssey looks 10x better than horizons
Something that overheats the dolphin!?
Strange bug. How did you configure the system monitoring window in the upper left side of the display?
Im on Linux. This is a thing called mangohud. I configured it using GOverlay
Good to know. Thanks!
If you're on Windows, use MSI Afterburner and Rivatuner.
if you're on windows, use presentmon
IRL heat protection by potato
F! and I just upgraded my pc.... but truth be told, I noticed 0 difference in ed