Geck optimization

[WastelandLoner]

Hi,

Just curious about something, In the geck tutorial it talks about room boundaries, portals etc and while i understand the reasoning behind it, when i look thorugh existing interior cells in the geck, i cant seem to find any cases where they have been used.

(I have checked they are shown in the show/hide menu)

Are they really necessary, or should they only be used in certain circumstances, like depending on a cells size,content?

[prensa]

WastelandLoner - Hello!

"i cant seem to find any cases where they have been used"

Small interior locations won't use them much, neither will locations that are connected by many "teleport" doors.

Room Markers are used in the vanilla game for locations that are large uninterrupted areas.

The Dunwich Building & The Capitol Building interiors are very good examples of multiple uses of Room markers & portals.

As you noted, Portals & Rooms are turned off in View - Show\Hide in GECK by default & must be ticked for them to show up.

If you look at those locations in GECK you'll see they are multiple rooms without load doors.

These locations also have a lot of enemies & clutter so easing resource use is important.

Room Markers are good for easing memory use by only drawing stuff that's in view however they have one draw back.

Moveable clutter items will disappear if they are moved from one Portal connected Room Marker to another.

You can see this at work by going to The Dunwich Building, picking up a tin can from the first room on the left & dropping it by the stairs off to the right up ahead.

You'll note that as soon as the tin can comes to rest it will disappear, this is because it's still treated as belonging to the Room Marker zone you picked it up from.

It seems Room Markers haven't been updated, or can't be, to take into account Havoked clutter items.

It's not a problem if there's nothing of importance for the Player to pick up in the location & random junk clutter is unlikely to be knocked out of one Room Marker into another but it's definitely something to consider when choosing to use Room Markers & Portals.

It's the main thing that puts me off of using them.

I tend to prefer using more load doors & breaking a location up into manageable chunks.

You can actually get away with a fairly large area before running into trouble, take a look at some vanilla locations that have no Room Markers, like the "Museum of History Lower Halls", to get an idea.

There's also a warning system built into GECK that's not widely known, if a Cell starts to become too memory intensive a coloured border appears around the Render Window in GECK.

It's called the Memory Usage Frame, it's normally turned on by default & is listed if you right click on the Render Window & select "Render Window Properties". Show Memory Usage Frame should be ticked.

The frames seem to mean:

Green - seems to be warning you to expand no further.

Grey - is the beginning of tipping over the edge in size, remove some clutter objects etc. to get back down.

Red - DANGER, the cell is too big memory wise. Can result in freezing or CTD's in game as well as other oddities, break it up into smaller parts.

There's little documentation on this feature so I've had to surmise their meaning based on my experiences.

I first wrote about the Memory Usage Frame here:

http://forums.nexusmods.com/index.php?/topic/878363-show-memory-usage-frame/

Hope this helps!

Prensa

Edited October 30, 2013 by prensa

[WastelandLoner]

Very helpful thanks, I checked out the dunwich building and capitol building and saw the markers, I have also experienced objects disappearing when dropped/moved before, but never knew why.

Also, i know its completely unrelated and very random, but i recently experienced the bug in the pitt dlc where you fall through the roof in the steelyard, and saw that it is to do with having point lookout, the bug itself is not the issue but i am very confused as to why it occurs. Are you able to shed any light on this?

 

Thanks

[prensa]

In response to post #9913801. #9923913 is also a reply to the same post.

Mattydigs - Hello!

FOOK2 & FWE are generally considered to be incompatible, they're both major gameplay changers & tend to clash. Most people choose one or the other.

Your MMM plugins, when using FWE, should look something like this:

Mart's Mutant Mod.esm

Mart's Mutant Mod.esp
Mart's Mutant Mod - DLC Anchorage.esp
Mart's Mutant Mod - DLC The Pitt.esp
Mart's Mutant Mod - DLC Broken Steel.esp
Mart's Mutant Mod - DLC Point Lookout.esp
Mart's Mutant Mod - DLC Zeta.esp
Mart's Mutant Mod - FWE Master Release.esp
Mart's Mutant Mod - FWE Master Release + DLCs.esp

Mart's Mutant Mod - FWE Master Release.esp from FOIP replaces most of the MMM plugins including the Menu plugin. Only the MMM DLC plugins are needed (If you have the DLC's of course).

You should untick & remove these:

Mart's Mutant Mod - Zones Respawn.esp
Mart's Mutant Mod - Natural Selection.esp
Mart's Mutant Mod - Tougher Traders.esp

Mart's Mutant Mod - Master Menu Module.esp

"besides flickering clothing and weapons, which I don't mind"

That sounds like a classic archive invalidation issue, mod added textures act like chameleons.

Using one of the methods of archive invalidation fixes it.

"I've tried archive invalidated"

You mean the stand alone ArchiveInvalidation Invalidated?

http://fallout3.nexusmods.com/mods/944/?

If that does not work for you & you use a mod manager there's a built in archive invalidation tool in there.

If you use "Old" FOMM click on Toggle Invalidation on the right.

For "New" FOMM you have to go to the buttons at the top & select:

Tools - Archive Invalidation

NMM has built in Archive Invalidation too.

DON'T USE BOTH MOD MANAGER & STAND ALONE METHODS TOGETHER.

Note FOMM/NMM's version often needs to be toggled off & then back on again when you add in a new mod.

Hope this helps!

 

EDIT: this post has appeared in the wrong thread on the Forum section of the Nexus so please ignore there. :)

Prensa

Edited November 8, 2013 by prensa

[Deleted1205226User]

Hello prensa !

The link about the Memory Usage Frame leads to an error page. I would like to read this documentation, is there another access ?

[prensa]

pixelhate - Hello!

 

"The link about the Memory Usage Frame leads to an error page."

 

Ah yes, it's in the Modder's section.

 

"I would like to read this documentation, is there another access ?"

 

I'll repost it here, it started off as a question but I amended it with my own findings when it became apparent it was a little known feature. :smile:

 

I also found a link with over large cells & the known bug of scrambled navmesh in .esp's so it's worth putting out there.

 

Original post:

 

Hello!

I don't normally have to ask questions but I've come across something I've never seen before. :smile:

Thought I'd post this in the mod authors section as I figured it would more likely be known here if at all.

I recently built a cell a fairly large but not, or so I thought, too large a cell.

I've had a few issues in there, not entirely certain it's specific to this cell but it seems likely.

I've recently noticed something in GECK that I never spotted before.

On this cell in the Render window is a thin red border framing the inside of the Render Window.

Very subtle & easily overlooked.

Well I checked in the Render Window options & found:

Show memory usage frame

Unticking that makes the red frame go away so obviously it's that.

The red frame seems to be a warning that the memory usage of the cell is high.

Reducing the cell by removing chunks changed the red frame to another color & further reductions retuned to no framing as normal.

There seems to be no documentation for this GECK function on http://geck.bethsoft.com.

They do have the function listed by wording but no information:

http://geck.bethsoft...php/Preferences

I'm curious if anyone else has seen this?

If so, how dire is the warning?

Is it merely a caution or an urgent "turn back!". :smile:

How can you tell if your cell is too large or at least too memory intensive?

Is it the quantity of items?

I know all about room portals & occlusion to alleviate large cells but room portals have issues with havok objects & I like to use them sparingly.

I normally cut up cells into bite size chunks but sometimes certain builds require unbroken rooms.

Now oddly enough, cutting the cell brutally in two to test & that seemed to make things worse in game.

Travelling to the outside world from the cell was fine but travelling between the two sections seemed sluggish & unstable (worth noting that cut in two the two separate sections still had red warning frames & thus must be large).

It was better when it was a whole, large cell that you travelled only out of & into the outside worldspace.

I have seen mention before of there being a difference between travelling from a large cell to an established worldspace & travelling from a large cell to another large cell. The large cell to another large cell being problematic.

I'd appreciate information on this "Show memory usage frame" feature, anyone's experience of it, information on maximum cell size. Or even just thoughts on the issues mentioned.

Thank-You for taking the time to read this, if you did. :smile:
If you didn't, what are you doing loitering around down here?

Prensa



~~~~~~~~~~~Additional Discoveries~~~~~~~~~~~~~~~~



EDIT: Okay, seems to have drawn a blank with people so far. :smile:

I've been playing around since spotting this memory usage frame & have discovered a few things of interest.

Before the Red frame comes a Green frame.

Frequent modders will probably know about the bug that .esp added cells have with navmesh, namely that the navmesh in certain cells will be fine untill you leave it. Coming back into the cell though, the navmesh will be messed up & any NPC's or creatures will be scrambled due to the messed up navmesh.

Now the work around for this has always been to convert a mod with new cells into an .esm.

The odd thing with the bug has always been that it does not affect all mod added cells.

Well I had another cell that displayed the red border I mention above & it, along with the other cell with the frame had that very same navmesh bug.

I split this cell into two parts thus reducing each cell's memory usage & removing the warning red frame.

Now the cell's navmesh is no longer afflicted with the navmesh bug.

It seems, not yet confirmed, that the navmesh scramble issue in .esp's is connected to the cell triggering that Memory Usage Frame warning.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EDIT: 4 March 2013

Frames around the Render window are:

Green - Grey - Red

They seem to mean:

No frame around the Render window is ideal, all is well.

Green - seems to be okay but warning you to expand no further.

Grey - is the begining of tipping over the edge in size, remove some clutter objects etc. to get back down.

Red - DANGER, the cell is too big memory wise. Can result in freezing or CTD's in game as well as other oddities, break it up into smaller parts.

It's not the "physical" size of the cell that trigger the warning, you can have a single room trigger the warning frames if you pack it with high detail clutter. Conversely you can have a large collection of rooms in your cell, with little clutter, not trigger the warning frames.

Prensa

Edited November 8, 2013 by prensa

[pkleiss]

I thought I'd add my 2¢ here...

 

I spent quite a lot of time researching the navmesh bug back when FO3 was new and found it's specific cause and reported it back to Bethesda in hopes that they would fix it in a patch. That fix never happened, but I can tell you this. The navmesh bug has nothing to do with the resource utilization warning frames you are talking about.

 

What causes the navmesh bug is looping the navmesh around behind where your entry portal is located. If you make a linear navmesh, you won't get the bug. But if you make an entry portal and have the navmesh loop around that teleport triangle, you'll get it. I'll draw a little text picture of what I mean.

 

|----------------|

| | x = teleport marker

| x--------------|---x - or | = navmesh path

| |

|----------------|

 

 

-------------|

|

x-------------|----------x

|

-------------|

 

The first example will cause the navmesh bug, while the second won't. You don't have to necessarily connect the loop all the way around and behind the entry as I have drawn it, the path just needs to end up both in front and behind the entry portal. I was able to replicate and remove the bug at will with a single navmesh triangle in a very small cell using this technique.

 

As for the resource warning frame....

 

I have exceeded the red frame multiple times without incident and have released said cells to the world, again without incident. I did use portal and room markers in said cells. You are correct that the colored frame is a warning, but it is mostly unnecessary at this point. It's original use was for the devs in creating cells as a reminder to keep cell resources low enough that they would not exceed the minimum requirements for playing the game. Most PCs nowadays far exceed these minimum requirements, thus making a cell that is at 200% probably won't give most GPUs any fits whatsoever. In fact, room bounds are probably irrelevant at this point as well - that is, for those who have PCs that aren't 10 years old.

Edited November 9, 2013 by pkleiss

[prensa]

pkleiss - Hello!

"The navmesh bug has nothing to do with the resource utilization warning frames you are talking about."

Ah but it does. :smile:

I can actually turn on the bug by reaching the point where the cell warns you with the frames.

At that point leaving the cell & coming back into it results in the navmesh getting scrambled.

Any NPC in there will act like there's no navmesh in the room.

Worth repeating, with this bug the cell is fine until you leave & kicks in only when you re-enter.

Reducing the cell so that the warning frame goes away will restore the navmesh's function.

Neither location I've seen this in conformed to your example of looping around.

The scrambled navmesh issue is a well known bug, the accepted method to fix it is to make the navmesh adding mod an .esm.

Navmesh added by an .esm seem unaffected by the bug regardless of cell size, though It's still not a good idea to have a cell that trips the frame warning system anyway, after all it is a warning system. :smile:

Since disovering the frame warning system the only vanilla location I've seen a red frame around is across the bridge in The Pitt.

It had always been noted that some cells were fine while others could incur the bug if not in an .esm but the reason was unclear.

It seems the reason some are affected & not others is down to cell size, or rather it's resource use as indicated by the frame warnings.

"I have exceeded the red frame multiple times without incident and have released said cells to the world, again without incident."

The first cell that I had a red frame on triggered freezes & even blue screens. I'd never had a blue screen on my set up until then & never again since eliminating the problem.

The cell would be fine sometimes but often unstable.

It was a complex & cluttered cell which was well over the red warning frame.

Only splitting it in half removed the warning frame so I know I was well over.

I've had no instability with green frame warnings but green frames trigger the navmesh issue to which I refer.

But as I said above, if the mod adding the cell is an .esm then no scrambling of the navmesh occurs regardless of size/warning frames.

A bit like the other well known bug with .esp's, NPC's having mismatched head/bodies, also fixed by making the .esp an .esm.

Until that cell I'd never seen a warning frame & there seemed no documentation of it, hence my original question about it.

 

"in hopes that they would fix it in a patch. That fix never happened"

Funnily enough the exact same bug seems to exist in Skyrim, with the same make it an .esm solution:

http://forums.nexusmods.com/index.php?/topic/558598-how-do-we-deal-with-the-navmesh-bug/

Not sure if they've fixed it with a patch there yet.

Anyway my findings don't change the accepted fix, make it an .esm, just provide a clue as to why the bug affects some cells & not others in .esp's.

Prensa

Edited November 10, 2013 by prensa

[rickerhk]

They finally did fix the navmesh bug in Skyrim. Hopefully it will still be fixed for Fallout 4 :)

 

But there are other bugs in Skyrim that can only be fixed by esmifying too. Which is not surprising, given that the game and all DLC's are esm format. I'm sure they didn't spend too much time testing mods in esp format.

[prensa]

rickerhk - Hello!

"They finally did fix the navmesh bug in Skyrim."

That's good to know. :)

I wondered since that thread I found was last posted in 2012 & there was mention of a coming official solution.

"Hopefully it will still be fixed for Fallout 4"

Fingers crossed. :)

"But there are other bugs in Skyrim that can only be fixed by esmifying too. Which is not surprising, given that the game and all DLC's are esm format. I'm sure they didn't spend too much time testing mods in esp format."

I'd say you're right there.

An .esm seems the best way to avoid these issues, just a shame GECK will only edit .esp's meaning the nuisance of converting between the two.

Still a lot of fun to be had modding though. :)

Prensa