Elite Dangerous: Odyssey Update 7 Notes

Love the updates. Odyssey has worked nigh on perfectly for me for weeks now. Keep up the great work!
 
Last edited:
Wow thanks again for the massive amounts of work. I've been away from Odyssey for a few weeks b/c I got hooked on FO76 but figured hey, by the time I get back, you will have fixed/improved even more stuff.

Keep up the good work. Odyssey is a great platform for lots of fun gameplay, and it's now beginning to shine.
 
Improvements to the aliasing seen on planet surfaces have been made.
  • Please note that this continues to be investigated. We're not done yet!
Hi Sally, just tried out one of the planets near Beagle Point, noticed the following (no, didn't check all 30 pages if this has been reported so sorry if this was already mentioned):

Floating rocks. No, not actual floating in the air rocks. This was noticed on the SRV scanner.
3D884D9FBCEAB5FFC66D78730D236A2BBF55642B

Note it shows the item is above me. It is actually under me.

Noted something similar on my ship when returning for departure from the surface:
E3C702C68257558D2FB701FF64A079B9DF73B6DF

I realize that I'm in a crater but the ship is on the same level as me. There shouldn't be an indicator that it's hovering several meters above me.

Frame rates: Still having an issue watching this number vary from 55 to 35 depending on which way I'm looking. On approach there was a huge amount of visual stuttering. Tried using normal view as well as "heat map" view, no difference - if it's going to stutter, it'll stutter.
Did notice that once I got about 3 or 4 km the frame rate picked back up.
1D080BEBD11BC2956169C2A35945FDD2C0A5748F

Love the textures. Would love the frame-rate number shown in this last image to show up on the ground. Even if it's never going to be possible, 50-55 fps would be a serious improvement. And I'm not going to get to see the inside of a station for another few months. BTW, the station I'm heading to is Jaques Station. It would be nice to see him tending bar (hint hint). :)

Thanks for all your help with this, Sally! We appreciate you being here and putting up with us. I know we can be … trying at times.
I, myself, have had to herd cats once in a while.
 
The fleet carrier menu is totally wrecked. Re log new into game did not solve this issue.
Old standing bug with animations.
You have some services paused.
Use right-menu.
1. To hide this broken screen use "engineers" button without relog.
2. Use carrier management and unpause ALL modules on carrier, then it will work.

They fix it and break again on each update to game :D v6 was break, v6.01 was fix :D, v7 is a break again.
 
Why? Going back to a outdated game with outdated functionalities?
Because the expansion isn't working, it's getting worse with each update, and the bugs have started spilling over into the base game.

At this point I wish there was the option to pay the developers for NOT touching Horizons. FDev, please make Odyssey a separate game with a separate set of servers and leave Horizons alone. Do NOT touch the code again! Please!
 
thanks. that worked. anyway I am programming for 35 years now and can not imagine how old issues can re appear during development unless you grab old parts of a product and re fit again including old bugs ...
Easy ...old procedural style (C-like) does it. Eventually if you read something like linux source they invent C++ manually, i.e. do all that C++ could do but manually.
Fixing of procedural programs mixed with OOP looks exactly like that (when you glued existing procedural with existing OOP). I was doing couple such refactorings.

Also there are some algorithms relaying on data property, like sorted data. That could be done by initial programmer for speed and not commented. Now they change sorting and have full spectrum of random bugs.
 
Last edited:
I came across a strange occurrence while in my ship.
Looks like you have bloom enabled. I turned it to medium after today's patch down from ultra, otherwise can't see a thing in dolphin.
Also had to lower brightness for everything to normal as it was rised a lot before.
 
Hello all.

The Headlook to Comms panel issue was fixed. I can now look at the Comms panel, it activates, and gets the focus to my keys/controls.

However, messages being sent by NPCs (not sure about cmdrs) are cleared as soon as I look at them. To read what they're saying, I have to turn my eyes but not my head.

Not sure if it needs hysteresis or if the panel clears the messages when it gets the focus but I had to turn headlook on Comms panel off once again.
 
hmm ... then I would put a bet something like



If to compile such with C++ rules- UB - optimizer will break all that and C guys love it.
UB means only that the compiler pulling demons from your nose is perfectly valid behavior. Most C++ compilers (heh, there aren't that many these days) use the same back-end as their corresponding C compiler (ie, just a different front-end), so UB has meaning only in the spec (ie, the spec does not define the behavior, but the compiler engineers are free to define it as they wish).

Still, I agree. That's what it looks like. Somebody had a brainfart and thought it would be a good way to speed up int to float conversions.
 
UB means only that the compiler pulling demons from your nose is perfectly valid behavior. Most C++ compilers (heh, there aren't that many these days) use the same back-end as their corresponding C compiler (ie, just a different front-end), so UB has meaning only in the spec (ie, the spec does not define the behavior, but the compiler engineers are free to define it as they wish).

Still, I agree. That's what it looks like. Somebody had a brainfart and thought it would be a good way to speed up int to float conversions.


Many compilers issue "strict aliasing" warnings in such cases, even though technically such constructs run afoul of something other than the paragraph commonly known as the "strict aliasing rule".

The purpose of strict aliasing and related rules is to enable type-based alias analysis, which would be decimated if a program can validly create a situation where two pointers to unrelated types (e.g., an int* and a float*) could simultaneously exist and both can be used to load or store the same memory (see this email on SG12 reflector). Thus, any technique that is seemingly capable of creating such a situation necessarily invokes undefined behavior.

 
Back
Top Bottom