I have very little experience with modding Beth games or any others, though I have the training and the desire. Being in school full-time working on programming coursework . . . this spring is perfect timing for me to be able to treat modding like a "part-time job" and build up my portfolio.

I've heard it said from long-time forum regulars whose opinions I trust and respect, that it is a "bad idea" to either make mods without the GECK or to use those mods (unless you understand that, a patch or update might completely break it). I do not question that though I do not fully understand why it is the case.

I've played the game up to Level 78 and realized: it gets far too easy on Normal. If there was a "Fallout Wanderer's Edition" for FO4 already available, I'd download that, and play it, and it would likely be to my ideal. But since there isn't, my natural inclination is to want to start making such a thing myself.

And then I see all these mods that are already out and getting reviewed on Youtube . . . yes most of them are obviously overblown cut-and-paste or three-character-edit jobs, but some of them seem to be pretty involved. For example, CBBE Body Replacer is already out!?

So, can you guys who know what you are doing please help me by answering some questions and offering some suggestions?

1. Is it or is it not a bad idea to start making mods right now?

2. Assuming it is best to wait for the GECK, what would be the long-term problems of making and using mods right now that are "pre-GECK?"

3. Would it be a good use of my time to get familiar with the CK for Skyrim or GECK for FONV?

4. Two specific mods I have a strong interest in making:

A. A "Autonomous Settlment Defense" mod in which settlement attacks happen (and playthrough using the same dynamics as if you were there) even when the player is not in range of the cells. Is this even possible? What past mods might I look at to get a sense for how this might work in FO4? I'd think that Skyrim Immersive Patrols and/or Tundra Defense might be the closest thing to this functionality?

B. A "Difficulty Overhaul" along the lines of Fallout Wanderer's Edition, would love to hook up with these guys and help out as much as I can if they are still active.

I've been using texture mods almost since the game released. With CBBE and other more advanced mods, I've ~started~ migrating to them, but many of them were created with primitive tools and / or lack of understanding of the new game systems and cause more problems than they solve.

The main thing the GECK would bring, I think, is scripting control. People have made textures and some meshes and altered the code that is tied to items or even world cells (with resulting Cell Reset problems) but I haven't seen much beyond that, yet. When the proper tools come out, some of these mods may be tweaked / improved, but I imagine many will simply be replaced.

This generally refers to plugin (Esp or Esm) files made with a tool called tesVsnip, as it was made for Skyrim before the record structure was fully understood. Mods made with this tool flooded out into the world before Skyrim's CK was out, and then we found out they caused save corruptions. A lot of people's saves were destroyed because of this. Thus, the general advice is to NOT use plugin based mods right now because the only completely safe way to make a plugin (for now) is with the official GECK.

That said, mods that do not use a plugin are completely unrelated to this concern. E.g. a mod that is purely texture files is 100% fine to use as it cannot break your save. At worst it breaks your graphics, and you can just uninstall it with no penalty or problems to your save.

Yes, it would absolutely be a good use of your time to at least do some reading up on the CK for Skyrim (http://www.creationkit.com/Main_Page), but not the GECK for Fallout 3. There was a big change in engine, both in quest building and especially scripting, between Fallout-3 and Skyrim, but as far as anyone can tell a much smaller change between Skyrim and Fallout-4.

Fallout 4 edit is out though, and there have been no reported issues I have seen with using mods made with it. I personally use quite a few, and have no issues with my game, or my saves. (beyond the usual for a newly-released beth game.)

However, some words of caution on the FO4Edit page on Fallout 4 Nexus are worth bearing in mind...

I'm not trying to sell FO4Edit short, it's an amazing achievement in so short a time, created by some very knowledgeable people with a wealth of experience. And it is the best tool available so far. But it is based on an incomplete understanding of the FO4 plugin file structure, and should be used carefully by people who know what they are doing.

So, to the original poster, by all means use FO4Edit to create plugins, but be aware that any gaps in your knowledge may lead you to create mods that will corrupt users' savegames - so a lot of reading and asking questions would be time well spent

FO4Edit is better than the GECK for a lot of applications. However, it's dependent on having the fields decoded and systems understood. We still don't know how a lot of the systems work, so we can't edit them and we won't know until the GECK comes out.

There's some things it *can't* do, like placing references in the world (causes bugs) and scripting. Some things are horribly awkward to do in it, like dialogue, quests and AI packages.

Whilst the GECK isn't exactly accessible, it at least makes the relations between the various forms more obvious and importantly stops you don't things that don't work. FO4Edit doesn't know what does/doesn't work, so starting modding now without a solid idea of what is and isn't possible from previous versions of the engine isn't a good idea. [i]I've[i] spent most of my time modding on things that don't work and I've mostly been trying to replicate stuff I've made in previous versions of the engine.

1) it's a good idea, tbh. Even though FO4Edit is somewhat limited, it still has a large number of records decoded. Get yourself familiar with where / how / what kind of information is stashed in these records and not done with scripting. You'd be surprised. For example, who knew that water generators had a 25% chance of not giving you anything during a production cycle? And who knew you could change that with a pretty simple record edit? FO4Edit knew.

2) potential long-term problems are pretty much the same now, pre-GECK, as they will be later, post-GECK: the tools you're using to make the mods might have bugs. And you can expect roughly the same chance of Bad Things (really pretty small, but never zero chance), and the same magnitude of Bad Things (worse case: lose save forever).

3) I doubt anyone can say for sure. Most likely, FO4CK will have a very similar UI. But, frankly, it's like any other IDE. There's a difference between learning the IDE and learning the system you're going to be messing with.

4a) I doubt it would playthrough with the same dynamics - if you're talking about things like silly BethPhysics™ grenade bounces, and pathing bugs leading to lucky (or unlucky) breaks, that's probably not going to work. But you can simulate results with scripting. Does it sound unglamorous? It shouldn't. How good those simulations are (and what ramifications they have) will be up to you.

4b) there are already difficulty overhauls being made using stuff we can see with FO4Edit. Ranging from level caps, AI packages, health and damage scaling, respawn times, etc... As mentioned earlier, you can pop open some of these mods in FO4Edit and see what's available to tweak now. You'll want to tweak the same things later, too, so why not look at and understand the systems now?

Subscribe to TES5Edit on Github. The developer traffic is fascinating, both for what they know and what they don't know.

It is like watching forensic pathologists at work.

Once they have the GECK, they can introduce a change and see how it is reflected in the binary.

That will speed things up considerably, and in some cases - make the impossible easy.

FO4Edit in itself is probably safe to use as long as you play it safe and follow the patterns that already exist in the Fallout4.esm, but anything that's not yet clear is probably best avoided for now. The Creation Kit generally has a smoother workflow and is more "idiot-proof" than FO4Edit. And while your programming knowledge will help you figure out FO4Edit, it'll be much more useful when you get your hands on the Creation Kit.

There's a lot that can be done in mods now, but most of it is still pretty basic. Graphics replacers, editing existing records, and adding new records based off of existing records is possible (and most of that is the stuff you're talking about), although some things are a lot more tedious and a lot less intuitive with FO4Edit than they'd be with the Creation Kit. Adding new quest content or new game mechanics with scripting is probably out of the question, though.

A Wanderer's Edition style overhaul would require a lot of things: adjustments to the level scaling, and stats on items and actors, is all possible in FO4Edit (and arguably easier depending on your workflow and what you're trying to do). But changes to the level design, new areas, tweaks to the AI, or things that necessitate scripts like new game mechanics (realistic needs, new abilities) are probably beyond FO4Edit.

On autonomous settlement defense: I don't think it's possible for the fight to play out unless the area's actually loaded (and I don't know if you can load a cell not around the player, or if that's even a good idea), but with scripts you could probably set it up to check the settlement's stats against the attacking party and auto-resolve it there after the objective's time limit expires. You could possibly even do advanced stuff, like lowering the settlement's happiness, removing settlers that "died" defending the place, or damaging a certain amount of placed items. Maybe even depleting raw resources and produced goods from the Workshop containers. But again, this would all require scripting and a little quest editing.

Ah, thanks a lot guys! Some great responses here. I see I have at my disposal some materials to get me going and which can seamlessly carry over into working with the GECK!

Cheers!

Re: the issue of "Autonomous Settlement Defense" a lot of us find the "return to defend" settlement functionality less than ideal. I was thinking in terms of "calculating" a few variables (firepower, accuracy, damage resistance, etc.) for the settlement and its attackers and implementing an "auto-resolve" sort of thing like you guys are referring to. But I was puzzled by a paradox that the settlement building presents.

A star-shaped fort, with turrets or guard towers at the points which affords excellent fields of fire will provide better defense (in real life) than a ramshackle assortment of walls and weapons that leaves large gaps in fields of fire.

During engagements the AI seems to get this to some degree, and certainly many of the level designers have made scenes in the game that reflect this principle to varying degrees, though granted this in general is defense against the player.

To put it succinctly, 20 settlers all equally armed and armored, plus 20 turrets is (or would be in real life) only "part" of the equation for calculating the defensive value of a fort or settlement. It seems difficult to account for the value of the overall structure of walls, placement of weaponry and guard towers, etc. in a way that would be easily turned into a simple Defense vs. Attack probability calculation.

Paric suggested that, the game already has the capacity to 'simulate' the value of such defensive structures, but they only come into play when the player is in the cell and the settlers and attackers engage in actual combat. So he basically suggested "make the attack happen and play through as if the player were there watching it happen, even when the player was not there."

One major caveat: as it is, neither defenders or attackers seem to "acknowledge" walls. I've seen ghouls charging at settlers despite their being a wall separating them and settlers standing on the other side of the wall shooting at them. Whether the shots actually penetrate the wall (or some of them) I am not sure, but it would seem that a first step to making player built settlment defenses work properly would be to make all the NPCs recognize that they cannot walk through nor shoot through walls and thus to either assault walls (scale them, sap them, blow them up, yes I know not happening in current form) or to find a gate and go through it.

Assuming the above was possible to do (make actors behave 'normally' with respect to combat around walls) then it would seem the ideal solution might be: the game calculates that an attack is going to take place at a settlement (assuming the player is not at the location for the sake of this example), the settlers at the location either do or do not detect the attack initially, once it is detected, the player (maybe, depending on communications abilities?) gets radio warning, and then a brief delay (attackers might have to reposition or maybe they were detected well in advance) and then *bam* the attack on the settlement "plays out" just as if the player were in range of the cells where it happens, but even when the player is all the way on the other side of the map. In sum, the game gets to "load" a cell and playthrough a combat between NPCs (and with all the landscape features taken into account as they are in any 'normal' combat) takes place and resolves.

If the fort was well-designed, well-armed and the settlers were well armed and armored then the resolution should tend to be better than if there were not walls to funnel enemy traffic and/or poorly placed turrets, poorly armed settlers etc.

Of course, as it is, enemies can spawn INSIDE walls, so that would have to be 'fixed,' but presumably that would be doable.

What do you guys think, would it be possible to load a set of cells and play out a complex combat even if the player were not in range of those cells? I know it might be disastrous and cause CTDs or lots of other problems, but it sure would be cool if it could be done.

If you're talking about actually making the fight visible and watchable, you'll have quite a few problems with the time of day advancing and triggering all kinds of events. Firefights between randos in the outskirts of Diamond City often take hours to resolve. A raid could take days. What's your character doing during that time? If you want to rewind time after the fact, you'll have to reset quests, stop any radiant activity, it's a lot of stuff you have to keep track of.

If you're talking about not actually making the fight visible, but sim-loading the cell and still getting geography info, my guess is you'll basically have to do one of two things:

1) Rewrite all the physics, pathing, and AI so that it isn't dependent on the geometry actually being rendered (essentially: rewrite the game engine, minus like shaders and lighting maybe)

2) Fake-load the cell out of view, kill all the lights, sounds, and other effects of combat (like mininuke whiteflashes), and also detect if the PC is walking into view of the combat cell (which might start happening halfway through the fight), and shift the cell location back to its original location without triggering BethPhysics™

All that work, and the end result will likely be something like: one out of every ten raids, two extra Settlers survive.

I'm kind of making fun of you. I'm sure it's technically possible, but not for one person and not in one year. It's definitely not going to be worth the effort. You'll almost never notice the difference between that and a well-done script that abstracts away the geometry and physics down to a handful of head-to-head numbers, and it won't have any in-game effects. It'll just be a tree falling in the woods, something you "know" happened, even though you never saw it and it had no ramifications.

TL;DR: modding and programming in general is a lot more work than you may think, and you want to make sure you pick projects that give returns that are worth it.

I'm almost 100% certain that this is impossible. The way NPC AI runs at lower levels of fidelity at greater ranges is hardcoded into the game engine.

One way round this might be to have a pop-up which lets the player know a settlement is being attacked and give them the option of 'Defend or Auto-Resolve'. If they choose auto resolve then all NPCs in the cell they're in get their AI disabled, the player is warped to the settlement with the screen faded black (and the player ghosted so undetectable and invulnerable), the timescale gets ramped up to complete the fight quickly, then the player gets warped back where they were.

Basically a horrid cludge

Some good responses thanks guys! I'm glad I asked because it sounds like it would be a hellacious amount of work and not a good idea for a "first mod!"

ADDIT: actually another question though . . . I understand that something called "navmeshing" is used to guide movement of actors across the terrain?

When you think about the benefit of a fort, what it boils down to is: it restricts enemy movement while exposing them to fire. One simple abstraction of this could be something like "how many paths" are there to get to the "center" of a settlement? The Workbench would be the most obvious 'center' and presumably when you place obstructions something is being stored that represents blocked navmeshes?

I cannot quite imagine what the equation would look like (I don't know what a navmesh is exactly), but maybe there would be a way to numerically represent the bottlenecking that results from a gate?

Navmesh has nothing to do with what you're describing, it is an invisible grid or pathway that NPCs can see but the player never can that tells an NPC what is or is not a valid pathway to walk in or through, say if there is something in the way blocking the path the NPC wants to take like a wall or a rock for example. Without Navmesh correctly placed in every cell in the entire game, all NPCs would not "see" such obstructions and would instead try to walk through it (or off it if there is a height difference involved such as a building or cliff edge) so they'll get stuck or walk in place or stand there confused. This is all very simplified of course, you can read more about it here:

http://www.creationkit.com/Bethesda_Tutorial_Navmesh

That tutorial was obviously intended for Skyrim's Creation Kit but the GECK for Fallout 4 will no doubt function somewhat similarly so you can get a basic understanding of the concept.

I am wondering how the navmesh actually works in FO4. Building settlement walls and buildings, ladders and bridges, how exactly is the navmesh as we know it from Skyrim working here? It does not seem possible that its the same.

Statics can have navmesh information embedded directly on them. So the hope is that the CK will have some kind of method for applying it to your own navmeshes. Settlement meshes also need snap points for alignment with other pieces but it's not clear from FO4Edit whether or not that data is in the records or if it's part of the meshes themselves.

1. That's is completely dependend on your own opinion. For me it's ok because I know at one point I'm going to drop my character anyways. Playing with it since roughly 50 hours in a somewhat heavily modded game, and there are occassional bugs, both, vanilla made and mod made. However, I would not recommend using mods now when planning a longtime character that is never going to be dropped.

2. Wrong Id's, conflicting forms, potential unstabillity in general.

3. It would.

4. Two specific mods I have a strong interest in making:

A. No need for a mod, this already happens in game.

B. Prepar for a long time project in which community will tell you how to make the mod, if you're aiming for success. Balancing a personal overhaul is a long time project just as well...you need to have a fundamental understanding of the game mechanics to get the balance for an overhaul done.

just because fo4edit is out does not mean everything is A-OK. people have this false impression that just because something is made with fo4edit that it is somehow immune to bugs or inherently safe. this simply is not true. Yes, it is immune to the save corruption that is caused via Snip, but thats all.

Ill reiterate some stuff i said over at the nexus a few weeks back.

The way that modding currently stands now, I would be hesitant of any mod that adds new items into the gameworld (placed objects). Also, any mod that is very complex, adds new systems, overhauls, etc. I would be cautious of, for now. Everything is still very new. Even experienced modders may not know exactly how the fo4 records are structured yet. Looking at a particular record type, we have to learn what type of subrecords it contains, how are they structured, what other records are being referenced (i.e. how does everything fit together, which things interact with each other), what keywords are used to specify x, y, or z .. so on and so forth. These things take time (never mind the fact that some of the records, subrecords, properties have yet to be decoded). Just because something can be changed, saved into a plugin, and posted to nexus doesnt mean it is safe. It doesnt mean that changing the primitive bounds on the workshop sites wont have some unforeseen consequences later on down the road. We simply don't know yet. There are often unintentional side effects, 'bugs' pop up when you don't expect it, etc.

As others have said.. yes, there are benefits to xEdit. Always has been. Some things are way better suited for xEdit, others for CK. CK, though, is invaluable. It's not just scripting and decoding records, it also has a way of showing you visually how certain things tie together. For example, You could open a certain dialog box (for a container, for example).. the way it presents you the data makes it very easy to see what is important, how things are organized, etc. Sometimes what you see in a single diolog box in CK will actually represent multiple records in xEdit. So you can go into xedit, punch in the formid of what you were looking at in the object window in CK, compare everything, see the similarities, see the differences, and it really gives a better understanding of the puzzle that is the overall game. This is a very valuable part of the CK imo, one that is often overlooked and taken for granted.

Of course, my favorite part is the render window.. being able to edit things in cells and worldspaces.. making player homes, inserting new NPC refs, etc.

So.. there are many reasons why you need the CK. And no, xEdit is not the magic bullet some people think it is. It is a great tool and idk where we'd be without it. But it is only as valuable as the (responsible) modder who uses it.

Really want to thank all you guys for excellent responses! Cannot wait for that GECK

Even so, you've given me plenty of material to go through in the meantime

I don't, and have never had any desire to personally create mods, but I use them quite a bit. I've been using some mods practically since the game launched. Installing mods right now is a bit more complicated because it involves editing the .ini files, but it really isn't that complicated of a task. Anyone that has used a word processor or text editor at some point and has some basic knowledge of how to navigate through files on a computer is more than capable of doing this. The mods I've used up to this point haven't been very complex mods. I have one to make ballistic weave available on more articles of clothing, one that makes the recon scope look like the regular scope, one that adds a more realistic damage increase to the (incredibly underpowered) .50 caliber receiver swap for the hunting rifle. I also had to install the 'Vault Booty' mod to make females look a bit more 'defined' in the nether regions while wearing the Vault Suit.

I've had no major issues with any of this. When the first patch came out it took a little while for a fix to get figured out, because basically all the mods got disabled. Once a fix was found though, it really only took a few minutes to actually apply the fix. The GECK will make this a much smoother process.

I'm not sure that I'm necessarily addressing any of your questions directly here, but my point is that there are plenty of us that are already happily modding our games with basically no issues.

Hey about the .ini, I made some changes but I think I must have edited the wrong one. Why games tend to create multiple such files in different directories remains a mystery to me.

What is the default path on the .ini you actually use to change in game stuff?

I changed the value for "bBloodSplatterEnabled=" from "1" to "0" in the file:

C:\Steam\steamapps\common\Fallout 4\Fallout4_Default.ini

But still blood splatters.

I see there is a different file for each tier of the video settings (Low, Medium, High, Ultra) so maybe I need to change it all of those and then use one of those default settings? What if I use "custom" video settings?

Or maybe it is in a sub-directory where the save files live?

You want the one in the MyDocuments\MyGames folder for Fallout 4. The one you changed is the default copy that should never be edited.

Of course it is!

Luckily I only changed a couple values. But I'd guess that simply "Verify Integrity of Game Cache" in the Properties window of the game in the Steam library would revert any of those .ini files to their default values?