Community,

We are now just over the horizon on New Vegas and our little team has been working on the next version of Fo3Edit for the upcoming release of New Vegas. Elminster has been working at it for months actually, porting Fo3Edit into a newer environment/code base and have alot of us do testing. At this point I've tested the new Fo3Edit on Fallout 3 and Oblivion and it worked very well, very fast (same engine works for Fallout3 and Oblivion just by renaming the binary).

JustinOther and I are both hard at work the next big tutorial update, with JustinOther already contributing some Really big ideas on how the next tutorial will be a level-of-magnitude better and more instructive than the Fo3 version. We'll be adding about 30% more tutorial content over the last revision plus an entirely new feature that has me very excited; labs! In addition to have the tutorial as a guide, we'll be offering a set of labs that users can go through to learn some of the more complex tasks that we do in Fo3Edit by actually Doing them on lab plug-ins that we ship with the tutorial. Can't say how many we'll get done in the first release, probably a good sampling so we can get feedback. If there are any labs that You think would be adventagous or that you would like to see done first, that will help focus our time.

At this point we would like to hear from the community regarding the kinds of things you think are missing or could be done better in Fo3Edit. I'm not promising anything of course for delivery of new features as they must first be reviewed by Elminster and approved. But if there are 2 or 3 critical things missing from the tool that could be done better, then I'm confident that we can get them on Elminster's plate (pending his workload of course!). In my experience the best way to get new features added to any tool is to be detailed but concise and to get them in early. We may not see new features for months or even a year, or we may see some new features much sooner, and our best-bet is to get the requirements and suggestions in now.

With that said, if you have a few things that you would like Fo3Edit to do or think it could do better, by all means let us know!

Thanks and cheers,

Miax

wow.. yay.., woot, er.., I, I.., I.., wow. :celebration:

:goodjob:

:)

Only things I miss off-hand, personally, would be: Being able to use a reference in record to jump directly to the record for that reference. By which I mean when I'm looking at a object and it has a script on it, it would be nice to be able to right-click the script entry and have an option to jump directly to that script record.

Also, the "Use Info" function in the GECK is very handy for finding things by providing a list of all uses of an object and allowing you to jump directly to where it is being used. If something similar could be implemented in FO3Edit I wouldn't have to open the GECK nearly as often as I do.

Either or both of those could be ridiculous requests, of course.

Good to know we're getting such an essential tool right off the bat.

I've run into a few problems where removing unused parents from a mod in the GECK can sometimes screw over all the referencing records- everything that used to be referencing 04xxxxxx stays referencing it when you remove say the 02 master and the 04 is now 03. I've fixed it by going through FO3Edit and manually changing all the indexes, but that's a bit of a faff. The ability to select an entire mod and go "Reindex all references to XX to YY" would really help with that.

I've also run into problems with splitting mods up into a master and a dependent on it, and the indexes being wrong. The ability to select a bunch of records and just change their index, rather than renumbering them to fit into another mod, would be great.

You can already, hold down Ctrl and click on it Then, use the blue arrows at the top to return. You can follow a chain of references this way.


That's also already there -- there's a 'Referenced By' tab at the bottom while you have a record selected that's referenced by another. You can then jump to any reference in the list by Ctrl-clicking on it as above. By default, this tracks references within the .esp you're loading itself. To build references across multiple files right in the left pane (anywhere) and select 'Build Reference Info', and this will build a list of references across other loaded plugins or masters (for example, Fallout3.esm to your .esp that's loaded, if there are any).

See, that's why I like threads like this...they reveal my ignorance. Thank you.

So.....it also bothers me that the column widths reset every time you switch from one reference to another. Did I miss a way to make them stick as well?

The way the columns are expanded and contracted always struck me as weird anyway. In order to shrink the "Form ID" column (left pane) I have to grab the right edge of the "Editor ID" column and manipulate that. Grabbing the right edge of the "Name" column also shrinks the "Form ID" column while leaving the "Editor ID" column in the middle the same size.

Right hand pane behaves more naturally, except that the last column is annoyingly hard to expand. You have to grab the column edge from the "inside" edge, not the "outside" edge (left of the line itself, not right of it) in order to make it expand.

Remove the drop-down selection menu when entering a ref into a subrecord. I have had to wait minutes for FO3Edit to load one if I accidentally open the drop-down menu when creating a new entry in a FormList, since all form objects are eligible for entry into it. Or at least disable them just for FormLists.

Make an option to remove the nag screen every time I alter something. I get it, you can FUBAR things with it if you don't know what you're doing. I do know what I'm doing.

Put the backups in theit own subfolder. The data folder is heavily cluttered as it is (or 'will become heavily cluttered' in FONV's case).

Great feedback so far, thank you all!

After a few days I'll summarize all of the recommendations into a single message and forward that to Elminster for review. Some of these make absolute sense.

Thanks and keep it coming!

Cheers,

Miax

Is LOD object generation amongst the things to be implemented in the revamp? IIRC that was an Oblivion only feature.

"LOD gen : FO3Edit :: Snowball : Hell" (Elminster)

Given New Vegas is bound to be more like FO3 than Oblivion, I'd bet 10 internets that neither FO3Edit nor FNVEdit (?) will ever get LOD gen. I'd love to be wrong...

It mentions above that they ported it to a new codebase, and that the same program works for FO3 and for Oblivion (with renaming the file). If they kept all the Oblivion features, it might mean that FO3 and FNV both get LOD Gen now. Or it might mean that Oblivion loses it.

edit: Oops, didn't notice you were involved in the testing/tutorial for this.

No actually LOD gen for Oblivion was done another way, an easier way as I understand it. I agree with JustinOther that there is almost no chance we will see LOD in Fo3Edit or any other program, the GECK/engine changed the way its generated significantly. Its unfortunate too, as LOD generation is currently one of our big Fallout 3 modding pains (that and Lip Sync are my tops).

As it stands, Elminster has ported the code into the most recent release of the Delphi engine that he developed it on. It's not a different code base, its bringing TES/Fo3Edit up to the latest releases of its CS. Later on this will pay big dividends when he needs to change stuff and add new features. The new version is nearly identical to the old, though I've found a few small differences that I reported to him.

If you take Fo3Edit and rename it to TESEdit then slap it into the Oblivion directory, it will "become" TESEdit. Its an awesome feature really, one code base that supports all 3 games.

Oh, does the 'select by directory' thing mean it uses whatever install it's in the directory of? I've currently got two FO3 installs, one non-Steam modding install, one Steam playing install. Wherever I put the FO3edit exe it always uses the Steam path (whatever mod list I edited last), which is a tad inconvenient.

Will there be backward compatibility for Oblivion?

One issue that is coming up for Oblivion was kind of necessitated by the release of the total conversion called http://www.gamesas.com/index.php?/topic/1118493-release-nehrim-at-fates-edge-english-version/ which in turn has prompted many to want to mod Nehrim and some of the difficulties about that I outlined here in the http://www.gamesas.com/index.php?/topic/1118767-nehrim-and-mods/.

Out of this discussion there are plans to have Wrye Bash be able to be installed multiple times in new game directories and Gaticus has made a program http://www.gamesas.com/index.php?/topic/1119357-wipz-mtes4-manager/ that will clone your install and allow you to swap between installs (and save game folder, app data for plugins.txt, ini and all that) and and therefore have more than one install of Oblivion that you can swap between. With these two improvements - having mutliple installs on one hard drive is now within reach and Gaticus says that it is likely portable to Fallout 3 for the same thing.

Particularly with regard to TES4edit it seems that it is not multiple install friendly and was wondering if that were possible and/or at least be able change the directory it scans for plugins.

Actually this is something I'd like to see kept as it's pretty handy. If it were made more intelligent so it doesn't try and load everything into it that would be awesome, but removing it would svck.

Is anyone else unable to get FaceGen code to work right? Whenever I copy-paste a FaceGen hex string in FO3Edit, or from FaceGen Exchanger into FO3Edit, the game invariably crashes if I load that face, either on an NPC or in Gene Projector/Plastic Surgery.

I'd either like to have that bug fixed or find out why I can't get it to work without crashing.

I played around with the copy-paste of the hex-code string and found that it copies all of the data, but when you paste it, only about half of it gets pasted. I would think that would be an easy fix. If you paste it into notepad, it's all there.

How about skipping the bsa loads. It takes too long (especially with DLCs) and they aren't used by FO3Edit anyway.

Yes, actually I'd like it if the BSAs were all skipped as there are no graphical functions that need them to be loaded. It might shave some load time off, though admittedly for me it wouldn't shave off much.

Also, I'd really love it if the record flags in an entry could be changed with the "copy to selected records" function. Currently an exception error is generated if, say, I try to mass-copy an initially disabled flag to multiple records doing that. It's something I've reported before but never got an answer on.

I'd like to be able to open up two instances of FO3Edit, and drag things from one instance to another. For example, when working on Imp's More Complex Needs, every food item needs a calorie, protein, hydration, and nutrient effect, with an ID==Player conditional. I'd like to be able to set that up for 1 food, and then just drag it en masse over to different foods displayed in the other instance. Something similar for perk entries would also be good.

So that, and if possible, a compiler so that I can edit scripts without opening the GECK.

This, though I know it's a lot of work. Still, that would be my number one request.

@Alystin & Arthmoor; Actually the BSA loads are critical to many of Fo3Edit's functions, especially when it comes to conflict resolution and error checking. Granted there are indeed functions that could be run without the object database loaded, I will inquire with Elminster about the possibility.

@Imp & Martigen; I agree whole heartedly on the script compiler. It is technically possible to do today If we could replace carriage returns with the Control charcter (looks like a box), but I have never found a way to do this successfully. Right now all we can do is view the script.

@Madcat221 & RickerHK; I'll ask about the FaceGen data, thanks for pointing out that only half of it gets pasted - this may help.

@TalkieToaster; I'll find out about the default directory / path setting - It would be great if it ran out of the directory it's installed into.

Thanks for all the great feedback. JustinOther's ideas on using Labs with the tutorial (for all 3 games, TES4, Fo3, FNV) are fantastic, and we're expanding upon it - I think this will be the biggest addition. I'm tossing around the idea of breaking the tutorial into 2; a Basic and an Advanced version as right now it's 150 pages and will get much larger with the new content. This I think is unwieldy (even in PDF), and it may make sense to carve it up more with smaller fonts in the Advanced tutorial to support the greater level of textural description needed, and separating functions between the two. I've got the full version of Fraps with the the DivX and Corel video studios setup so I can also make video tutorials of the most common tasks for linking up to YouTube.

All ideas and feedback are most appreciated,

Miax

A couple more thoughts. About "undelete and disable references", moving the Z axis to -30000 has created problems for people in the past (probably due to the base land height being at 10500 for FO3 vs 0 for oblivion). Second, could we get a expand tree option. There are times I've wanted to expand the entire wasteland worldspace from a mod all the way down to all its references and had to do it entry by entry.

Can't this already be done by hitting '*' on the keyboard when the top-level entry is selected?

As for me, a feature I would like to see is an "uninject record" item in the context menu when r-clicking on injected records. The function would change the formid to an available formid in the current plugin and update references to the new formid. This would help with fixing some mods that have accidentally injected records into their masters.

@Miax: what is the issue with carriage returns? I assume this is something more than just a character translation for 0x0A and 0x0D?

While I think of it -- one bug I'd like to see fixed is this: when you Deep Copy as Override... into a new plugin, Base Effects aren't copied properly and lose their references. There's no warning of this failure, you only find out when you play your mod and wonder why certain effects aren't working anymore.

I did raise this with Elminster a while ago, but from memory he said it would be hard to fix and it went above my head when he was explaining why. Still, if it _can_ be fixed at some stage it would be nice, but alternatively add a warning when copying Base Effects. I'm aware of it so work around it, but for modders who aren't it could save them hours of hair-pulling debugging.