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):Improvements to the aliasing seen on planet surfaces have been made.
- Please note that this continues to be investigated. We're not done yet!
Old standing bug with animations.The fleet carrier menu is totally wrecked. Re log new into game did not solve this issue.
Use on ship carrier managment, press (4) then "carrier" then unpause all.I can not access any of the broken menus![]()
Because the expansion isn't working, it's getting worse with each update, and the bugs have started spilling over into the base game.Why? Going back to a outdated game with outdated functionalities?
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.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 ...
I mean, if they're suspicious that someone's going around cutting panels and some guy's walking around the base in a maverick suit....How they could tell it was me I have no idea.
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.I came across a strange occurrence while in my ship.
For comedy reasons I really hope they didn't replace the "I've been shot!" response to getting punched.Civilians now have lots of new dialogue, including combat taunts, as well as new lines for when they're taking fire.
Wrong byte order, yep.I did some analysis of that silly number in the PA damage: 9223372036854775808 as a float is 0x5f000000 in hex (0x5f = 95), so it looks it might be a bad float conversion.
not just wrong byte order. 0x0000005f as a float would be a very tiny number.Wrong byte order, yep.
hmm ... then I would put a bet something likenot just wrong byte order. 0x0000005f as a float would be a very tiny number.
float *p;
((int*)p) = 1234
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).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.
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.