Ouch!Hi All
Heh!....I win!... I'm still using my Geforce 1060 3gb to play this game(I've got a better gpu card, just haven't installed it yet on a new build)
Jack
Curious FDev decision(New FSD)
- Thread starter Bob McBobblehead
- Start date
So if I'm reading this right, if I plug my GT 1030 in, change my CPU speed to super conservative values I'll go so fast with SCO I might time travel to U19s release?
Well, that is one of the problems with superluminal travel...
If you do, can you come back and let me know what module slots the Python MK2 has got? I've been collecting mats for engineering and would like to know if I've covered everything.So if I'm reading this right, if I plug my GT 1030 in, change my CPU speed to super conservative values I'll go so fast with SCO I might time travel to U19s release?
You'll almost travel as fast CMDR Thrust from Bradford. He reputedly says Update 19 is good.So if I'm reading this right, if I plug my GT 1030 in, change my CPU speed to super conservative values I'll go so fast with SCO I might time travel to U19s release?
You need a PC with a Turbo button. 4.77Mhz goodness.So if I'm reading this right, if I plug my GT 1030 in, change my CPU speed to super conservative values I'll go so fast with SCO I might time travel to U19s release?
The most powerful answer is to decouple the physics engine from the render engine. The challenge is that's really very difficult to implement in practice so as someone else pointed out, a LOT of games have things dependent on framerate and then find unexpected complexities lead to unexpected outcomes.
So... yes, to keep things fair, fix the engine at a framerate which is also a decent compromise with however you are handling netcode and however you are handling runaway rounding errors, and the other problems you get into with numerical methods for physics.
The meta at the moment is to not only have the core physics engine locked for fairness but also have discretionary parts of the sim run faster for better accuracy locally and tie that in to the general clock as appropriate.
So... yes, to keep things fair, fix the engine at a framerate which is also a decent compromise with however you are handling netcode and however you are handling runaway rounding errors, and the other problems you get into with numerical methods for physics.
The meta at the moment is to not only have the core physics engine locked for fairness but also have discretionary parts of the sim run faster for better accuracy locally and tie that in to the general clock as appropriate.
It does not, it merely ties it to some sort of rolling average of frametime, unless you are proposing that every frame looks at how far off the previous frame was and back-corrects, which is a good way to start building correction errors on top of the errors...
If you make it frame-rate agnostic first and then factor it per render frame then yes, that helps, but that is a lot harder than it sounds, and the only real way to do that is what I said in my other comment just now.
Greetings from the future!
The special feature of the Python Mk2 is that is a hologram over an Asp Scout.
I did some confirmatory testing in the other thread.
forums.frontier.co.uk
forums.frontier.co.uk
GALNET - Prototype Frame Shift Drive almost production ready, competitor sceptical - 04 APR 3310
I would take my Courier over it any day. It is an amazing little ship. I have 1 very fast Courier - the others are tailored for different purposes so may be as slow as 600 m/s
GALNET - Prototype Frame Shift Drive almost production ready, competitor sceptical - 04 APR 3310
SCO heat generation is tied to fps. Try it on 30, and you will be surprised how effective it is. I wish it was easy to tell if this was a joke or not.
Here's another quick test:I did some confirmatory testing in the other thread.
GALNET - Prototype Frame Shift Drive almost production ready, competitor sceptical - 04 APR 3310
I would take my Courier over it any day. It is an amazing little ship. I have 1 very fast Courier - the others are tailored for different purposes so may be as slow as 600 m/s
GALNET - Prototype Frame Shift Drive almost production ready, competitor sceptical - 04 APR 3310
SCO heat generation is tied to fps. Try it on 30, and you will be surprised how effective it is. I wish it was easy to tell if this was a joke or not.
Only 1 ship, and two of the test runs (the 45 fps and the uncapped fps one) happened in the exact same circumstances (same amount of fuel, nearly same postition in space etc).
So it's a specialist drive for scout samplers...
Well at least we can control the heat better now.
I think I'll pass on the 30 FPS just to get a few extra seconds of hypercruise time, when I don't need them that much in most scenarios. Works better to keep it active in shorter intervals and cut down on the fuel use anyway.
... also found that a (shieldless) Krait MKII with a G4 LE/monstered powerplant can drop a heatsink and hold itself at 0% heat with the overcharge active. At least with the setup I had when I decided to run that decidedly non-scientific test.
... also found that a (shieldless) Krait MKII with a G4 LE/monstered powerplant can drop a heatsink and hold itself at 0% heat with the overcharge active. At least with the setup I had when I decided to run that decidedly non-scientific test.
...and don't forget to plug in that math coprocessor!
I checked at 30, 60 and 90 fps and Bob is right.
Heat generation is directly proportional to fps...
Is there an issue ticket for it? I would upvote.
(edit)
There is a ticket, but it does not load for me. I would definitely upvote/confirm.
Issue Tracker
issues.frontierstore.net
Issue is not valid or link is not good
That takes me back - I had an IBM PS2 in 1988 - turbo button, heh heh. it did work though!! doubled the power.
And memory management - you had to work out manually (for VRAM/HDRAM?) and I had the first VGA ports (monitor with 256? colours instead of 16 with EGA)
This ends up being pretty rough for me personally. If I try to lower the frame rate my game looks terrible. Choppy when looking around and seemingly stuttering or something unless I play with Framerate Limit set to off (over 100 FPS). So, I heat up super fast when using the module.
I wasn't impressed much by this module at the start, but this makes it even less attractive than it already wasn't.
I wasn't impressed much by this module at the start, but this makes it even less attractive than it already wasn't.
Still not gone to pick any of these up yet. However I am planning to do so in the next few days.
I have no intention of changing any of my settings, and frankly the thought of doing so to change the performance of a module makes me uncomfortable.
The fact that this overcharge comes with the expense of fuel usage and heat doesn’t worry me of itself as my image of it is like the afterburner on an old military jet so not something to run for minutes at a time but just for a fast and furious few seconds.