[Dev Team] New multiplayer beta + gameplay fixes opt-in patch 1.7.2
- Thread starter Jamor
- Start date
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
If you were actually interested in why there's a delay at the moment the information is right here on this forum. They can't really be blamed for you not taking the time to find out. But you're not really interested, are you?
It's almost as if betas are meant to shake out problems and anyone opting into one should be aware that it might have issues.
What's sad is that many of us here want to help tests the features implemented in the beta, but got shaken down at the gate by the slowdown. If they release a hotfix for it, I'm down for another run at 1.7 beta..
By the looks of this thread it seems as if the issue is a priority. It wouldn't surprise me if they released another beta to see if they squashed it good when they've put in a fix.
So I was bored, and curious, and went at the problem with a debugger to see if I could figure out what's going on. Findings:
The function at 0x10021CE0 (gathered this address using IDA) in pops_api.dll gets to 0x10021DB3, where it does a MOV AL, [EDI + 48h]. Next it does a TEST AL, AL. This is, as far as I can tell, the only way out of the following loop without hitting a "Vector<t> too long" error. Unfortunately with the current code, [EDI + 48h] never changes. So it gets stuck in that loop endlessly. I'm not sure what the loop is supposed to be doing, because I suspect it's not actually doing it, which is why it's looping endlessly. But the root call seems to be coming from a thread created by the POPS_Initialize function, which takes place right before it gets to some code dealing with strings "Test mode engaged" and "http://127.0.0.1:8080/sandbox". Hopefully this info will help to some degree, and if not, at least I can play without my CPU frying (by manually setting AL to 0, ha!).
The function at 0x10021CE0 (gathered this address using IDA) in pops_api.dll gets to 0x10021DB3, where it does a MOV AL, [EDI + 48h]. Next it does a TEST AL, AL. This is, as far as I can tell, the only way out of the following loop without hitting a "Vector<t> too long" error. Unfortunately with the current code, [EDI + 48h] never changes. So it gets stuck in that loop endlessly. I'm not sure what the loop is supposed to be doing, because I suspect it's not actually doing it, which is why it's looping endlessly. But the root call seems to be coming from a thread created by the POPS_Initialize function, which takes place right before it gets to some code dealing with strings "Test mode engaged" and "http://127.0.0.1:8080/sandbox". Hopefully this info will help to some degree, and if not, at least I can play without my CPU frying (by manually setting AL to 0, ha!).
Except 1.7.2 is a beta the whole point is testing the fixes they are working on and it's expected for there to be issues with new untested code. Look, they finally listened to those of us who just wanted them to release a beta of what they're currently working on. This is what I was asking for and I'm glad they listened. They're letting us play with and help test the current bug fixes so we won't have another release like 1.6.0. If you don't like that stick with the stable version until they finish the patch.
Well, see, "working on" may as well mean "come to work, say hello, log into ur acc and chill for the rest of the day". Some people work to get paid, some consider actually doing something in return. A random guy, without the actual game code, just went in, found that a single thread loads single core of the CPU to 100% and correctly judged that the reason must be an infinite loop. In less than an hour he posted proof here. THIS IS A MEANING OF WORKING ON.
PDX, you should hire this Bruic guy as QA 
Hopefully this was indeed the error, and PDX fixes this asap.
Hopefully this was indeed the error, and PDX fixes this asap.
ASAP, aha. As always. Just give us the code we will do it faster. And fix the rest of the bugs as well. And also introduce all the long-promised features. And optimize the late-game so it will have no lag. I am sure fans can do better work if only they would have code, not the devs. If fixing infinite loop at initialization bug takes them so long, what can u expect?
Really, guys, think about it: devs just gave us tools so we could check where the problem is. And they keep claiming they play the game themselves. Fans run the tool and clearly all seen the same issue. Now the question: wouldn't devs find this the same way if only they run the game with tool themselves? It shows that they just keep us busy pretending that a lot of testing needed here. This guy above just showed how easy it was to find the problem having some skill. Devs are playing with us to slack until the July vacation.
Really, guys, think about it: devs just gave us tools so we could check where the problem is. And they keep claiming they play the game themselves. Fans run the tool and clearly all seen the same issue. Now the question: wouldn't devs find this the same way if only they run the game with tool themselves? It shows that they just keep us busy pretending that a lot of testing needed here. This guy above just showed how easy it was to find the problem having some skill. Devs are playing with us to slack until the July vacation.
Last edited:
1.6.1 is entirely playable and 1.7.2 is a beta and as such you shouldn't actually expect it to be playable. The game is far from perfect, but it is clearly improving and vastly improved since release. Take a chill pill and/or stop shitting this thread up with unhelpful whining.
A beta is not an alpha build and is not supposed to be wholly untested code. Especially if it's a beta released to the public.
I work in a professional environment and good intentions and 'trying' only goes so far. At the end of the day you're judged, rightly, on results.
QA would only notice and log the bug. Bruic is acting as a freaking Dev which now just annoys me. A random forum person managed to find the bug while bored while... a whole team of paid professionals...?PDX, you should hire this Bruic guy as QA
Hopefully this was indeed the error, and PDX fixes this asap.
Last edited:
No CTD(s) - It's playable ! - That's a very undemanding attitude ! - I expect something like this this from careless players, achievement-hunters or even "dumb" players, which don't realize, that something is going wrong in regards to the code, features, mechanics etc. of the game ...
You really want to fund this kind of development (as an alpha-beta-tester) for another 2 years and 140 Euros/Dollars/what-ever ? - Isn't it ? ...
To be clear, without this so called "whining", the responsible "bosses" of paradox would do "business as usual", which means, that you would have (atm) a more buggy version of the game, but (probably) 3 more DLC(s).
And how does finding an asm layer infinite loop help fixing a higher language/layer bug? You do not code mostly in asm... Also infinite loop is not necessarily a bug. At least I can hardly believe the above guy actually verified that memory area cannot be modified by another thread or ui or networkinterrupt. Sure probably it is a bug but probably only a lack of sleep in upper layer. Or as well some other coding construct. So kbowing of some bug do not meen you know how to fix. And verifying you fixed the root cause not only implemented a workaround or broke something else is another matter.
Obviously this bug is fundamental! See how long do they work on that single one? And there are hundreds more known. Imagine how long it will take?
If u r not sure which button to hit for this post - it is a red one. Post contains sarcasm. So u need to disagree. U r welcome.
If u r not sure which button to hit for this post - it is a red one. Post contains sarcasm. So u need to disagree. U r welcome.
It doesn't help me fix it, obviously, but it should help someone fix it who has access to the source code since they can translate the asm to whatever language they are coding in (C++ probably?). And no, an infinite loop is not necessarily a bug, but in this case it most certainly is, as the code has a check to exit, which wouldn't be the case if it was intentionally designed to infinitely loop. I certainly can't verify that it cannot be modified by another thread or ui or network interrupt, but I can verify that it wasn't being modified. That is, in fact, the reason that it would cause the CPU to max out, because it would not break the loop.
It is a bit surprising to see that you, despite not having looked into it at all, feel confident to dismiss my conclusions while at the same time also feel confident enough to conclude it is "probably only a lack of sleep". I would like to point out that at no point did I claim to have "fixed the root cause". All I was doing was trying to potentially help point someone in the right direction to fix it. If I did, great, if not, I'm sure they'll be able to figure it out quickly themselves.
I did exploit developement, crash (Watson anyone?) analysis and code reengineering a lot professionally and do know from experience how complex is it to get from an asm symptom to a proper fix. And usually asm level code debugging is not necessary in the fixing process. And most construct I mentioned has an exit condition. You need to check other treads whether they write there or not. If you take an arbitrary program, break into it most probably you will end up in a loop you have just described.
Yet it is possible you provided value, and even if not I did not say your assesment is bad. What I said getting from your data to a proper tested fix is tough and folks should not blame the devs since your discovery did not provide insight on the effort and skill they are investing in Stellaris.
Last edited:
Might very well have found the root cause and is fixing it as we speak? I have no idea if that is so, it just seems weird to assume that the devs don't know more than the people in this thread.
Look at what he's responding to. I think it's the rather insulting (to the devs) assertion that PDX employees just go to work and sit of the time rather than work.