Still 100% off-topic to this game right now. Especially in a beta update thread.
-
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.
- Status
The memory leak is real, but very slow: it took me 8 hours of play to start to experience it. I have 16gb of ram though, so there's a bit of an overhead which probably helps.
Not a coder, but I wonder if that slowness is precisely the problem. It's like a slow tire puncture. There's no sound or escaping air to tell you where it is, so you have to either painstakingly search every point, or resort to extraordinary measures (I know, a whole *sink* of water
) to find it.
Last I checked you can't stick a computer under water without bad stuff happening, so I think that leaves a painstaking search. If it's really obscure, it's likely to be a right bugger to find.
Not a coder, but I wonder if that slowness is precisely the problem. It's like a slow tire puncture. There's no sound or escaping air to tell you where it is, so you have to either painstakingly search every point, or resort to extraordinary measures (I know, a whole *sink* of water
) to find it.Last I checked you can't stick a computer under water without bad stuff happening, so I think that leaves a painstaking search. If it's really obscure, it's likely to be a right bugger to find.
hope they release this soon. looks like it breaks a lot of mods and dont want to start a new game
Add to that the fact that it may be triggered only by a combination of things happening in 'the right way' to accumulate in just the wrong way. It may be that there's a tiny bit of memory leaked when you go into the mechlab, and a tiny bit when you look at your component list, and a tiny bit when you go to the mechwarrior barracks, or the hiring hall / store / contract list.
On their own, it may not be appreciable, but if they happen quickly in succession pointer references may be lost track of and never freed up. God knows, Perl's underlying use of memory calls like malloc and free don't always do their job properly or the underlying call may not. Way back in the dawn of my career, I ran into an issue caused by the way that Perl free'd memory. It wasn't a bug in Perl or in the program I was working on, but on the system libraries that Perl was using. As much as I wanted to, there was nothing I could do unless / until the system libraries were fixed (which wasn't going to happen because the OS vendor wasn't updating it anymore).
The short of it is that, if possible, track what actions you're taking over the course of play and see if there's a detectable pattern in how you play. I can saying for sure that I don't always visit every store and hiring hall and there are plenty of times where I don't touch the mechlab or barracks. Part of that is because I'm forgetful. If you are habitually hitting up every store and hiring hall, checking your pilot XP constantly, and constantly tweaking mechs and builds, that's a play style difference that results in different memory allocation / use in the background (hiring halls don't need to be generated, stores don't need to be populated, inventories / pilots aren't constantly being brought in and out of memory, etc).
The identification of actions taken would help in the debugging and troubleshooting of the problem since it would allow HBS to see what actions are being taken and examine them more closely.
And, as some have said, multiplayer folks are seeing it a lot, so there's probably something there as well.
From the sound of it, I'd be examining all "list-oriented" functionality (inventory, mechlab, store, hiring hall, game lobby, mechlab) and make sure that the lists are being freed up correctly when the user leaves those screens and not just ignored in the expectation that garbage collecting will "fix it all" (god knows I've run across enough Java developers that expect the Java GC functions to work miracles with their code). I don't know how Unity does it, but I expect it's just as bad as most modern languages.
A scroll through the bug support subforum shows that a depressing amount of reports attach zero relevant info to the report beyond;
"My games not working, fix"
Steps to repeat : "play"
Files attached: none.
Systems specs/hardware attached: none.
Doing this is practically useless
Anybody else notice an increase in stuttering and frame rate drops with this patch? Not in the Argo just during combat. Not sure if it's certain maps.
One of our customers submitted a bug ticket a few years back with the single line: "Nothing works ok".
That one got saved for the blooper reel.
I definitely noticed it on my first (and thus far only) 1.2 mission. I wasn't sure if it was just because I had recently switched to the public beta and the game needed to do some just-in-time compilation of assets or what, but I wasn't going to say anything until I had more time to spend on 1.2.
Sadly (or happily... PoV is important), it's getting close to the beginning of school here and my kids' activities are all gearing up so my gaming time is getting dramatically cut into as we figure out scheduling and whatnot.
I can't remember exactly what it was off the top of my head, I know we had issues with memory allocation for their server (the 32-bit JVM we used at the time had to have its memory allocated in a continuous block, which meant the most you could allocate was 1.2 - 1.5 GB or so, and their server regularly hit that roof, causing an OutOfMemory exception), it might have been that.I'm sure that one was a simple matter to reproduce the bug right?
Just once? That is a daily problem report for me. When asked for more detail, the reply is often just as ambiguous.
- Comms Systems tooltips and descriptions still award morale instead of resolve
- There is a bug, where if you loose a mech in a mission (cored) then all the salvage you pick gets doubled.
Right there with you on the kids. Instead of getting a mission in before work, I'm making PBJ sandwiches for my kids lunches. Ahh, the joys of parenthood!
I had this happen just an hour ago... in my case, the duplicate Griffin that Glitch headcapped didn't show up in my mechbay, so it's possible this one's just cosmetic.
Had that issue a long time ago, it was they rearranged their office and didn't plug the system back in or hook it back up.
- In mechbay, in refit mode, In the FIREPOWER on_mouse_over blurb, the number takes into account only one missile from every launcher (for example an SRM6 counts as 8, instead of 48 dmg)
- This is also true for MGs (3 damage instead of 15)
Can you please move non relevant discusions to one of the myriad of other discussion threads and leave the beta thread for bug reporting issues so that the developers can see them easier?
Last edited:
Proper bug report method
Bug reports should be using the support tab at the top of the webpage or posted in the bug report subforum, with the tag "beta 1.2.0."
Not in a discussion thread, not even the patch notes discussion thread.
Support does not read this thread.
What you are posting (while appreciated) is not a bug report. And will not be noticed if not properly reported.
Last edited:
Well, Ironman works now for me.
It seems you have found something to lower the heat burden especially in the Dropship part of the game.
Sadly Maps are a big Trouble as Opfor Vehicles and now also Convy Vehicles get stuck and i had recently a Mission were only 2 of 4 of the convy made it to the extraction Point and the other 2 got stuck.
It was the mountaineous map withg the river where a serpentine road leads from a mining outpost to a Dropship Landing flat in the River.
1 Vehicle stuck b4 Crossing a Ford and 1 Vehicle stuck Right after Crossing the Ford in the first Serpentine.
Quite some Maps have pathways that seem to have become impassable and OpFor Vehicles get stuck on their spawn waiting to be found...
Had to withdraw from the Mission despite destroying all OpFor and have no Vehicle lost....a shame...will not Play the game in such a state.
I really like the game, i think ist great when it works and wish for more but pls fix the Maps!
It seems you have found something to lower the heat burden especially in the Dropship part of the game.
Sadly Maps are a big Trouble as Opfor Vehicles and now also Convy Vehicles get stuck and i had recently a Mission were only 2 of 4 of the convy made it to the extraction Point and the other 2 got stuck.
It was the mountaineous map withg the river where a serpentine road leads from a mining outpost to a Dropship Landing flat in the River.
1 Vehicle stuck b4 Crossing a Ford and 1 Vehicle stuck Right after Crossing the Ford in the first Serpentine.
Quite some Maps have pathways that seem to have become impassable and OpFor Vehicles get stuck on their spawn waiting to be found...
Had to withdraw from the Mission despite destroying all OpFor and have no Vehicle lost....a shame...will not Play the game in such a state.
I really like the game, i think ist great when it works and wish for more but pls fix the Maps!
- Status