Glitch Possible cause for crashes?

[Swift BountyHuntin Rick]

It doesnt show up on screen but its that cmd window that opens before the actual game does after logging in

 

[Filipe]

Yeah, sometime CTRL Alt Del does nothing for a while. Esc probably closes the responsive console in the background of the game idk

tbh the console looks really interesting, I wonder if there's any kind of advanced/custom configs we can do from the cmd line. it's my first time seeing a multi-player client utilize a visible cmd launcher, which is actually really neat given our ability to see when the game hangs up/ desyncs from local time/sends heartbeats all funky, etc. in real-time.

think the devs are willing to give us some custom cmd-based memory settings? lol

 

[xXtpw_360Xx]

It doesnt show up on screen but its that cmd window that opens before the actual game does after logging in

Well the console opens up a Notepad Tab loading the games files then creates a separate tab for the game logging in. But I think its just me

 

[Swift BountyHuntin Rick]

The user -us- do not have access to write into the console, just read it seems. No sv_cheats 1 for oylur future. -garry's mod reference. I remember the days. But yeah no. The escape button always helps me keep as much time inside the game rather than hanging there futile and crying hahahah

 

[Falco]

That thread is incorrect... while the loading screen issues are indeed caused by memory usage issues, the proposed workaround has nothing to do with the underlying cause. I'm not surprised to hear that it didn't help you, because it won't help.

There is a limit to how much memory a program can access. The loading screen issues are happening because TLOPO is trying to use more memory than it's allowed to, not because there's a lack of available memory. That is why people are getting out of memory errors despite having an abundance of available memory.

Unfortunately, I don't think there's much we can do about it. I've already tried toggling every single setting in the game, and even reducing the game resolution to the bare minimum, and no matter what the memory usage remains exactly the same.

You are wrong too.

Any running program (process, the active entity) is given the impression that it has all the physical memory available, when in reality, only currently needed resources go through the page table in the MMU to be mapped physically.

The devs use Python, which is garbage collected, so they don't have that much power inside the engine when it comes to memory. The only off-boundaries memory error I can think of (the only error that's not a memory leak) is accessing more elements in an array than it has. And with Python, the size is calculated and assigned at run-time.

So technically, one process CAN access all the memory you have. That's why you can have a memory leak, when data is dynamically allocated, but not freed. (The memory fills up) Before, processes couldn't go off-boundaries of the stack memory, but nowadays the OS will give a process more stack memory at run-time if it needs to, in order to prevent the stack of overflowing.

And the reason why the memory stays the same after you changed so many settings is because any data about graphics is stored in the VRAM. (unless you have an integrated GPU, because on-board GPUs use RAM to store the frame buffer, they don't have memory of their own)
What you were monitoring was most likely the RAM, not the VRAM.

 

[Filipe]

You are wrong too.

Any running program (process, the active entity) is given the impression that it has all the physical memory available, when in reality, only currently needed resources go through the page table in the MMU to be mapped physically.

The devs use Python, which is garbage collected, so they don't have that much power inside the engine when it comes to memory. The only off-boundaries memory error I can think of (the only error that's not a memory leak) is accessing more elements in an array than it has. And with Python, the size is calculated and assigned at run-time.

So technically, one process CAN access all the memory you have. That's why you can have a memory leak, when data is dynamically allocated, but not freed. (The memory fills up) Before, processes couldn't go off-boundaries of the stack memory, but nowadays the OS will give a process more stack memory at run-time if it needs to, in order to prevent the stack of overflowing.

And the reason why the memory stays the same after you changed so many settings is because any data about graphics is stored in the VRAM. (unless you have an integrated GPU, because not all, but most of them use RAM to store the frame buffer, because they don't have memory of their own)
What you were monitoring was most likely the RAM, not the VRAM.

so in short the only way to really circumvent this problem is to buy a higher-memory GPU?

 

[Falco]

so in short the only way to really circumvent this problem is to buy a higher-memory GPU?

No, because doesn't matter whether the engine indefinitely allocates a graphical resource or just a variable, at some point memory will be filled up. Another form of memory leak is accessing an address that's protected by the kernel, where memory size doesn't matter.

And who knows, this probably isn't even a memory leak issue, it could be problem on the server-side when sending packets.

The only solution so far is to wait for fixes.

 

[Will Callecutter]

And the reason why the memory stays the same after you changed so many settings is because any data about graphics is stored in the VRAM. (unless you have an integrated GPU, because not all, but most of them use RAM to store the frame buffer, because they don't have memory of their own)
What you were monitoring was most likely the RAM, not the VRAM.

Yeah, I didn't know about this VRAM thing. I suppose explains why there's such a massive difference in apparent RAM usage between my two computers. One is a custom desktop, TLOPO uses about 1.1GB of RAM. The other is a laptop with integrated graphics, and on that TLOPO uses about 1.7GB of RAM. I was concerned about why the laptop was using so much more RAM, but your comment explained it- some of TLOPO's memory usage on the desktop is on the VRAM, whereas on the laptop it's all on the RAM since it has integrated graphics. Correct?

And who knows, this probably isn't even a memory leak issue, it could be problem on the server-side when sending packets.

Could be, but my desktop has has never had issues with the loading screen, while my laptop consistently gets a stuck loading screen on probably 95% of the play areas in game- they're polar opposites. The game is set up the same on both, so I figured it was a game issue.

 

[Falco]

Yeah, I didn't know about this VRAM thing. I suppose explains why there's such a massive difference in apparent RAM usage between my two computers. One is a custom desktop, TLOPO uses about 1.1GB of RAM. The other is a laptop with integrated graphics, and on that TLOPO uses about 1.7GB of RAM. I was concerned about why the laptop was using so much more RAM, but your comment explained it- some of TLOPO's memory usage on the desktop is on the VRAM, whereas on the laptop it's all on the RAM since it has integrated graphics. Correct?



Could be, but my desktop has has never had issues with the loading screen, while my laptop consistently gets a stuck loading screen on probably 95% of the play areas in game- they're polar opposites. The game is set up the same on both, so I figured it was a game issue.

Correct, resources reside in main memory, because integrated GPU's don't have memory of their own. (They are just a part of the CPU, such AMD processing units are called APUs, Intel doesn't use that name though, they just like to make a list of the specs, where you have the CPU and "Integrated HD Graphics" mentioned separately)

 

[Will Callecutter]

Now, someone told me a while ago that 32 bit programs like TLOPO can only access roughly 2GB of physical memory (not VRAM). On my laptop, which has integrated graphics, TLOPO runs fine until I try to load any new area, and during the loading screen, RAM usage starts to increase, and once it gets near 2GB the loading screen gets stuck and you have to restart it.

My desktop never has loading screen issues, and I think that's because the RAM usage never gets near 2GB since some of the memory usage is on that VRAM instead of RAM.

So, maybe computers with integrated graphics are more likely to have loading screen issues since the physical memory usage is higher.

 

[Falco]

Now, someone told me a while ago that 32 bit programs like TLOPO can only access roughly 2GB of physical memory (not VRAM). On my laptop, which has integrated graphics, TLOPO runs fine until I try to load any new area, and during the loading screen, RAM usage starts to increase, and once it gets near 2GB the loading screen gets stuck and you have to restart it.

My desktop never has loading screen issues, and I think that's because the RAM usage never gets near 2GB since some of the memory usage is on that VRAM instead of RAM.

So, maybe computers with integrated graphics are more likely to have loading screen issues since the physical memory usage is higher.

It's not 2, it's 4 GBs. One way to remember this is by 2^32, where 32 represents the bits themselves and 2 is just the unit "bit", because it can either store 0 or 1, that's two values. The result is 4 GBs of RAM. And yes, this doesn't apply to VRAM, if you happen to have a dedicated GPU. But that is exactly the purpose of the GPU anyway - to be a separate processing unit specifically for processing graphics.

Architecturally, 32-bit microprocessors can address up to 4GB of memory, in software the bit talk is used only for compatibility reasons, and no, it doesn't mean you will keep playing if a memory leak occurs at the time of you playing. It will still kick you out, no matter what software you use, doesn't matter if it's compatible or not - memory leaks cause crashes.


P. S. : I'm sorry for the sloppy explanation, I just woke up and I still have yet to liven up. But I noticed that my explanations are not so "hardcore" when I'm half awake. That's a good thing, otherwise I unconsciously make them unnecessarily complex.

 

[Will Callecutter]

It's not 2, it's 4 GBs. One way to remember this is by 2^32, where 32 represents the bits themselves and 2 is just the unit "bit", because it can either store 0 or 1, that's two values. The result is 4 GBs of RAM. And yes, this doesn't apply to VRAM, if you happen to have a dedicated GPU. But that is exactly the purpose of the GPU anyway - to be a separate processing unit specifically for processing graphics.

You're correct... but I see where that 2GB number came from now- it looks like, for some odd reason, Windows has an additional limitation of just 2GB (which I was able to verify with TLOPO). Which is much worse of an issue for computers with integrated graphics... in fact, on my laptop, TLOPO almost hits that just from loading in to the game initially... doing pretty much anything will push it over and result in a stuck loading screen.

There seem to be two camps of people here... one group that gets infrequent crashes, and another that suffers from incessant loading screen crashes/freezes/etc. I'll bet that most of the people who have loading screen issues have integrated graphics. My desktop has dedicated graphics, and its RAM usage is much lower because of it... takes an hour or more for RAM usage to hit 2GB.

 

[Falco]

You're correct... but I see where that 2GB number came from now- it looks like, for some odd reason, Windows has an additional limitation of just 2GB (which I was able to verify with TLOPO). Which is much worse of an issue for computers with integrated graphics... in fact, on my laptop, TLOPO almost hits that just from loading in to the game initially... doing pretty much anything will push it over and result in a stuck loading screen.

There seem to be two camps of people here... one group that gets infrequent crashes, and another that suffers from incessant loading screen crashes/freezes/etc. I'll bet that most of the people who have loading screen issues have integrated graphics. My desktop has dedicated graphics, and its RAM usage is much lower because of it... takes an hour or more for RAM usage to hit 2GB.

"it looks like, for some odd reason, Windows has an additional limitation of just 2GB"
Lol, it's not an odd reason. Operating systems reserve some space for themselves to run and obviously you wouldn't want user-space applications to access memory that's reserved for the OS, if an application tries this, it will result to a segmentation fault. (The OS will handle such faults by forcing the application to terminate/crash) A way to prevent those faults, the OS will put constraints on how much memory user-space applications can address (the rest of the memory left). That's why the limitation is 2GBs for applications' virtual address spaces, although not all of this virtual address space is in memory when the game is executing, thanks to a technique called paging.

It's a very complicated topic, but I tried to explain it as simple as possible.