This thread is to provide handy little tips for modding Fallout, anyone can contribute tricks they've learned about modding and everyone can learn from them. I'll start.

1. My tip is useful for working with multileveled interiors or any other situation in which you have a lot of things blocking your view in the render window. Simply select the offending objects and press "1", press it several times and the objects will eventually become invisible, pressing "1" again after this will bring them back to normal.

And pressing F5 will re-load the cell bringing back all de-selected and invisible objects.

Ok, I'll write 2 things I found helpful in my last mod:

1. When detecting key press events, consider not using the FOSE functions directly but instead create a separate event detection script with a very low delay time which only polls the input keys and, if detected, sets a flag true

EventDetection:if isKeyPressed 123	set keyPressed to 1endif

Other script:if EventDetection.keyPressed  ;Clear flag   set EventDetection.keyPressed to 0   ...endif

With this method you can significantly increase the delay time of the other script and still don't risk missing any events. The same of course applied for any "transient" functions, getAnimAction etc.

2. As far as I know, there's still no "stopSound" function for fallout 3? A way to start/stop a looping sound i remember from oblivion is to first create the Sound and set the 2D flag, then create an activator with an invisible model (xmarker for example). set the looping sound of your activator to the sound you wanna play, and then place a persisent reference of the activator in some testing cell.
If you wanna start playing a looped sound:

loopActivatorRef.moveTo playerloopActivatorRef.enable

To stop playing:

loopActivatorRef.disable

If there's an easier way to do this, forget what I just said

Ya, you can just enable and disable the sound object itself, no moving required.

I didn't quite understand this yet, could you give some more details? disable/enable only works on references and if i don't move the object the sound is attached to near the player, he won't hear a sound?

Edit: Ok, thanks I think I got it now.

Now I'm not sure I undersatnd you. You can place a sound object (the green circle thingy) in the game, then if you give that object a reference ID and make it persistent, you can eable and disable it by script. I was actually talking about sound objects you place in the game versus objects that have looping sounds attached to them. But if your just talking about a sound object, this will work easily.

So just to clear it up: What I meant was an equivalent to

playSound loopSound... (wait until condition is fulfilled) ...stopSound loopSound

So a sound, not specifically attached to any object but local to the player. But using an activator instead of the actual sound references indeed is unnecessary.

Ive never modded for fallout ( just morrowind ) but i believe the same applies here.
Always have a website next to you if you forget a command
something like this http://fallout.wikia.com/wiki/Fallout_3_console_commands_(all)

A few threads of similar like from the CS forums : http://www.gamesas.com/bgsforums/index.php?act=Search&CODE=show&searchid=2d5eb2d3408d11053f5b1ff64f6af9bf&search_in=titles&result_type=topics&highlite=%2BTips

Oh, how I wish...

So, for that case, what you posted is great.

• If you're having code issues, debug the crap out of it. FOSE's http://fose.silverlock.org/fose_command_doc.html#DebugPrint (with http://fose.silverlock.org/fose_command_doc.html#SetDebugMode) and http://fose.silverlock.org/fose_command_doc.html#PrintToConsole are both great for this. If you're creating a lot of console output, http://geck.gamesas.com/index.php/SetConsoleOuputFile (note the missing t) can be very useful.
  
• Write down everything on paper first. Preferably, explain it out loud as well. Work through everything in your head first so that, hopefully, you'll be able to eliminate a few of the inevitable bugs before you actually implement your idea.
  
• There's no such thing as too much testing, and there are always more bugs.
  
• If you're working on a large project, particularly if you're working as part of a team, having some form of subversion control can be very helpful. There are various freeware options available, such as http://mercurial.selenic.com/ and http://tortoisesvn.tigris.org/, both of which I have used.
  
• When working with large cells, it is often easiest to create different sections in different cells, then join them up later using the GECK's "Paste In Place" tool. Just make sure to copy across certain reference points to keep you oriented.
  
• When testing your mod, you can avoid save corruption by calling http://geck.gamesas.com/index.php/CenterOnCell from the console straight from the main menu. If you need your character to be a certain level, or to have certain equipment, you can set up a batch file to run a series of console commands for you. Such files should be saved in your "Fallout 3" folder, and can be called from the console with the following syntax:

  bat MyBatchFile.txt

  
  
• If you want to quit the GECK quickly, the fastest way that I'm aware of is to cause an error, which will cause the GECK to ask you if you want to close it (it will close quickly if you tell it to close). The fastest way to cause an error is usually to create a new script and attempt to save it without any content. The GECK will tell you that a scriptname declaration is required, and then ask you if you want it to keep running.

Cipscis

1 - Save often
2 - Backup often (copy paste to a backup folder, with version names on the backups)

The Geck saves your last 10 version in the \data\backup folder.

True, but Murphy loves us all...

Haha. True words of the wise.

Navmeshing Bits:

1. Use the "W" key to quickly switch between NavMesh viewing modes, this is very important as you will see.

2. Use the "B" key outside to show the cell boundaries, which is critical for Navmeshing the cell boundaries correctly in exterior cells.

3. Try to make as large of triangles as you can, but in general (as Echonite points out), don't try to get elaborate as the GECK is going to re-write it when your done. Your key goal with NavMeshing should be to cover the areas where NPCs can go.

4. Do not make too-extreme of angles with the triangles, or the GECK will whine about it.

5. You cannot have more than 2,000 Navmeshes in any cell. More than this, and the GECK will error-out. Furthermore, Joystick Monkey says any more than 2,000 is bad for frame rate.

6. The cell boarders in exterior cells are Tricky. What you have to do is Navmesh each side of the boarder and line-up the edges as closely as possible. Each exterior cell has its Own mesh, and they don't physically connect to boardering cells. If you get the meshes at the boarders close-enough, a fat green line will appear at the boarder when you Finalize (see below step 9).

7. The "Tab" key is Huge. You will see this in the tutorial, it allows you to switch which two vertices from the last triangle that you have selected, so you can quickly "walk" your mesh across.

8. The "Test Cell Navmesh" is fabulous, you click it, then click a To and From spot on your mesh (click triangles), and the GECK will draw a fat line across the mesh where it Would send the NPC if it was trying to get from A to B. Its very effective in letting you know where the game would send your NPCs in specific game settings.

9. This takes time to do right, and I strongly recommend the tutorials from Bethesda. I started with them, and thanks to the short-cuts and methods they use I have since Meshed about 12,000-15,000 triangles. Their techniques and short-cuts REALLY make a big difference.

10. When your done with your mesh, do the following:

a. Save.
b. Click the, "Balance for Optimization" button. This will re-write the mesh in a more efficient form and you'll notice the number of triangles drops.
c. Check the mesh, as sometimes Balance can remove triangles if the space is too-narrow for NPCs or too angled. Fix any missing spots as necessary.
d. Click the, "Find Cover Edges" button, which finds the good corners that NPC's can use for cover while in combat.
e. Click the, "Finalize Cell Navmeshes" button, which will finish things up. If you have any errors, they will show up here.
f. Save Again.


Then to Test the Navmesh:

1. Open the Navmesh feature.

2. Select the Path Test button, which looks like a little path with 3 dots (in the middle).

3. Double Right-click two spots in your cell (give a second between the two spots), and you should see a big Green line showing you where the game will path the NPC. If it's not green, then the path was too-long to be efficient for the game engine.

4. Be very careful with this, as you can very easily crash the GECK if you hit Esc or try to do something else while Path Testing. When your done with a path-test, click the Path-testing button to turn off the feature safely.

Miax

Two scripting related tipps:

The first one is a general rule: Comment your own code! Not necessarily for others, but also for yourself, because after a coffee-powered night of half-awake scripting, on the next day it's reasonable to assume that you won't know anymore what you did and why you did it. So generally it's always a good idea to comment your code so not only yourself but also another person could understand it, cause very soon you will be this person

The second is on how to generally design your scripts. In scripting there are not many methods for abstraction, so sooner or later you'll end up with spaghetti code. It will be hard to follow control flow, and optimization becomes more and more difficult. One way I sometimes handle this is by designing my scripts based on discrete finite machines (if they're called like this in english). I'll give a simple example to illustrate the concept:

1. Abstract Features:You want to create a script for an armor that provides a stealth field effect. This stealth field can be switched on and off by a hotkey. Additionally, it will consume energy cells when active.

Next, find discrete states for your script. There are many possbilities, so you'll have to think a little (and eventually change then later). One example:

2. Discrete states:0: Stealth field disabled (can't be switched on)1: Stealth field standby2: Stealth field enabled

You could also have only 2 states (on/off), or more (disabled, enabling, enabled, activating, activated, disabling). But those 3 seem about right. Next, you have to create transitions from one state to another. These are based on conditions.

3. Conditions:cEquipped - Armor is equippedcHotkeyPressed - Stealth toggle button is pressedcEnoughCells - Enough energy cells left

For complex states/transitions, you can also draw a small graph.

4. Transitions between states0->0: !cEquipped0->1: cEquipped1->0: !cEquipped1->1: cEquipped && (!cHotkeyPressed || !cEnoughCells)1->2: cEquipped &&  cHotkeyPressed && cEnoughCells2->0: !cEquipped2->1: cEquipped && (cHotkeyPressed || !cEnoughCells)2->2: cEquipped && !cHotkeyPressed && cEnoughCells

These can be optimized later in the code. Speaking of which:

if state == 0	// do stuff		// Evaluate transitions	if cEquipped == 1		set state to 1		return	endif	return	elseif state == 1	// do stuff	// Evaluate transitions	if cEquipped == 0		set state to 0		return	elseif cHotkeyPressed == 1 && cEnoughCells == 1		set state to 2		return	endif	returnelseif state == 2	// do stuff	// Evaluate transitions	if cEquipped == 0		set state to 0		return	elseif cHotkeyPressed == 1 || cEnoughCells == 0		set state to 1		return	endif	returnendif

(Hopefully I didnt make too many logical mistakes)
While for small stuff this may be overkill, for larger scripts this generally results in a clear structure. I say it's easy to debug, understand and already well optimized because only a single state's code will run per script execution.