amcclell

You can open the console by tapping the tilde key (`) then typing "showracemenu" without the quotes. Then hit the tilde key again and change your character. Rabbit Several mods also offer the option - essentially they're just doing the same thing as mentioned above, just through the UI rather than the console.

Maybe it picks randomly from these, along with a bunch of other, possibly negative effects. You could use the luck stat in order to determine your chances of getting better results - it's disappointing how luck really isn't used in FO3 like it was in the first two games (Where having high luck made you more likely to run into the really bizarre random encounters).

Not in the usual sense, no. You could, however, make a mod that fires a laser blast from your eyes when you push a certain hotkey. It wouldn't really function in the standard "Weapon" sense, though. *Edit*, actually, it depends on how you want it to work. To be able to use an embedded weapon while having another weapon out? No, only the above method can do that. But you could probably make an item that functions similar to a special weapon like that - it would mean you would have to "Equip" it to use it, though.

Remember that FO3 is based on the TES4 engine used in Oblivion as well, so FO3 is, to oversimplify, a hacked together total conversion for Oblivion. Now, they did do engine modifications for FO3, so it's a bit more complicated than that, but really, a lot of these complaints about FO3 could also be said about Oblivion, especially with regard to graphics/stability. I'm not really saying that makes it BETTER, but if they had based it on a brand new engine instead, it probably would have been in development for a hell of a lot longer. That said, the writing is a bit of a let down. It's functional, but it's not very interesting. Personally though, I think most of the story is told not through dialogue, but through all the little details in the Wasteland, and that IS done very well. FO3 isn't so much about the story as it is the setting. Really, the previous two fallout games weren't exactly stellar on story either. I mean, the plot of Fallout 1 was basically "Find a water chip -> Stop the supermutants. Do a lot of sidequests on the way". Fallout 2's story was a bit more involved, but it was still more about the overall setting of the game than the primary story arc. Gameplay-wise, I do agree that vanilla FO3 is kind of on the dull side, but that's what mods are for. I'm finding the game a hell of a lot of fun with FWE, but really, FWE is NOT for everyone. If the game shipped like that, I bet a lot of people would claim that it was way too hard.

Short answer: It depends entirely on the mods in question, which is why there isn't a general "Here is the correct load order" thread. Long answer: -Generally, anything that adds brand new content doesn't matter where it goes in the load order. Exceptions are when that new content is added to pre-existing vendors or containers, in which case: -Generally, anything that modifies existing content will conflict with other mods that modify the same content - so whichever one you want to use has to be later in the load order. -Generally, "Total overhaul" mods need to be earlier in the load order, since otherwise they're override pretty much every other mod you're using. -There are always going to be exceptions to the above rules, since there are about a dozen different ways to modify the same content in FO3, and each way will cause mods to interact in different ways. FO3Edit is a great tool if you really want to understand how load order works. Its entire purpose is basically to highlight mod conflicts and tell you which mods win the conflict based on your load order.

Are you talking about the effect it makes when chems wear off? That has nothing to do with withdrawl, it happens whether you're addicted or not. Withdrawl is the stat penalties you get when chems wear off if you're addicted. Better Living Through Chems has a plugin that disables that effect.

I don't know what the game does in this situation exactly, it's possible it just doesn't allow it, but even if it does, you would probably have some extremely strange behavior and probably crash a lot. The point is, even if the game starts, it won't work correctly, so just don't go over 255 mods.

If you really want to understand exactly how the load order works, download FO3Edit. The entire purpose of FO3Edit is to allow you to merge/modify mods to eliminate conflicts, and so it's naturally got a lot of features related to rooting out conflicts and has a simple colour-coding system for overrides. As a general idea, here's how the mod loading works: -Everything in the game has a "Form ID", which is an 8 digit hex number that uniquely identifies that object. The first two digits identify which mod the object is from originally, while the last 6 are the object's ID within the mod. -The first two digits of the mod are dynamic and dictated by load order. Fallout3.esm is always going to be 00-XXXXXX, and everything after that goes up sequentially (So 01-XXXXXX, 02-XXXXXX, etc) -Objects which have the exact same form ID will conflict. Now, "Conflict" doesn't always mean "Bad". Overriding an object from the basic Fallout3.esm is technically a "Conflict", but it's usually intended behaviour. -If an object is created new within a mod, it will use that mod's ID. Meanwhile, if an object is meant to override another mod, it will use that mod's ID. So, for example, if you create a brand new "beer" object in your 3rd loaded mod, it will have an ID of say, 03-123456, and not conflict with the "beer" object in Fallout3.esm. If, however, you design your beer as a modification of the one in Fallout.esm, it will share the Form ID from the master file, 00-015197, but only the one from your mod will be in-game (Because it's loaded after). -Long story short, this means that any time you MODIFY an object, it will cause a conflict and override something from a previously loaded mod. If you were to say, reverse your load order, then your modifications would be overridden by the original because it would be loaded in afterwards. Meanwhile, any objects which are entirely new assets will NOT cause a conflict - but depending on how they're placed in the game world, may conflict with other mods which try to use the exact same container (This is extremely unlikely, though). -This means that it is NOT granular down to the "field" level - though it depends a lot on which kind of object you're dealing with. Several objects have fields which are themselves other objects with their own Form IDs, and thus you can modify those objects without creating any conflicts regarding the top-level object they're being referenced by. A simple example is scripts - if an object calls a script on use, you can change that script as much as you want (At the editor level - once you're in-game everything is locked in) and the original object will still be considered "Unmodified" by the game. So to answer your first question, it depends on how you "add" the script. There are a few ways to do it, which will all work differently with regards to conflict resolution: -A quick primer on how item script calls works - there's basically 3 separate objects in play here. Item -> Base Effect -> Script. Modifications to one will not affect the other two, unless you change the references being made. -If you modify the basic object (Say, a stimpak) by adding a new base effect which runs your new script, then both scripts will run when the object is used - but because you've modified stimpaks, it will conflict with any other mod which modifies stimpaks. -If you replace the code within the script with your own script, then only the new script will run as it will override the version of the script from the previous mod, but stimpaks themselves will be unmodified and thus won't conflict with any other mods (Unless those mods remove the script call entirely from the object). -If you make a brand new script and change the base effect that the stimpak references to call the new script instead of the old one, then the stimpak will only call your new script when you use it, but the old script will remain available and function as normal on any other objects which might reference it. Since "Base Effects" have their own form IDs, stimpaks will also be considered unmodified by this method (So long as you only changed the Base Effect itself - if you made it reference a different base effect, then stimpaks would be considered modified and cause conflicts with other mods). -If you modify the old script to include both your new code AND the old code, then both will run simultaneously, but this will also apply to any other objects which reference that script, and will conflict with any mods that make changes to that script.

Mine does the same thing. I believe it's unloading the esp files from memory. The solution is that you don't actually have to close GECK to test files in game. Just save the changes, minimize GECK, and load up the game as normal.

What's this ---> "Mart's Mutant Mod - FWE with EVE.esp" and where did you get it? anyway, as for FOOK2 vs FWE... I think it depend if you are the LORE freak or not. FOOK2 has many "war" type things. Like that Ghost guy from ModernWarfare is now a Talon COmpany boss you have to fight. and lots of war-buff weps in FOOK2. But FWE follows more the "fallout" way of the game. Oh, and are you first time 'mod player', or first time Fallout3 playere? That looks like one of the FOIP compatibility patches. Search for FOIP here and you'll find it.

Ahhh.... Okey thanks^^ Though, for reference, explosion type objects automatically mark themselves for deletion after their duration expires, so in this particular instance you wouldn't need markfordelete. Most other object types you do, though.

The set command for CleanT is in a doctor script I didn't post, since it was working fine. All the comparisons are between a variable that's been set to GameDaysPassed at a previous time, and the current value of GameDaysPassed. That's why they have secondary conditions restricting the comparison so that it's only true when the values of *T are meaningful (Since, like you said, they're going to always evaluate as true because GameDaysPassed will be much higher than the starting value of the variables, which I believe defaults to 0).

I'm pretty sure this isn't the issue - I'd worried about that with another mod in the past, but it turned out not to be the problem, and the condition was much more complex than this one. Besides, all this would do is create a situation where the if statement would execute or not execute when I don't want it to - which isn't the issue I'm having. The issue is that stuff isn't executing more than once even when it's just in open space just after the Begin GameMode line (And thus it should execute on every pass). It's possible this might be causing a runtime error, though, since I tried what Schlangster suggested and it is indeed dying right around the point when those statements start. I'm still getting used to GECK not complaining about syntax except for flagrant errors like an unterminated If or a non-existent variable. It's kind of scary when C is more user-friendly than something. *Edit* Aha! I found it. It wasn't order of operations, but in the process of adding the brackets I found the error - One of the (20ish) checks was missing a && in the middle, so apparently If Player.IsSpellTarget WithdrawalBuffout GameDaysPassed - BuffoutT >= CleanTimeBuffout was good enough for the compiler but not the runtime. As soon as I fixed that, the script starting running how it was supposed to. I imagine you probably would have spotted that if I'd posted the entire script but at the same time I didn't want my post to be a huge wall of code that nobody wanted to read.

I'm having a very annoying bug with a script I'm working on. It's a Begin GameMode type quest script, attached to a quest set to be active on start (You know the usual "Background handler" kind of quest). The problem is, the script seems to only run once, when I load the game, and then never again. I can't tell if it's a bug with my game or the script or what, but it's very annoying. Everything else I'm running works as it's supposed to, but this script seems to refuse to behave. Here is the script in question: ScriptName AddictionToughOut ; All Addiction functionality goes here. float BuffoutT float UJetT float AlcoholT float AntNectarT float JetT float MentatsT float MorphineT float PsychoT float StimpackT float RadXT float TwoCIT float AmphT float BenzoT float CocaineT float DXMT float NoDozeT float MethT float PCPT float RadAwayT float SativexT float TobaccoT float QNukaT short Cleansed float CleanT float FailT short tempadd Begin GameMode ; Addiction Withdrawal is handled here Set Generic.Addicted to 0 If Player.HasMagicEffect AddictionEFFECT && Cleansed == 0 Set Generic.Addicted to 1 EndIf set tempadd to Player.IsSpellTarget WithdrawalRadX ShowMessage Debugger GameDaysPassed Cleansed RadXT tempadd If Cleansed == 1 && GameDaysPassed - CleanT >= 1 Player.RemoveSpell WithdrawalAlcohol Player.RemoveSpell WithdrawalAntNectar Player.RemoveSpell WithdrawalBuffout Player.RemoveSpell WithdrawalJet Player.RemoveSpell WithdrawalMentats Player.RemoveSpell WithdrawalMorphine Player.RemoveSpell WithdrawalPsycho Player.RemoveSpell WithdrawalQuantumNukacola Player.RemoveSpell MS09WithdrawalUltraJet Player.RemoveSpell XanderRoot Player.RemoveSpell WithdrawalRadX Player.RemoveSpell Withdrawal2CI Player.RemoveSpell WithdrawalAmph Player.RemoveSpell WithdrawalBenzo Player.RemoveSpell WithdrawalCocaine Player.RemoveSpell WithdrawalDXM Player.RemoveSpell WithdrawalNoDoze Player.RemoveSpell WithdrawalMeth Player.RemoveSpell WithdrawalPCP Player.RemoveSpell WithdrawalRadAway Player.RemoveSpell WithdrawalSativex Player.RemoveSpell WithdrawalTobacco Player.RemoveSpell AddictionClean ShowMessage AddictionCuredMessage Set Cleansed to 0 EndIf If Player.IsSpellTarget WithdrawalBuffout && GameDaysPassed - BuffoutT >= CleanTimeBuffout Player.RemoveSpell WithdrawalBuffout ShowMessage CleanBuffout EndIf (Snipped out a bunch of checks for other chems, they're all identical to this one) End Basically, it's the code from Wasteland Survivor for letting chem addictions wear off on their own, which I'm adapting for FWE. The part that's driving me insane is that I've run this before and it worked fine. Hell, as far as I can tell, it still works fine when the conditions are met. The problem is that it just doesn't want to keep running like it's supposed to. Is this an issue with my game or is it just something wrong with my code? *Edit* Just to make everything clear, here is the effect script that's run by chems when they're consumed: Scn ChemBuffoutScript Begin ScriptEffectStart If Addiction.Cleansed == 1 Player.RemoveSpell AddictionClean Player.AddSpellNS AddictionFail ShowMessage AddictionFailMessage Set Addiction.FailT to GameDaysPassed EndIf Set Addiction.Cleansed to 0 End Begin ScriptEffectFinish If Addiction.Cleansed == 0 && IsSpellTarget WithdrawalBuffout Set Addiction.BuffoutT to GameDaysPassed EndIf End

This is sort of tangentially related, but what's the interface mod you're using that shows the time/hunger/thirst/sleep and the like? If it's compatible with Survival of the Fittest I would love to use that (Even if it's not, I could probably modify it pretty easily to make it compatible, it's just variables).

Ah, there's your issue. You need to look at the "Doctors" QUEST itself - there's no script. Curing addictions is handled under the "Quest Stages" tab, index 20. The Result Script there is the script you're looking for - it's kind of a subscript for the quest, so you won't find it saved under Scripts. Just add the removeSpell line to the bottom there, just before "Set Generic.Addicted to 0" (I'm not actually sure how the game uses that variable but it's best to leave it alone if you don't know what it does).

Yes, I discovered that yesterday digging around - however, while I couldn't use that the way I wanted, it did give me the idea to have rain place a radiation explosion on top of the player every 5 seconds - and it turns out it works. The key issue I found out was that the "DamageRadiationLevel" Base Effect has a minimum damage of 1 - which I discovered when messing around and creating a spell that had a magnitude of 0 (Which still did 1 rad/s). Radiation explosions, however, function the same way as a Radiation Marker, so rad resist can bring it below 1 rad/s and thus make radioactive rain fairly manageable with rad-x and rad suits. I think I may upload this fix after I test it out a bit more just to make sure there's no oddness - I need to justify the amount of effort I've spent on it to myself.

*Bump* Still trying to get this to work to my satisfaction. Numerically, it works fine. I even got the geiger counter to show by having the game accumulate 1 - (RadResist) damage in a global variable every second, and when that variable equals one, it casts the "DamageRads" effect on the player for 1 rad damage. It still doesn't work how I'd like it, however - if you have decent resist, it looks weird just seeing the counter pop up every 10 seconds or so with none of the "Clickclickclick" sound you associate with being near something radioactive. I'd still like to figure out how the game handles irradiation by being near toxic waste or swimming in water, I can't find an effect anywhere. Is that stuff just hard-coded into the placeables or am I looking in the wrong places?

How are you trying to remove it? Doctor scripts actually remove addictions to chems on an individual name basis, so you need to modify their scripts to check for your new addiction in order for them to recognize it (Everything you need to modify should be in the quest "Doctors"). Make sure to add "Player.removeSpell (Your addiction name)" to the script they run to remove addictions as well - it's all well and good if they recognize that you have it, but they won't remove it unless you add that in. If you're really stuck, you can make an effect that uses the base effect "CureAddiction", which will wipe out anything flagged as an addiction on your character. Just to be sure, your custom addiction is an ActorEffect with a type "Addiction", right?

I've attached a screenshot of the ability the mod uses to cause radiation damage while it's raining (Er, just ignore that it's a disease. That was me just messing around to see if it would fix anything - normally it's an ability). What's confusing to me is I can't figure out WHY it doesn't work properly - it uses the built in "Damage Radiation level" function, which is already set up to take into account radiation resistance - except all my testing of the mod has shown that this isn't the case. I'll take a constant 1 rad/s damage, even if I mod my radiation resist to 100%. I've tested out rad resist on other sources of radiation that also cause 1 rad/s and they work exactly as I would expect them to - 90% resist makes me go up 1 rad every 10 seconds or so, etc. I'm thinking that in order to get it to work I'm going to have to use a script, but I'm still kind of a newb at quest scripting - how would I set it up so that a script runs once a second? Change the "Script Processing delay" to 1 instead of .1? If that's all it takes, I might actually be able to modify the pre-existing rain script to include radiation damage. *Edit* Well, I have a version that ALMOST works correctly. It calls a script every second that uses DamageActorValue RadiationRads to deal 1 - (RadResist) rads - and it seems to work properly with resistance. The only trouble is that it doesn't make the "Geiger counter" pop up while it's raining. Is there a command to manually display the counter in a script or is that something that's hard-coded into radiation damage effects? *Edit2* And now I can get it to work with an applied effect, if I set the amount of rads/s to 10, it resists properly (So at 90% resist I only take 1 rad/s)... but not if I have it at 1. I think I want to strangle this game. Do Actor Effects always round to an int? That might be the root of the problem if so.

I'm messing around with chems a bit, to see if I can make addictions work more like in fallout 1 and 2 where you could have them wear off if you go cold turkey. I'm not 100% sure if just modifying the duration of the "Addiction" parameter of the withdrawal disease effect will work, but I figure that's the simplest thing to try first. One thing I'm not sure about is the units for duration - seconds is obvious, but are the minute, hour, and day options real-time or game-time based? I run with my timescale modded down to 1:5 real:game rather than the default 1:30, so I want to make sure the duration lasts the amount of game-time that I'm intending (Rather than having something last 7 days REAL time, for instance). Additionally, this isn't as important but since it's related and I just thought of it, I might as well ask. If I give an addiction a duration, will that duration be refreshed if I use the chem again? For a random example, if the addiction has a duration of 10 hours, will it only last 10 hours from the initial addiction, or will that timer be reset if I use the chem again to counter the withdrawal? If it's the former, I might need to look into scripting to make it so that addictions will only wear off in time if I go cold turkey. Also, I'm aware that someone's made a mod that does something similar to this, but it has a bunch of other modifications to chems that I don't want, and it only affects vanilla chems, while I'm using better living through chems and would like those addictions to work properly as well.

Okay, so I'm using the Enhanced Weather mod with the radioactive rain plugin, however, the thing that's problematic is the fact that the radiation caused by the rain seems to bypass radiation resistance. The way he has it set up is an ability is applied to the player at game start and that ability causes 1 rad damage per second if the rain script is running and you aren't indoors. At first I thought that the game just couldn't handle dealing less than 1 rad per second, but I tested other sources of passive radiation damage (Like wading into water) with different levels of rad resist, and with high rad resist the rate of radiation accumulation was noticeably slower, despite the fact that those sources also only do 1 rad per second damage as a base. I think the issue might be the fact that the rad damage is caused by an ability rather than an outside source, and maybe the game ignores resistance on things that originate from yourself? (Even though it's using the base effect DamageRadiationLevel which should be resistable). My idea then was to change the rain script to make the game treat it as if you're wading into water when you're being rained on, but after about an hour of digging through the GECK, I cannot for the life of me figure out what effect or script or whatever placeable water is actually calling to cause the passive radiation damage. I'm not even sure if this would fix the issue, but I can't seem to find any other way to do it. Anyway, long story short, anyone have any suggestions about how to make this work properly, so that the player takes a consistent base 1 rad/s damage while it's raining, but have it be resistable like with swimming in irradiated water?