Major bugs caused by v1.5 Thread 2

Post » Fri Aug 21, 2009 5:47 pm

Well clearly I'm not missing much by not actually playing this game all that often, despite having been foolish enough to have patched before seeing all this.

However, and keep in mind I know nothing about navmeshes other than they're a PITA to make, wouldn't it be super-simple to fix this whole mess all around for Bethesda to just make the GECK save new mods as ESM files?
User avatar
Mashystar
 
Posts: 3460
Joined: Mon Jul 16, 2007 6:35 am

Post » Sat Aug 22, 2009 7:26 am

Esms have faults and limitations that esps don't have. Esms can't modify each other without extra wizardry, wizardry that the geck doesn't provide.

An esm can add new things, but it can't edit existing things. The changes will simply roll back to fallout's esm state, if i'm not mistaken.
User avatar
Amanda Leis
 
Posts: 3518
Joined: Sun Dec 24, 2006 1:57 am

Post » Sat Aug 22, 2009 12:05 am

Esms have faults and limitations that esps don't have. Esms can't modify each other without extra wizardry, wizardry that the geck doesn't provide.

An esm can add new things, but it can't edit existing things. The changes will simply roll back to fallout's esm state, if i'm not mistaken.

UNLESS you're using 1.5, in which they can.
User avatar
Lyd
 
Posts: 3335
Joined: Sat Aug 26, 2006 2:56 pm

Post » Fri Aug 21, 2009 6:07 pm

I'm experimenting with that now... not entirely sure yet, but it may be the case.

But also, remember that .esm files load high in the load order automatically.

In Phalanx' case, I cannot make it all an .esm because lotsa mods conflict with some of Phalanx' content. I will end up with an .esm and an .esp, is how it looks, for what's in mainfollowermodule now.

If you're editing an external cell and have changed the navmesh, there's something extra you need to do to your navmesh to make it override fallout3.esm's. But me being a newb I don't understand just what that is.


Cool, I can deal with that - I've not had to play with .esm's and was trying intentionally to keep everything for my mod in a .esp to avoid conflicts.

Fortunately I have not modified any of the Fallout3 game whatsoever (and will only do so as the last step to add the entry-way) - I created my own world space. Thus far I've done a 10 x 6 cell exterior Business District (its a lead-up area to my main area), and I have alot more exterior area that I'm going to be making an Navmeshing. So far I've Navmeshed most of the exterior cells I've created, so hopefully I wont have to change anything with it other than to move it all into a .esm.

My mod will be Very large, but especially in the sense that I'm focusing on level design and making huge, interesting new places to go and explore with several quests and a well-defined theme - light on the coding side (so far). So the impacts to the cells I've made is where my big concern is - I have 5 large interior cells in addition to the exterior one described above. If I seem to be freaking out about this, it's just my over-worry about losing so much work.

Thanks for the testing, I owe you one.

Miax
User avatar
DeeD
 
Posts: 3439
Joined: Sat Jul 14, 2007 6:50 pm

Post » Sat Aug 22, 2009 3:38 am

Esms have faults and limitations that esps don't have. Esms can't modify each other without extra wizardry, wizardry that the geck doesn't provide.

An esm can add new things, but it can't edit existing things. The changes will simply roll back to fallout's esm state, if i'm not mistaken.
From all I've gathered, actually, those ONAM's (overridden forms) aren't needed for an ESM to alter the contents of another ESM. Neither my Anchorage.ESM or ThePitt.ESM have the ONAM's in their file headers and everything works just fine. If ever the "wizardry" were in fact needed, it's just adding the overridden refs to that ONAM list, but I really don't think it's needed from all I've seen. Could be that adding an ONAM to an esp fixes things with 1.5 if an ESM ref is edited?
User avatar
ashleigh bryden
 
Posts: 3446
Joined: Thu Jun 29, 2006 5:43 am

Post » Sat Aug 22, 2009 12:59 am

So, unless/until Bethesda fix this bug (if bug it is), mods that add new non-persistent content should be released as .ESMs, and mods that edit existing non-persistent content should make the edited items persistent. And mods that do both should be released as an .ESM/.ESP pair.

Do I understand correctly?
User avatar
saxon
 
Posts: 3376
Joined: Wed Sep 19, 2007 2:45 am

Post » Sat Aug 22, 2009 12:16 am

Esms have faults and limitations that esps don't have. Esms can't modify each other without extra wizardry, wizardry that the geck doesn't provide.

An esm can add new things, but it can't edit existing things. The changes will simply roll back to fallout's esm state, if i'm not mistaken.


UNLESS you're using 1.5, in which they can.


Pretty much what I figured, so 1.5 fixes one of the long-standing issues with the way the ESM mechanism works for modifying the contents of another ESM. A good thing IMO, as long as they get around to fixing how a normal ESP behaves, because if everyone and his uncle follows the advice of turning thousands of refs into persistent refs, those will be the mods I won't be using because I don't relish having 3GB save game files :)
User avatar
sara OMAR
 
Posts: 3451
Joined: Wed Jul 05, 2006 11:18 pm

Post » Sat Aug 22, 2009 7:13 am

From all I've gathered, actually, those ONAM's (overridden forms) aren't needed for an ESM to alter the contents of another ESM. Neither my Anchorage.ESM or ThePitt.ESM have the ONAM's in their file headers and everything works just fine. If ever the "wizardry" were in fact needed, it's just adding the overridden refs to that ONAM list, but I really don't think it's needed from all I've seen. Could be that adding an ONAM to an esp fixes things with 1.5 if an ESM ref is edited?


What I know for sure is this.

As a test, I dumped my entire mainfollowermodule, which contains navmesh replacements for a few exterior cells, into an .esm. I found that my followers were obeying fallout3.esm's navmesh, not mine. Quarn said ONAM thingies were needed in my .esm version for them to use my navmesh instead.
User avatar
Marcia Renton
 
Posts: 3563
Joined: Fri Jan 26, 2007 5:15 am

Post » Sat Aug 22, 2009 2:31 am

What I know for sure is this.

As a test, I dumped my entire mainfollowermodule, which contains navmesh replacements for a few exterior cells, into an .esm. I found that my followers were obeying fallout3.esm's navmesh, not mine. Quarn said ONAM thingies were needed in my .esm version for them to use my navmesh instead.
Hmmm... Maybe it's just NAV meshes? :shrug: References in general, at least using 1.0.0.15, don't seem to need the ONAM's whatsoever. We'll get to the bottom of it. I'd experiment with 1.5 but it wouldn't let me play, so I reverted, again. >__<
User avatar
Avril Louise
 
Posts: 3408
Joined: Thu Jun 15, 2006 10:37 pm

Post » Sat Aug 22, 2009 8:37 am

Hmmm... Maybe it's just NAV meshes? :shrug: References in general, at least using 1.0.0.15, don't seem to need the ONAM's whatsoever. We'll get to the bottom of it. I'd experiment with 1.5 but it wouldn't let me play, so I reverted, again. >__<


How does one set these onam thingies? Is it an FOEdit thing?
User avatar
Rhysa Hughes
 
Posts: 3438
Joined: Thu Nov 23, 2006 3:00 pm

Post » Sat Aug 22, 2009 6:12 am

Yep. And if navmeshes don't override as they should, what else doesn't override as it should?. Afaik esms have been plagued by this since they exist.


Correct me if i'm wrong, but the only changes i know of that the pitt and anchorage do to vanilla stuff are changes on base forms.

and mods that edit existing non-persistent content should make the edited items persistent.

Dont, you'll just bloat savegames.
User avatar
Cagla Cali
 
Posts: 3431
Joined: Tue Apr 10, 2007 8:36 am

Post » Sat Aug 22, 2009 1:01 am

I was going to post something useful, but it turned out to be unuseful... as the new patch, I only hope beth is REALLY working to fix the bugs from the bugs from their patches, HA! patches... thats funny.
User avatar
kirsty williams
 
Posts: 3509
Joined: Sun Oct 08, 2006 5:56 am

Post » Sat Aug 22, 2009 7:09 am

Hmmm... Maybe it's just NAV meshes? :shrug: References in general, at least using 1.0.0.15, don't seem to need the ONAM's whatsoever. We'll get to the bottom of it. I'd experiment with 1.5 but it wouldn't let me play, so I reverted, again. >__<

Yeah as far as I see any modified cell reference in Fallout3.esm needs an ONAM override in your ESM or your changes won't appear (new placed objects don't need ONAM overrides), UF3P v1.1.0 was an ESM till I saw this issue and quickly went back to a esp and uploaded v1.1.1.

I'd like to make UF3P an esm again but there needs to be a way to automatically generate all the ONAM's, doing 1000+ ONAM's by hand = head explode :banghead:
User avatar
Marie Maillos
 
Posts: 3403
Joined: Wed Mar 21, 2007 4:39 pm

Post » Fri Aug 21, 2009 8:57 pm

Wow, guys...

I took my hugest version of my military base - - the one with about 1960 triangles (not real optimized though) and imported it into an .esm, and linked it to the world. When this was in an .esp, I'd get pathfinding failure upon setting foot through the door the second time.

With it newly loaded into an .esm and linked to the uhhhhh a door stuffed alongside of the super duper mart, I went in and out of the cell repeatedly, and there was no pathfinding failure. Testbed of 8 followers. This sort of thing positively makes the .esp version [censored] itself.

Time will tell, but atm this looks like the core of the issue I've been chasing for some weeks now.

I think that navmesh in .esp files does something strange and, after the player is exposed to the added navmesh, some condition begins to accumulate in the game. And eventually the .esp's navmesh stops being seen by the game.

In 1.5, I think it applies to both interior and exterior cells. I am not sure if it applies to exterior cells in 1.4, it may not, I first noticed my larger campsite (an .esp navmesh change) doing it after I patched.
User avatar
Kim Bradley
 
Posts: 3427
Joined: Sat Aug 18, 2007 6:00 am

Post » Sat Aug 22, 2009 1:11 am

Dont, you'll just bloat savegames.

Presumably the bloat will only be significant if large numbers of references are edited and made persistent. If base objects are edited there isn't an issue, and if only a half-dozen references are made persistent the 'bloat' will be unnoticeable.

So the mod author has to judge it on a case by case basis.

Is that right?
User avatar
Patrick Gordon
 
Posts: 3366
Joined: Thu May 31, 2007 5:38 am

Post » Sat Aug 22, 2009 8:54 am

What I know for sure is this.

As a test, I dumped my entire mainfollowermodule, which contains navmesh replacements for a few exterior cells, into an .esm. I found that my followers were obeying fallout3.esm's navmesh, not mine. Quarn said ONAM thingies were needed in my .esm version for them to use my navmesh instead.
Hmmm... Maybe it's just NAV meshes? :shrug: References in general, at least using 1.0.0.15, don't seem to need the ONAM's whatsoever. We'll get to the bottom of it. I'd experiment with 1.5 but it wouldn't let me play, so I reverted, again. >__<
User avatar
Spencey!
 
Posts: 3221
Joined: Thu Aug 17, 2006 12:18 am

Post » Sat Aug 22, 2009 12:50 am

BUT it's safe to assume that it probably is, as nothing but the achievements seems to be related to broken steel.
Actually, the new patch also introduced a new function which is presumably used in Broken Steel to change the water in the DC basin
Spoiler
after the purifier has been activated.
- http://www.gamesas.com/bgsforums/index.php?showtopic=963756&st=160&p=14226426&#entry14226426

I don't know what this will mean once the DLC is released, but I suppose we'll all find out soon enough.

Cipscis
User avatar
Jack Walker
 
Posts: 3457
Joined: Wed Jun 06, 2007 6:25 pm

Post » Fri Aug 21, 2009 11:23 pm

Has there been any info on the update to the update? I ask because I would rather not use the Fake patch I get nervous with stuff like that.
User avatar
Rich O'Brien
 
Posts: 3381
Joined: Thu Jun 14, 2007 3:53 am

Post » Sat Aug 22, 2009 1:55 am

You needn't be nervous about using Fake Patch. It doesn't alter Fallout3.exe in any way, but instead incorporates the edits to Fallout3.esm that would normally be made by the patches. In short, it fixes Fallout 3 in the same ways as the patches, except it doesn't make any changes to the actual game engine so none of the bugs introduced by the patches will be introduced to your game.

That said, no one's going to force you to use it, of course.

Cipscis
User avatar
Isabel Ruiz
 
Posts: 3447
Joined: Sat Nov 04, 2006 4:39 am

Post » Fri Aug 21, 2009 9:31 pm

[quote name='maran' date='May 4 2009, 05:03 PM' post='14260416']
From a modding perspective, there are major bugs in the new patch, this thread is intended to raise awareness of them and find solutions.

Continued from the previous thread:

The following was a recent crash, "cross thread deadlock" now the game just keeps craching. It is very hard to enjoy a game witth continuous errors like the following report:

Source: Application Hang
Date: 5/4/2009 7:55:25 PM
Event ID: 1002
Task Category: (101)
Level: Error
Description:
The program Fallout3.exe version 1.5.0.22 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Problem Reports and Solutions control panel. Process ID: b08 Start Time: 01c9cd1386812a72 Termination Time: 105

Fallout3.exe
1.5.0.22
b08
01c9cd1386812a72
105
430072006F00730073002D00740068007200650061006400000044006500610064006C006F006300
6B0000000000


Binary data:


In Words

0000: 00720043 0073006F 002D0073 00680074
0008: 00650072 00640061 00440000 00610065
0010: 006C0064 0063006F 0000006B 0000


In Bytes

0000: 43 00 72 00 6F 00 73 00 C.r.o.s.
0008: 73 00 2D 00 74 00 68 00 s.-.t.h.
0010: 72 00 65 00 61 00 64 00 r.e.a.d.
0018: 00 00 44 00 65 00 61 00 ..D.e.a.
0020: 64 00 6C 00 6F 00 63 00 d.l.o.c.
0028: 6B 00 00 00 00 00 k.....
User avatar
Sanctum
 
Posts: 3524
Joined: Sun Aug 20, 2006 8:29 am

Post » Sat Aug 22, 2009 12:16 am

Presumably the bloat will only be significant if large numbers of references are edited and made persistent. If base objects are edited there isn't an issue, and if only a half-dozen references are made persistent the 'bloat' will be unnoticeable.

So the mod author has to judge it on a case by case basis.

Is that right?

Don't bother trying to make your mod "compatible" with v1.5, waste of time (more so if Bethesda actually fixes it). Persistant references are also a drain on resources since they are stored in memory all the time.
User avatar
naana
 
Posts: 3362
Joined: Fri Dec 08, 2006 2:00 pm

Post » Fri Aug 21, 2009 11:12 pm

Don't bother trying to make your mod "compatiable" with v1.5, waste of time (more so if Bethesda actually fixes it). Persistant references are also a drain on resources since they are stored in memory all the time.


Hopefully at least a percentage of people will take this attitude, otherwise we will be left with countless mods which no longer work.

It is sad that I cannot release a version for the official 1.5 but I have little doubt when some ingenious modder gets to patching, we will have its functionality without the official version, so hopefully there will be no need for it anyway.


A note from: http://cs.elderscrolls.com/constwiki/index.php/Esp_vs._Esm

When one esm modifies in any way a worldspace cell of another esm, the land bug occurs in gameplay. The land bug is where the local land textures (and often static buildings, etc.) disappear in gameplay. This happens not just in a few isolated spots, but typically everywhere.


Is this fact or fiction? I had always heard there were occasionally problems with using too many ESMs but in a brief search I couldn't find any definite quotes but this one.
I think 50 ESMs rather than 50 ESPs will certainly strain a few variables we haven't pushed before.
User avatar
Britney Lopez
 
Posts: 3469
Joined: Fri Feb 09, 2007 5:22 pm

Post » Sat Aug 22, 2009 8:23 am

I was talking with eliminster a moment ago, and he verified something that is an important point.

It would appear that if this new change is going to stay, we should put our levels as .esm files. It's impractical and odd to have to mass-create persistant references for, say, a large outdoor area, and it seems that .esm is the natural thing for this, now.

However, the GECK does not actually allow you to create and edit .esm files. To make .esm files you create an .esp in the GECK, then convert it to an .esm using, like, FO3edit. Then, to edit it again, you convert it back to an .esp. The GECK can't even load an .esm as an active file, I don't think. It didn't work when I tried.

So, what's the official story on this exactly?

This whole thing makes the GECK level editing tutorials um, wrong. Shouldn't they add the ability to edit with .esm files to the GECK? They would sorta need to add the esp/esm conversion process FO3Edit to their tutorials otherwise.

Also, navmesh doesn't work properly in .esp files. That's clear to me now. And items in exterior cells have to all be marked persistant, which also isn't part of the tutorials.
User avatar
Stephy Beck
 
Posts: 3492
Joined: Mon Apr 16, 2007 12:33 pm

Post » Sat Aug 22, 2009 12:13 am

It would appear that if this new change is going to stay


We cannot jump to that conclusion after such a short period of time, lets wait for some word either way.

So, what's the official story on this exactly?

This whole thing makes the GECK level editing tutorials um, wrong. Shouldn't they add the ability to edit with .esm files to the GECK? They would sorta need to add the esp/esm conversion process FO3Edit to their tutorials otherwise.


I don't think this was an intended change, if it was its a pretty badly thought out one, hence the tutorials still reflect the intended way of doing things and the Geck doesn't need to be altered.
User avatar
Causon-Chambers
 
Posts: 3503
Joined: Sun Oct 15, 2006 11:47 pm

Post » Sat Aug 22, 2009 5:25 am

Actually, the new patch also introduced a new function which is presumably used in Broken Steel to change the water in the DC basin
Spoiler
after the purifier has been activated.
- http://www.gamesas.com/bgsforums/index.php?showtopic=963756&st=160&p=14226426&#entry14226426

I don't know what this will mean once the DLC is released, but I suppose we'll all find out soon enough.

Cipscis


Well then I guess I won't be getting Broken Steel then because I refuse to submit to game-crippling bugs. I'm starting to get bored of FO3 anyway...

F you too, Bethesda.

Seriously... Why should I buy your games if you continually give the PC community the shaft? The fact that we get the GECK is irrelevant to the fact that the core game is shoddy.
User avatar
steve brewin
 
Posts: 3411
Joined: Thu Jun 21, 2007 7:17 am

PreviousNext

Return to Fallout 3