Vectrobe
- Paul17041993
- paul17041993
- Australia/Sydney
- Yes
- No
MCL-1657
MC-62625
Windows 8, Java 1.7_u25x64
Windows 7, Windows 8, Windows 8.1, Java 1.6 i586, Java 1.6 x64, Java 1.7 i586, Java 1.7 x64,
Each time I start the launcher, it will get an "Invalid Token" error and I have to re-type my full username and password, incredibly annoying, the launcher should at least hold the email in there so I only need to type the password if it fails to login.
edit; current likely cause is due to 3rd party launchers being used at times, or multiple computers being used, likely causing the servers to renew the token and make the official launcher's one invalid. still yet to be confirmed however.
Windows 7, Windows 8, Windows 8.1, Java 1.6 i586, Java 1.6 x64, Java 1.7 i586, Java 1.7 x64,
Windows 7, Windows 8, Windows 8.1, Java 1.6 i586, Java 1.6 x64, Java 1.7 i586, Java 1.7 x64,
Windows 10 pro, Java 1.8 x64
Each time I start the launcher, it will get an "Invalid Token" error and I have to re-type my full username and password, incredibly annoying, the launcher should at least hold the email in there so I only need to type the password if it fails to login.
edit; current likely cause is due to 3rd party launchers being used at times, or multiple computers being used, likely causing the servers to renew the token and make the official launcher's one invalid. still yet to be confirmed however.
Each time I start the launcher, it will get an "Invalid Token" error and I have to re-type my full username and password, incredibly annoying, the launcher should at least hold the email in there so I only need to type the password if it fails to login.
edit; current likely cause is due to 3rd party launchers being used at times, or multiple computers being used, likely causing the servers to renew the token and make the official launcher's one invalid. still yet to be confirmed however.Occurs with the vanilla launcher, old and new. Note that some platforms do not have the new launcher either, as it's an exclusive executable to windows...
non-standard pipeline, state calls or set flags cause driver-level render filtering to fail, most specifically AA settings. Standard OGL deferred rendering is not affected.
solutions;
- use more standard modern game deferred rendering
- add an option for SSAA
- if it is indeed just set states or flags that force-disable driver settings, provide an option to disable these.
this seems to be a known bug since 1.7.2.
side note for those who might not know; in the options file there's an option called 'fboEnable', if you set this to false it'll disable the deferred render and rendering behaves like it did in mc 1.6 and earlier. so ie things like SSAA will work correctly etc.
non-standard pipeline, state calls or set flags cause driver-level render filtering to fail, most specifically AA settings. Standard OGL deferred rendering is not affected.
solutions;
- use more standard modern game deferred rendering
- add an option for SSAA
- if it is indeed just set states or flags that force-disable driver settings, provide an option to disable these.
this seems to be a known bug since 1.7.2.
side note for those who might not know; in the options file there's an option called 'fboEnable', if you set this to false it'll disable the deferred render and rendering behaves like it did in mc 1.6 and earlier. so ie things like SSAA will work correctly etc.
Windows 8.1 x64, java 1.7 u51 x64 JRE + JDK
Windows 8.1 x64, java 1.7 u51 x64 JRE + JDK
Windows 10 x64, java 1.8 x64 JRE + JDK
non-standard pipeline, state calls or set flags cause driver-level render filtering to fail, most specifically AA settings. Standard OGL deferred rendering is not affected.
solutions;
- use more standard modern game deferred rendering
- add an option for SSAA
- if it is indeed just set states or flags that force-disable driver settings, provide an option to disable these.
this seems to be a known bug since 1.7.2.
side note for those who might not know; in the options file there's an option called 'fboEnable', if you set this to false it'll disable the deferred render and rendering behaves like it did in mc 1.6 and earlier. so ie things like SSAA will work correctly etc.
1.3+ note; you can nolonger disable the FBO to switch back to forward rendering, so the above fix nolonger works.
non-standard pipeline, state calls or set flags cause driver-level render filtering to fail, most specifically AA settings. Standard OGL deferred rendering is not affected.
solutions;
- use more standard modern game deferred rendering
- add an option for SSAA
- if it is indeed just set states or flags that force-disable driver settings, provide an option to disable these.
this seems to be a known bug since 1.7.2.
side note for those who might not know; in the options file there's an option called 'fboEnable', if you set this to false it'll disable the deferred render and rendering behaves like it did in mc 1.6 and earlier. so ie things like SSAA will work correctly etc.
1.3+ note; you can nolonger disable the FBO to switch back to forward rendering, so the above fix nolonger works.non-standard pipeline, state calls or set flags cause driver-level render filtering to fail, most specifically AA settings. Standard OGL deferred rendering is not affected.
solutions;
- use more standard modern game deferred rendering
- add an option for SSAA
- if it is indeed just set states or flags that force-disable driver settings, provide an option to disable these.
this seems to be a known bug since 1.7.2.
side note for those who might not know; in the options file there's an option called 'fboEnable', if you set this to false it'll disable the deferred render and rendering behaves like it did in mc 1.6 and earlier. so ie things like SSAA will work correctly etc.
.13+ note; you can nolonger disable the FBO to switch back to forward rendering, so the above fix nolonger works.
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
oh oops, forgot to attach the log...
here's the error, cropped the log just before the download section so its not a wall of eventless library checks;
I have the launcher set to stay open, but I'm pretty sure if I close it before launching and re-open it doesn't hit the error, though being a student in game programming and doing an end-of-year project I haven't mad much time to really mess with it lately...
ok, re-opening multiple times after logging in has no effect, launching the game and closing also has no effect, it only occurs after a long period of time, the next morning for example.
this is both a account server issue and a major flaw in the launcher...
even in the case of a failure, it should remember your email so you don't have to re-type it every time, and what happened to the secure thing of entering your password at launcher open? that should already be in there by default...
still occurring, it will fail with invalid token at launch but log in instantly perfectly fine after re-entering the email and pass, very annoying...
yes, and all 3 above relations were falsely resolved... I don't even see a comment confirming any fixes...
MCL-1663problem logining inMCL-1671Login Failing When I Open The LauncherMCL-1700Launcher Invalid tokenthese 3 are marked duplicates of this, but are marked as resolved?
ok it seems like its fixed for me, but I also added a profile for the 1.7PR, not sure if that may have fixed it or not...
@Mike try making another profile for something, see if it stops the problem happening (for all profiles).
it seems to have been fixed after I made another profile in 1.2.8, seems like a file or cache thing,
anyone else here have the problem still? if yes you should probably try renaming your .minecraft folder and start fresh, try putting stuff back in one at a time and see if and/or when it breaks again...
ok, bug is indeed back again after adding another profile, launcher 1.3.7, new profile was one for vanilla 1.7, nothing else changed and the bug is exactly the same as it were last time, I am unsure if this could be related to using (legacy) minecraft 1.5 versions inbetween, (but not at the same time of course), these 1.5 clients are also done via a different launcher so I expect there could be a fatal flaw in the token system...
my current understanding of how the system works, seems like it uses the last token to login to the servers, and it then updates this token, but if another token from another launcher was updated beforehand it would fail as the current would be invalid, allowing only the one launcher to exist, which of course becomes a major function flop for people using multiple PCs and launchers like FTB and Technic, both said launchers use the original login system.
I think really what should be done to the launcher is to bring back the old session system, where I just enter my password at the start of the launcher or when launching a game, the fact that I have to keep re-entering my 30 character email each time is massively annoying to say the least...
side note, wheres the "delete profile" button? I have some 20 profiles I want to flush out but prefer not to meddle with the database files manually...
there isn't a fix for this unfortunately, you just have to wait for [Mojang] to refactor the token system to not be so aggressive or to bring back the classic enter-password-at-launch (of the launcher, the launcher then contains a session token), the latter I personally desire the most simply as it also stops unauthorized access to my account, as well as removing this kind of problem entirely.
added 1.3.8 to the list and added a "cause note" to the description, might be helpful, though the current launcher version, 1.3.9, isn't in the version list and needs to be added (yes this version has the problem too, the version list doesn't accept manual entry).
@eddie do you use any other launchers and/or multiple computers? (eg; technic, FTB,)
I still stand that the ultimate solution would be to retire the token system, its just not worth it in this current design, I mean if everything else still uses the classic user-and-pass system without flaws then why use pure token-only...?
really, bring back login on launcher start via password and (remembered) email/s, give users back the ability to save their password, and the launcher can then grab a session token that will allow the game to be launched provided said token is still valid, this will allow mixes of launchers and computers while still adding a layer of piracy protection.
3rd party launchers don't use tokens entirely, so as Ive been saying, a better system with legacy support would be required UNLESS you forced every 3rd party launcher to use the token system and keep in-sync with each other...
there's also still possibility of handshake failure, its a law, so as I have also said; the launcher NEEDS to remember the EMAIL so users only have to type their password if it fails.
oh yea, and lack of sync already throws multi-PC support completely out the window.
I can give you a UML of a better authentication process if you want? its not like I don't know how these systems work.
@Kumasasa that's for the old intel chips, this is (presumably, what the reporter says) a HD4000, found in the 4k i series CPUs.
confirmed for;
reported for many other processors on both AMD and Nvidia.
a sub issue seems that FRAPs (and I imagine others) don't recognize mc1.8 as a valid 3D application, if something in the window system was changed recently then that would be a likely cause, and likely been done somewhat incorrectly, for example rendering to a window texture over rendering to a window GL context is a bad idea as it more than likely causes unneeded buffer copy-backs (ie; VRAM > RAM > VRAM each frame, which is very bad and slow).
back to the main issue, the common modern 'correct' deferred render is to use Multisample framebuffers, they behave identically to standard ones, however their real size is determined driver-level and they don't have an internal depth buffer, the later is not a problem as if you need it in post-processing you can always define your own depth buffer via the use of gl_FragCoord or more optimally just passing through your positions as another vector4, or alternatively just pass the depth of the position as a float, either of these should work and you can change the graph if you desire (default GL depths is logarithmic-like), only note there is gl_FragCoord last I checked was being retired and may not be in later contexts.
that being said, I cant necessarily explain the whole gist of modern GLSL rendering as I have my own projects to attend to, but this is only the very basic stuff and you can find various info all over the place.
Has the pipeline been updated to use the modern multi-sample objects? If not then the main issue still remains, ie; FBOs must be disabled for AA to be functional.
Confirmed no change to the render pipe since 1.7/1.8, all bugs I know from them still exist in 15w46a, including poor draw performance overall.
The code never changed so the behaviour is still exactly the same, additionally on 4k displays the lack of AA results in dithering (ie; a block at the same distance could be either 55 or 56 pixels high with different minute FP values).
AA is not a post-process, nor filter, it's performed with the initial rendering stage.
In C/C++ the methods in question are 'glTexImage2DMultisample' to generate the framebuffer (as opposed to glTexImage2D) and you perform a glBlit to either a secondary buffer for post-process or to the backbuffer, depending on what render effects you want and what data needs to be passed through.
In this case it's likely just;
> render everything to multisample buffer
> blit to midway buffer (of the same res as the window
> render post-process effects from mid buffer to back buffer
This has now returned again as of the latest launcher releases (2.0.1049), if you install the launcher to multiple computers, each time you open the launcher on a different computer the token will be invalidated...
related to
MCL-1657? I've been getting invalidated sessions lately when switching between PC's, only been an issue since the latest updates...(deep regression of the above linked issue)
dupe of
MCL-1657I seem to be having this too on a new win10pro system, but not on my existing desktop, which is rather odd...
could be a corrupted library file on the servers, I might do a checksum between my client files tomorrow...
Yea, those comments were irrelevant from the beginning, and especially now where I'm using the vanilla launcher on each computer, this only popped back up as a regression very recently.
Notice the amount of duplicates, with a new one recently created but not yet linked;
MCL-9399eddie was wrong though, the new token system was a disaster from the beginning, and for who knows what reason the devs didn't accept this as being a bug until after it was marked 'invalid' (they finally admitted on twitter). But now because of it being ignored and subsequently forgotten, they've undone their 2013-14 fix and now the bug has returned yet again almost 5 years later...
btw, even though these are with clean launcher installs, keeping client ID's in a local file is how you create a backdoor...
Use the hardware ID instead, or TPM if available (and up-to-date).
That should not be the case, nor can it be a cause as the launcher does not check for whether a folder is marked hidden or not. Hidden folders are exclusive to windows explorer and any other explorers that actually read the thumbs file inside, this file tells explorer whether or not it has custom properties.
This needs to be re-opened so mojang can actually fix it properly, and permanently this time...
If the full GL pipe is open now, I may just fix this myself...
nope, no different to what it was before, other than the FBO option being stripped entirely...
The issue was confirmed long ago, and was primarily caused by the implementation of the unfinished FBO pipeline. The prior moderator forgot to change the ticket status back to confirmed.
The various issues are any number of graphical artefacts that occur as a result of using legacy GL with legacy render-to-texture, both of which are seldom supported, and block modern graphical features from functioning.
LWJGL only needs to support GL 3.2 to 4+ for it to not be an issue.
The primary changes needed to the pipeline are non-interfering spritemap generation (fixes edge sampling issues), and stripping out the legacy render-to-texture and implementing proper multi-sample frame buffer passes. Additionally, GL_QUAD calls should be stripped out and replaced with instancing, or proper triangle generation.
Once the above changes are made, a pair of new sliders for hardware Anti-Aliasing and Anisotropic-Filtering can be added, and the mip-map code can be stripped out.
The use of legacy render-to-texture causes hard pixelation, screen-door effect and prevents any form of driver render features from functioning, such as super-sampling, multi-sampling, morphological filtering, colour correction, buffer control and so on. AF appears like it has been fixed in .15, however the lack of AA means it's not exactly visible, nor are any AF sliders present yet.
Prior additional artifacts included poor performance and extreme pixelation in the inventory, where the FBO then had to be disabled to fix these. Though since the FBO option was removed, these may nolonger be an issue.
Current other artefact issues include items in-hand and in the world rendering with offset mesh coordinates, worsened when running on a 4k display or higher. Ice still renders all 6 sides randomly, while also Z-fighting, and rendering large amounts of chunks and/or items on-screen still causes immense performance degradation due to the use of legacy rendering.
No, it's on mojang's side to update the render code. As far as I know LWJGL has been updated to support current and future GL iterations.
Render quality has improved marginally, we're not seeing many block edge artefacts, however anisotropic filtering and multisample FBO's are still not present.
Item rendering still looks awful (1.14 and up bug I think), but that's technically a separate issue I'm pretty sure.
... I spoke too soon it seems. 1.16 has introduced a new bug, where when the game is set to fabulous mode, the resolution is nolonger correct and lower than that of the display's. In essence, the window size is not detected correctly, and a lower buffer resolution is used, resulting in severe pixelation.
This is also technically a separate bug, as it's a fault specifically in the window size handling/detection code.
Just curious, have any of you tried with the FOV set to exactly 60 degrees? Most games use 60 as it's the best sweet-spot between warped and telescoped rendering, I verified in minecraft and 60 has almost no angle distortion, while not looking like your head is attached to a plank being swung around that is 50deg and lower.
An extra game-dev rule is limiting directional movements with cameras, in that they should only be moving in mostly one direction or rotation at a time. If the camera for example were to fly outwards from the target, while also strafing to one side, that can cause spontaneous nausea in some people. In the case of minecraft, I would suggest an option to be added to snap motion to fixed rates, as opposed to having constant momentum, especially for creative mode. The user can then simply refrain from using WASD and the mouse at the exact same time, and not have to worry about the character still sliding around when they're looking around.
One other thing to note is looking down can be a sure-fire way of triggering nausea in a lot of people, especially if you're way up high and slam the view straight down. The effect can also be witnessed in real life when looking down from a high-rise for example, in a sense it could be confused with acrophobia, but they're not the same.
A very important note I will add to this; OpenGL effectively has a hard limit as to how many instructions can be passed through per second. If you add more little details to grass for example, that involves one or two more GL calls, the maximum framerate will be dropped accordingly.
If you wish to optimise against this problem, you'll want to implement chunk batching. If you batched every 2x2x2 sets of chunks (32x32x32 blocks) for example, you can cut your total draw calls by as much as 8 times. The one caveat to doing this however is chunk re-bakes (updates) will take extra time, so it's advisable that the batching be done for distant chunks, or ones that otherwise are not updating frequently.
An additional suggestion would be skinned meshes for entities, so that each entity can be rendered with a single set of draw calls instead of one set for every box they are made of. This would be incredibly simple to implement here as you'd only need a single bone per box.
... ok the resolution is definitely of itself a separate issue, fast and fancy are also affected.
MC-191780... really...?
You could easily fix the behaviour, but keeping it in and making it look worse than previous versions is instead the intended goal...? why...?
I would expect it to be a feature already present in LwJGL, all that should be needed is flagging the window as DPI aware before creation, and providing a scale option inside the graphics settings if high resolution is a problem.
On window resize, firing a buffer destroy-recreate, you simply grab the true window resolution (should be returned by the window size call when the DPI awareness is flagged correctly), and factor it by the scale option, and feed that to the buffer creation.
You could also provide an auto mode in the scale slider, of which the behaviour would be to grab the active scaling of the window at the time of resize/migration (a resize event is usually fired on scale change).
Note that you cannot expect this to be an automatic feature inside LwJGL, the application using said library must still handle the given modes correctly, otherwise if its left to auto DPI aware then you'll get mac users complaining that their small integrated chips are chugging at 5k.
If the feature is apparently missing in LwJGL, or not functioning as intended, please make that clear and don't close it as a "wontfix", that's not how you solve problems. I can potentially fix the bug (if present) in LwJGL if need be (note, only for windows and linux however, I do not own a high DPI mac).
Additional feature note; the scaling option could be allowed to go as low as .5x, which would provide a simple super-sampling feature.
@ampolive makes sense since that was created not too long after this one