tunaisafish

majinshinsa, you mentioned NVSE. It's a good idea to use while debuging your scripts even if you don't actually need the features in the release version. Use the printc function to see if your script is actually running when you think it is. Put this line in your block, and view the console when testing your mod ingame. printc "Beer ScriptEffectStart" I'm guessing that this is only running when you consume the first beer, and is skipped on subsequent beers as the effect has already started. Does the global increase if you let the beer effect wear off first? (I've not had use myself for an effect script so this is just speculation) The other thing I'd do is right click on the global and choose 'Use Info' to see if I'd written anything else that changes it.

Thanks chuck, I grabbed those nifs :) Have a project on the back-burner that they could come in very handy for.

See this thread making-non-static-objects-static-help on the Bethsoft forums. Particularly the response by JOG about static collections.

Looks fine to me, although I've only used GetScript. Just noticed this in the doc... SetScript Alias: none Parameters:2 scriptInRef:GenericObject item:GenericObject So maybe the script just needs to be stored in a ref ?

Most of the containers ingame have no physics data in the mesh. Try the sunset sarsaparilla crate one if you want to use an ingame resource that does have the physics.

Yeah just remember the filename of your image. There's a browse button so you can select it in a program-manager type box from your PC.

There's a box to type in file version. Did you leave it blank? Once you get past that stage you'll have the opportunity to upload your project files.

There may be something like that already in the God Items section. Freezing the contents of a container is probably more complex than you need. An activator that added the supplies to your inventory would be easier. OnActivate player.AddItem YummyCheese 999 End But, everyone already has that cheat on the console should they be so inclined :)

Look in the 'Tools' menu of FOMM. There's a BSA browser/creator there. Not sure if the pistol is there. You can filter if you know the name though. Edit: Ninja'd by Speedy :)

You'll find this thread of interest modern architectures. Same question basically, and the jury is still out.

Hi ObLars, yep it makes it much easier to follow if you endent as PaladinRider states :) Your problem is that your code will only ever run once (when stage = 40) You increased the stage within that, so that's why your additional stage code only ran once too. Reorganising your code, this would probably work. Hard to tell exactly without seeing your quest but this seems what your logic was trying to achieve... Now for some out of the box thinking. The problem with the above is that you would need to keep the quest running for the checks to take place. The code will also 'continually' keep enabling the Brahmin, even though there is no need. It's just a waste of CPU. So... as the ref's only need to be enabled when the user purchases your 'Brahmin' token, then place the code there. And once the token has enabled the particular cattle, it no longer needs to be in the players inventory. Wherever you sell the 'Brahmin' token to the player, add the condition 'If Brahmin3REF.GetDisabled == 1', so it will only be available if there are Brahmins to actually buy. Hope that makes sense :)

Sorry, I should have quoted this part before when replying. For me, refwalking has worked like a breeze since I read what Cipscis calls the 'apple bug'. I've not had to resort to creating quests to manage that part at all. I wasn't knocking your proposed solution to the OP's problem if that's what you thought BTW, listclear is not yet implemented for NV. You refer to the apple bug as being involved in formlists, yep I know there are some caveats there too. For all I know one of those is refered to as the 'apple bug' too... before my time :)

I've used refwalking extensively in Sortomatic... and yes I did run into some bugs. I spent about a day looking at my code looking for silly mistakes, and putting debugging statements in to see what was happening. The ref's were getting walked, but the properties from the refs were 'stuck' on the first ref found. The solution is simple, but I never would have guessed it. It's an old problem dubbed the 'apple bug'. The only reference and fix/workaround for this I found on Cipscis' Loops page.

I agree with the others about the actual content of your messages Koalma, but I applaud your choice of topic. It was clear and concise, without deliberate spelling mistakes, and described your query to the point. So I'll just answer that. Yes, there are. Have a nice day.

Oh you have a block then. A 'gamemode' block in this case. Finding syntax errors can be like looking for needles in a haystack. Install Geck-PU. You will thank yourself for it.

You cannot put calculations, functions etc. outside of blocks. Install GECK PowerUp to get script compilation warnings. I'd be bald right now from pulling my hair out without this tool.

Try NCCS.

It sounds like you've deleted something that was not part of your own esp package. If it was in your package then reopening the GECK would have solved the issue as Floatsup & angelwraith said. As far as I know you can't undelete a delete within the GECK. But FNVEdit is your friend here. It's always a good idea to look at your esp with FNVEdit, you may be surprised at the other resources you've accidentally edited.

The problem is the last line. 'Disable' - that just stops the graphics from rendering. Your script is still running in gamemode every frame, hence why you can't seem to move. Follow that line with 'MarkForDelete' BTW, You don't need to use the 'roachref.' reference prefix. The current object instance is implied. When you have gamemode blocks that you only want to happen once, use a variable to protect the block. You can't be sure that the object will actually be deleted in the same frame. I'm not sure if the markForDelete flag is checked before running the block again, so it's a good idea to use a protection block here too. ref roachref float teleX float teleY float teleZ int iDone begin gamemode if iDone == 0 set iDone to 1 set roachref to GetSelf set teleX to GetPos X set teleY to GetPos Y set teleZ to GetPos Z Player.SetPos X teleX Player.SetPos Y teleY Player.SetPos Z teleZ Disable MarkForDelete endif end

I've scratched my head over that puzzle too. You can't read the health of the weapon unless you equip it to the player, and there's currently no way to read the mod info afaik. And to make things trickier, if the actor had more than one of the weapons, equipping one wouldn't necessarily be the healthiest, or the most expensive.

I was browsing the ini file and saw this setting that reminded me of this thread... SCharGenQuest=00102037 ... and that corresponds to The quest ID of VCG00, that leads onto VCG01. So that might explain why it kept raising from teh dead. Levelled lists, no I don't think so.

Does this container have an OnLoad block? The reason I ask is that when the game is loaded from savegame, the OnLoad blocks in the current cell don't fire. And as far as the savegame is concerened, that crash never happened.

A few things... Wrap your message in a conditional 'DoOnce' to stop it popping up every 5 seconds. You only need 'one' GameMode block. I've not seen menu option handling used in a quest script before so not sure if it works for that type of script. Nothing in the GECK wiki to suggest it wouldn't. Maybe it does and the second gamemode block never ran??? Oh... and you should stop your original quest once it has done its' business. scn SCRIPTYDIPTY int iButton int iDoOnce BEGIN GameMode if iDoOnce == 0 set iDoOnce to 1 ShowMessage altCG00message endif set iButton to GetButtonPressed if iButton == -1 Return elseif iButton == 0 startQuest altCG00Assassin stopQuest altCG00 endif END Edit: What was probably happening is that calling ShowMessage was setting the result of GetButtonPressed back to -1 before you had chance to read the previous value.