here is a video of the bug
pressing resume with the mouse can get you killed, i think its cuz there is a split second where once you resume the ship teleports to where the mouse is before the game is able to get the mouse’s position back to where it was before pausing (at least if that’s how that works in the first place)
also this is the website version, not steam.
this might also happen for CI4, CI3 but IDK
EDIT: it also happens on CI4 (on website version at least), and in case ya’ll are asking yes it also happens on holiday editions as well, tho luckily not on CI3 (cuz i checked as well)
2nd EDIT: yes i do in fact have the latest versions, version 5.05.ze, and 4.22.n and 3.85.d so yeah i got the latest versions
3rd EDIT: yeah just checked steam versions for CI4, 5 and you will never guess what happened
This is actually a known bug which was even in CIU for a long time, I don’t remember when it was fixed. So it’s expected for it to be in episodes. Currently the episodes receive only some small emergency updates, as the active development is spent on Universe instead, so I wouldn’t expect this to be fixed any time soon.
huh, weird that i never noticed it until now
i mean its a pretty ez fix, all you have to do is to put the line of code that returns the mouse cursor to its place before the line of code that resumes the game
i think the reason that it doesn’t work for CI3 iz cuz CI3 moves the ship based on mouse movement instead of where the cursor is at, while in CI4/5/uni the position of the ship is based on the position of the mouse in the screen
Ahaha. Yes, that’s what any sane person would expect. This is what CI3/4/5 already do. However, there’s some weird behaviour in Windows that causes this cursor positioning (“warping”) to delay or fail every once in a while, seemingly randomly. So CIU has this
crappy and inelegant elaborate way of warping the mouse pointer, then verifying if the movement was indeed made, retrying it if it hasn’t taken effect yet, all the while ignoring the position reported by the OS in the meantime. It’s a huge mess, and I spent almost a week trying to understand what was going on. To give you an idea, this is just part of the code that attempts to fix this issue:
void UveInput::SetCursorPos_fix(UPoint pos, bool bAlsoVerify)
// We need this wrapper because SetCursorPos stupidly has two problems:
// 1. Changes to the cursor position won't always immediately take effect -- rather it could be several
// frames later (up to 6 frames in my tests) during which mouse move events will STILL be reported,
// but as if SetCursorPos was never called (i.e., we'll get the 'old' coordinates back).
// (the faster the framerate is, the more likely it is that this will happen).
// 2. Rarely, SetCursorPos will have NO effect at all, it will just be 'lost' (happened twice for me). WTF.
// Essential: we must pretend as if change was made immediately
// (because UVE sets the mouse position on each frame based on this)
os_mousePositionX = pos.x;
os_mousePositionY = pos.y;
// To minimize problems, we buffer all changes and only apply them at the end of each frame (see update2).
// We also (optionally) verify that our changes took effect.
pendingSetCursorPos = pos;
bPendingSetCursorPos_call = true;
bPendingSetCursorPos_verification = bAlsoVerify;
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.