Baffled! I Am Haunted By Invisible Objects At Internal Settlements

[niston]

One has to wonder then why they even bothered to place roombounds and portals.

I mean, they're there - It's just that they're (mostly) setup like ass.

 

Furthermore, I've recently learned that Umbra is fully capable of hardware accelerated, real time occlusion culling on decent hardware. But Beth doesn't use that, likely because potato consoles. Just like their default memory allocators, everything seems to cater to the lowest common denominator, without any (official) options for improvement. Funny story here, I was unironically told by people on a certain IRC channel that limiting RAM usage to 4GB and not using those other 60GB someone might have installed, is considered "good programming practice". Perhaps that goes a long way to explain the state of things.

[SKKmods]

Most likely junk left over from early development iterations.

[aurreth]

Limiting RAM to 4GB is done to support legacy 32 bit processors, or old development environments that people refuse to update. "Good programming practice" has nothing to do with it.

 

And yes, apparently room bounds/portals are left over from early development, and were then replaced with the precom/previs system when they realized what a pain it would be to try and box in every single room. When both systems are used in the same space (ahem, Vault 95) you run into issues, because modders don't generally exclude the room bound spaces from previs generation, and the two systems fight.

 

So best practice is probably to choose one or the other. In small spaces, with a limited amount of rooms, bounds/portals is likely more efficient (and things don't void when you delete a table.) For large builds, rip those out and use previs.

[1000101]

The fact that bethesda enables us to modify their stuff at zero cost does not mean the product is a "build to change" fail, rather we need to understand the limitations of, and be creative with, the ingredients we are given (for free) to cook with. Frustration is an optional state :wink:

 

"At zero cost?" "For free?" Sorry, but I paid for my copy, I didn't pirate it. So now what's their excuse for releasing a broken product seemingly without any QA? I'll grant you that we need to work within the limitations of the system, as we always do regardless of what we are talking about, but trying to say "we got it for free so shut up" is stupid since we didn't get it for free so we have every right to complain about a defective product. Being blasé about being sold a lemon just makes you spineless and your opinion worthless.

 

 

Limiting RAM to 4GB is done to support legacy 32 bit processors, or old development environments that people refuse to update.

 

Fallout 4 is not limited to 4GB of RAM, I routinely see the game itself using upwards of 6GB. As far as "support legacy 32-bit processors" - it doesn't. At all. The neither the game nor the CK will run on a 32-bit platform. It requires a 64-bit OS and a 64-bit x86 CPU, if you have anything else it won't run. Now, as far as targeting a 64-bit platform, the development tools wouldn't and couldn't impose an artificial memory barrier like that, if the developer used a memory allocator library (instead of calling the native system allocators directly) that library could impose a limit but as already stated, they don't. Further, if the developer refused to update their tools then they couldn't develop. The end-user doesn't have anything to update other than having the system requirements which are a 64-Bit OS on a 64-bit x86 CPU with the minimum installed RAM (which, I think, is 8GB for Fallout 4). Of course now you're going to say, "what about the .Net runtime vX.Y.Z? REEEEE!" Well, yes. You got me there. Sometimes you need to do platform updates. But we both know that isn't what you meant when you said "development environment" or if it is, then you don't know what a "development environment" is.

 

 

 

Lot's of misinformation on these forums, no wonder I never bother with them and I'm not sure why I did now.

[niston]

@1000101 A while ago, when I started playing this game, I noticed it wouldn't ever use more than roughly 4.5GB of RAM. Even tho my machine back then had 16GB. This didn't change when I upgraded to a machine with 4 times the RAM, so I wondered and since I happened to idle in a fallout4 IRC channel, I asked around there.

 

The reply I received is, to this day, the dumbest thing I ever read on the Internet (and we all know one can read a lot of dumb s#*! on there):

 

 

"This is done on purpose and it's considered good programming practice (not to use the available, free RAM and constrain your application to some arbitrary limit way below what is installed) you noob !!!111!11"

 

Turns out Beth in fact *does* use their own, little, shitty, broken crap memory allocators, instead of letting the OS do it's job. Thanks to FudgyDuff for fixing this s#*! with Buffout 4.

[aurreth]

 

Turns out Beth in fact *does* use their own, little, shitty, broken crap memory allocators, instead of letting the OS do it's job. Thanks to FudgyDuff for fixing this s*** with Buffout 4.

 

Consoles :(

[1000101]

@Niston

 

I know Buffout 4 has a different memory allocator for the engine, but I was unaware that the game wasn't using the system allocators. While system allocators aren't very fast and, some development environments implement their own heap to facilitate that, I would have assumed that they would use one that isn't a PoS.

 

"This is done on purpose and it's considered good programming practice"

 

I've been programming for over 30 years and have never heard that. Use as little resources as possible, yes, but "limit yourself to some arbitrary amount" is just dumb. If you can do the job in 1GB then great, but trying to faff about to make your code only use 1GB is wasted time. Having done programming in assembly for many years on systems were every bit counted and every cycle matters, it's laughable that a high level coder should think that they need to limit their memory usage like that on 64-bit systems (or even 32-bit systems "back in the day"). Not that one should waste memory, of course, but from experience - high level programmers are the most wasteful people on the planet and have no standing on the subject. "We need to conserve memory!" Says someone who uses 32-bits to store a boolean (1-bit).