The first is the game hangs and never starts at finalizing
the second is the game hangs when you try to start.
people have waited extensive periods of time.
Is this something gundam related? Is this a fixed engine bug? is the cause known. I would like to know because to see >5 users report this no telling how many are not reporting it at all and just leave.
you act as thought I gamers are technical adept. you act as thought they stuck around afterwards. I did people were more interested in shooting the breeze about google chrome.
I am FINE, tons of people trying to play spring apparently are not. You seem to think this is for my benefit.
See the thread. I posted infologs from the person. I can request info logs as well. every time I bring up these issues it is like you turn it around on me man. Take a look at the thread, see if you can get any idea from it.
"make one of them test on spring master. get GFX info from all of them, to see if it could be that (eg. all having intel/ATI)."
It takes me about a 2days to a week to get each one of them(provided they are willing) to dig up the infolog.txt file. These are not often tech savy people man. I am trying here at least look at the thread and see what I am complaining about. It ended with me asking what the hell this has to do with spring while they had fun talking about chrome and realplayer.
smoth, try to reproduce this problem. I mean install real player and take a look at "finalizing" stage code. Try to reproduce situation when this realplayer's dll will be attached to your spring and try to debug or something.
Also with new Spring version this problem can be fixed. You may wait a little for new version and see what will happen.
Anyway, thank you for bug report! If developers use mantis, maybe this report should be created as mantis issue... (if not created already)
smoth, try to reproduce this problem. I mean install real player and take a look at "finalizing" stage code. Try to reproduce situation when this realplayer's dll will be attached to your spring and try to debug or something.
So you want me to debug spring? Do you realize how time consuming that would be and how frustratingly difficult debugging c++ is? this isn't like .net, I would be reading assembly.
but so you know I did install realplayer and chrome... Got in game just fine.
jamerlan wrote:
http://springrts.com/mantis/view_all_bug_page.phpAlso with new Spring version this problem can be fixed. You may wait a little for new version and see what will happen.
You do not realize the hassle that comes with me re-releasing a new version.
jamerlan wrote:
Anyway, thank you for bug report! If developers use mantis, maybe this report should be created as mantis issue... (if not created already)
to reproduce the problem describend in the other thread with rpchromebrowserrecordhelper.dll: you have to install real-player and not chrome.
(and please stop baaaawwww!)
Good of to tell me stop whining. Let's review what i asked... Are the two bugs either: Gundam related meaning I have code triggering this Engine related as in known bugs Is the cause known
I get replies like: Get me an info log I point out that it is a time consuming process (because I am working with 2 right now to try and get their info logs been over a week now btw) I point to a thread where there is on
I point out that I did install both programs that are suggested in the prior thread Post shot of game still running
Get told to stop whining.
Dude, I am doing everything that is suggested to help track this down and have raged or anything near what you guys get from others and you say I am bawing. Would you prefer if I were less polite would that appropriately enough crank the aggression high enough for you? What do you want?
Why no infologs: the people having this error are giving time to something they have never even played. I am being patient with them and trying to walk them through each step as diplomatically as possible.
Why am I so serious about this: If the hours and hours I have spent in "let's make spring more popular" type threads are any indication, you should know I care about each potential spring user. We have likely lost out on scores if users due to these 2 possible bugs.
Why no mantis report: I have not eliminated gundam as the source of this bug, I have only one infolog for it. In conclusion I do not have a solid standing with this as a bug. Until I eliminated gundam from being the cause my bug does not go on mantis.
What is the point of the thread: To determine the validity of this bug and to collect what data I can in order to try and point a dev in the right direction.
Why am I being impatient: Because I have been giving my gundam dev time to collecting data for this. So far I have lost a week. Work is busy, I am carrying 2 projects and have not had the time to work out for 2 weeks now, been sick and am trying hard to pinpoint this guy so it doesn't make it into the upcoming engine release
GFX (driver) crash. in theory, and other driver (version) or different spring settings might make the crash go away, but it is not possible to tell you what setting it would be. If i remember right, the last crash you reported was with an Intel card too. maybe compare driver versions.
is the part in pink relevant? Does spring have a minimum needed glsl or just general needed gl build? if so can we start to give warnings/errors/close spring for the users who cannot support the required calls? Seems to me a natural step better handle people who apparently have no business running spring due to hardware/driver restrictions.
No it has nothing to do with the version of OpenGL/GLSL. It's just that Intel drivers suck and crash. It's not our fault at all. We send clean OpenGL commands and the drivers just fail. This is very common under linux with opensource drivers, cause all those build up on MESA which was designed as a _software_ OpenGL implementation. But later the opensource drivers used their code, so they can progressively switch command by command from software to hardware implementation. Sure this makes the life of such projects much easier, so they don't have to implement 100% to get a `workable` driver. The problem is that this way introduces many incompatibilities. And those result in random/unpredictable crashes.
Well poop. I was hoping there could possibly a simple "your machine cannot run this" solution. Pretty much with drivers it is chasing a moving target on what driver the end user has and whether on not that one is doing it right? Seems pretty much crapshoot odds.
Many of these fellas are getting hang at finalizing. As in, this is the number 1 complaint I see. Is it possible to get more data from the finalizing step in future versions or pretty much if their driver is shit, it doesn't matter and just dealwithit.jpg? Just seems like they are crashing in the same area, maybe that crash can be better caught and handled?
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum