Navigation section

Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

BRING BACK PANELS

George

George

Willard Networks Whistleblower
Joined
Nov 19, 2021
Messages
1,550
BRING BACK PANELS WE NEED PANELS

It didn't fix the overflow issue, people are still having problems

Those who DO have the issue don't deserve to play. I do not care about your lenovo laptop from the early 1800's.​
 
real, the only issue is that some people were making like giga resolution panels but that could be solved by just having staff review the images before theyre approved as webpanels
 
Panels don't just cause buffer overflows - but with enough panels in a concentrated area, the server will have to load them individually to your clientside.

For people with lower end PCs or haven't installed their GMOD on an SSD, you are rolling a dice for it to crash your game instead of a buffer overflow. What it fixed were critical crashings. Overflows were another matter altogether.
 
Imperator RAD-X said:
Panels don't just cause buffer overflows - but with enough panels in a concentrated area, the server will have to load them individually to your clientside.

For people with lower end PCs or haven't installed their GMOD on an SSD, you are rolling a dice for it to crash your game instead of a buffer overflow. What it fixed were critical crashings. Overflows were another matter altogether.
Click to expand...
Perfect, let them crash.
 
Bring panels back. And make rules so they don't get spammed on things that are not needed.
 
If ur pc is too weak to load an image I think you have bigger issues then not being able to play a gmod server
 
In general the code is very shitty and its a bad idea, as much as I love them as an immersion tool.

Regardless of the img size it can suck up a lot of VIDEO memory, many gigs worth, which is something a lot of folks are short on. This is just because of how these textures are inefficiently stored in vram, as the engine was never really designed to do this sort of thing. However, image size makes this worse ofc (exponentially so, in a literal way. more on that later).

This can cause random crash to desktops.

Fact of the matter is that we have a budget that we can spend. A budget that is already spent on things like stormfox, super high def models & textures, a fancy AF map, thousands of lua code files, etc. The more things we add, the more we take from the budget, and the more issues we will have moving forward.

Also, it contributes to people who get stuck in buffer overflows. I'm really tired of people trying to point to ONE THING causing them. There is not one thing that causes buffer overflows; sorry. Thats why they're not 100% fixed. There are things that contribute to it, and some of those things have been fixed. Which is why it isn't as bad as it used to be. Some of them remain, and panels can contribute to buffer overflows.

Imperator RAD-X said:
Panels don't just cause buffer overflows - but with enough panels in a concentrated area, the server will have to load them individually to your clientside.

For people with lower end PCs or haven't installed their GMOD on an SSD, you are rolling a dice for it to crash your game instead of a buffer overflow. What it fixed were critical crashings. Overflows were another matter altogether.
Click to expand...
All of the panels are loaded individually while you are joining. If they are not cached in your gmod cache folder, the server sends you a list of imgur links and forces your PC to very slowly download them (using some outdated protocols). That can cause an overflow while you're trying to join. Or, if a new one is added, everyone's gotta download and that can cause timeout/overflow as well.

The real issue is memory consumption that can lead to frequent crashing as, when there is no memory left, kernel makes game goes poof.

Panels are all shoved into video memory as uncompressed 4 dimensional bitmaps. Red, green, blue, alpha for each pixel. This means that each pixel is four bytes. They are stored in the closest square (power of 2) that fits their largest dimension. So, an image of (1000x500) is stored in a (1024x1024) 4D matrix. That is 1,048,576 pixels or, >4MB. The next size up is >16MB, and the next step is >68MB, then >256MB and so on.

You might have an image that is 100KB on disk, that is 16MB in ram just because of how much of a bitch uncompressed textures can be.

Now the real issue is that they are not culled. They are always rendered ALL THE TIME that you are on the server no matter where they are, how close they are together, etc etc.

You can read more about that process here: hidden surface determination

That is because the janky ass code that sets these up does not set up occlusion culling on the materials because they are not eligible for such a thing (this stuff is all calculated by the engine clientside). Thanks Chessnut.

For that to work it has to be attached to an entity of some kind then have it's transmission state set to TRANSMIT_PVS. Or at least, thats one method of doing it, theoretically. It'd be a good bit of work though.

Don't take my word for it though, you can read the code for yourself.
 
In technicality you could make your things into props, instead. Like how the propaganda posters look like on the server or the portraits.

But that requires more manual maintenance and server restarts for content packs. At best a twenty-four-hour waiting time for when ever it gets updated in theory.
 
Donovin Jones hate thread
M!NT said:
In general the code is very shitty and its a bad idea, as much as I love them as an immersion tool.

Regardless of the img size it can suck up a lot of VIDEO memory, many gigs worth, which is something a lot of folks are short on. This is just because of how these textures are inefficiently stored in vram, as the engine was never really designed to do this sort of thing. However, image size makes this worse ofc (exponentially so, in a literal way. more on that later).

This can cause random crash to desktops.

Fact of the matter is that we have a budget that we can spend. A budget that is already spent on things like stormfox, super high def models & textures, a fancy AF map, thousands of lua code files, etc. The more things we add, the more we take from the budget, and the more issues we will have moving forward.

Also, it contributes to people who get stuck in buffer overflows. I'm really tired of people trying to point to ONE THING causing them. There is not one thing that causes buffer overflows; sorry. Thats why they're not 100% fixed. There are things that contribute to it, and some of those things have been fixed. Which is why it isn't as bad as it used to be. Some of them remain, and panels can contribute to buffer overflows.


All of the panels are loaded individually while you are joining. If they are not cached in your gmod cache folder, the server sends you a list of imgur links and forces your PC to very slowly download them (using some outdated protocols). That can cause an overflow while you're trying to join. Or, if a new one is added, everyone's gotta download and that can cause timeout/overflow as well.

The real issue is memory consumption that can lead to frequent crashing as, when there is no memory left, kernel makes game goes poof.

Panels are all shoved into video memory as uncompressed 4 dimensional bitmaps. Red, green, blue, alpha for each pixel. This means that each pixel is four bytes. They are stored in the closest square (power of 2) that fits their largest dimension. So, an image of (1000x500) is stored in a (1024x1024) 4D matrix. That is 1,048,576 pixels or, >4MB. The next size up is >16MB, and the next step is >68MB, then >256MB and so on.

You might have an image that is 100KB on disk, that is 16MB in ram just because of how much of a bitch uncompressed textures can be.

Now the real issue is that they are not culled. They are always rendered ALL THE TIME that you are on the server no matter where they are, how close they are together, etc etc.

You can read more about that process here: hidden surface determination

That is because the janky ass code that sets these up does not set up occlusion culling on the materials because they are not eligible for such a thing (this stuff is all calculated by the engine clientside). Thanks Chessnut.

For that to work it has to be attached to an entity of some kind then have it's transmission state set to TRANSMIT_PVS. Or at least, thats one method of doing it, theoretically. It'd be a good bit of work though.

Don't take my word for it though, you can read the code for yourself.
Click to expand...
i ain’t reading all of that, add panels back
 
Imperator RAD-X said:
In technicality you could make your things into props, instead. Like how the propaganda posters look like on the server or the portraits.

But that requires more manual maintenance and server restarts for content packs. At best a twenty-four-hour waiting time for when ever it gets updated in theory.
Click to expand...
twenty-four, heh
 
M!NT said:
In general the code is very shitty and its a bad idea, as much as I love them as an immersion tool.

[...]
Click to expand...
Thanks for the detailed explanation. Very interesting read - I won't pretend to be knowledgeable about any of it, but it defintely helped with understanding some of the underlying mechanics and why the panels aren't optimal.

<3
 
Well. With the explanation I've given, I'm going to go ahead and mark this as declined. Thanks.
 
You must log in or register to reply here.
Back
Top