You can check for this already. For example, to check if the player is pressing (Left) Ctrl+G use "if IsKeyPressed 29 && IsKeyPressed 34", and to check if the player is pressing G without (Left) Ctrl, use "if IsKeyPressed 34 && IsKeyPressed 29 == 0".

Here's a list of http://fose.silverlock.org/fose_command_doc.html#DirectX_Scancodes from the FOSE Documentation.

Cipscis

If I had to guess...

I'd figure the "fire rate" entry is written in as a sort of scaled multiplier for one of the animations that makes up the categorized-animation's total frames per second. That way, if the numbers on the animation multipliers are unfit; square peg to a round hole; then that would account for the irregularities and chopiness in the weapon's in-game fire rate. Setting either too high or too low causes this to happen. There may also be several shared animations that are used by more than one firing type animation, since those "categories" likely identify only which sequence of smaller animation chunks to use when the trigger is pulled, which also shows why devs went with an automatic flag which probably tells the engine to chop off the ends of the sequence while the trigger is held.

I've been trying to edit a perk so that it applies when ever the player has a scoped weapon equipped, but I can't figure out how to check if the player has a scoped weapon in the perk settings(under weapon conditions you can apply it, but it doesn't seem to check how I want it to). I'm thinking I might have to set a global up for the checking, and if that global comes up a 1, then the perk applies, else, it doesn't, but I'm sure there must be another way.

Is it at all possible to make the con_setgamesetting function accept variables as arguments? Documentation says it can't, but I had an idea for a potentially mod-inclusive version of http://www.fallout3nexus.com/downloads/file.php?id=4805 that doesn't function because of that issue.

Will http://fose.silverlock.org/fose_command_doc.html#SetNumericGameSettingnot work for you?

Yes, it will. Just tested.

Gonna chit-chat with the creator of the original mod and discuss how the mod will be maintained. As more mods use this, space will need to be made. Even with the initial variables set up in the mod, modders will have to apply for a reserved variable entry in the mod in order for this to go smoothly. It'll work, but not without supervision.

Coming onto the actually-making-mods scene earlier to day (Though I've been playing F3 for a week or so, and Oblivion for ages, with mods galore and the **SE's <3), is it known if it will be possible for FOSE to implement new events? Like OnFire for guns, OnSwing for melee, or similar...

I've been messing around with a energy-level based weapon, and it seems like such a event would make it a good bit easier, as well as effects for other weapons, perhaps. (http://www.gamesas.com/bgsforums/index.php?showtopic=967181)


Either way, I'd like to add my own voice to the thanks for the tool =D

The standard scripting function GetAnimAction actually works quite well for stuff like that

when the pitt comes out will we have to move the dlc from gfwl to the fallout 3 program file folder so it could be recognized by fose w/o having to use gfwl? Is their supposed to be a pitt.esp or is it just an esm like anchorage cuz i dont see a anchorage.esp in my load order, only esm

As far as I know, Bethesda has not announced whether The Pitt will be a plugin file or a master file, but I would assume that it will be similar to OA. Either way, you'll have to move it into the Data folder before you can use it without GFWL.

Cipscis

thank you Cipscis

OH! Mighty FOSE Gods! I pray to you on my knees and wonder why 1.1b2 says my unworthy Steam FO3 1.4 instalation is an unknown version (1.4.0.6). May You, Allmighty, answer my question, plea?

It looks like there are actually two different versions of 1.4.0.6, one with a hash of 0x03ABCAA0, and one with a hash of 0x56492499. The first one was pushed out to all regions except Austria/Germany, this is the one that is currently supported. However, this second build is slightly newer (was built at a later time, not sure if there are any actual improvements) and was pushed out to Austria/Germany and apparently Steam sometime today.

Since the amount of time required to support each unique patch version is very large, we try and keep the number of supported patches to a minimum while supporting the maximum number of users. This recent development has made things a bit difficult, as the user base is now divided among 1.0.0.15 and the two versions of 1.4.0.6.

First off, we'll be dropping support for 1.1.0.35 as it doesn't offer any improvements over 1.4.0.6, plus patches for that version are widely available. Secondly, we'll be waiting a few days for the DLC to be released to see if Bethesda releases another patch unifying the 1.4.0.6 versions (please?). At that point we will need to reevaluate the situation and see what we can support. In the worst case scenario we will probably need to end up supporting all three versions.

This is good news for people in Austria/Germany, and not good news for us. People will need to hold on for a few days so we can see what Bethesda does regarding this situation. In the meantime, if you are using Steam, turn off auto-update temporarily.

If they ever fix VATS, things will get easier for you, as everyone will be adopting that hypothetical patch. The greatest reason people are holding on to 1.0.15 is because of the pervasive VATS bugs in 1.1 and 1.4.

Is there any way to edit the CRC check, than, just for us STEAM-morons? I'd do it with the source, but I have no complier on my pc , and hD editing gives me the creeps...

Sadly no. For each build we support we need to locate a large number of memory addresses. This is time-consuming work and also requires significant testing as one wrong address translates to sometimes difficult-to-spot bugs.
It appears there are some reports of problems with the DLC released today which may increase the probability that yet another patch will be forthcoming. We'll keep you updated as we get more information from Bethesda regarding patches.

Well, qt least you guys are more attentive that Beth devs ^_^
I'll be here, waiting on my terrace, with my lovely Eugene on my lap, 'till I can go back to the big killing spree I love

They need to build a new EXE every time they add new achievements due to the way Live works, so we're guaranteed patches every time they release DLC until they hit the (arbitrary) 100 achievement limit. This of course doesn't mean that there will necessarily be any /other/ changes or fixes.

I know you guys are in compatibility hell right now, but could you stand to add another function to your todo list? I've been frustrated by the lack of a way to push objects around using scripts. Something like PushActorAway, but which works on more than just actors would be so useful. What do you think?

My apologies if this is a stupid question, but is it possible for a script to detect that FOSE isn't installed and display a message if not? I tried this code...

		set FOSEtemp to GetFOSEVersion		if FOSEtemp != FOSEversion			set FOSEversion to FOSEtemp			set FOSEmessage to 1		endif		set FOSEtemp to GETFOSERevision		if FOSEtemp != FOSErevision			set FOSErevision to FOSEtemp			set FOSEmessage to 1		endif		set FOSEtemp to GETFOSEBeta		if FOSEtemp != FOSEbeta			set FOSEbeta to FOSEtemp			set FOSEmessage to 1		endif		if FOSEversion > 1			set FOSEok to 1		elseif FOSErevision > 0			set FOSEok to 1		elseif FOSEbeta == 0			set FOSEok to 1		endif		if FOSEok == 0 && FOSEmessage == 1			ShowMessage HoverCFOSEMsg			set FOSEmessage to 0		endif

... in the hopes that calls to GetFOSEVersion etc. would return a zero if FOSE was absent. No such luck, my script seemed to just not run.

Am I trying the impossible? Or just getting it wrong? Thanks.

You need to split it up into two scripts: one to set a variable to GetFOSEVersion, and one with no FOSE functions to check for it. That way if somebody tries to run your mod without FOSE, the script that sets the variable won't run, but the one that checks it will, and you'll be able to display an error message.

Ah, of course! Thank you!

*kicks self hard in shins and walks off muttering *

http://www.gamesas.com/bgsforums/index.php?showtopic=971140

I would be especially interested in feedback from the FOSE team and FOSE users.

While the base game is pretty much limited to a "IsInList" check, which would imply a Set, FOSE adds functions that allow to access FLSTs by index, which would indicate that the order of FLSTs entries suddenly becomes important, preventing a meaningful merge based on set rules.

We use the form lists like ordered lists. Internally they are implemented as a linked list and while the GECK doesn't allow you to have duplicate items in them, the engine is just fine with it. I am not sure about persisting those changes and whether duplicates are pulled, but at run time it works fine. I'll check out the thread and see what the discussion looks like there.

I see that Ian has already been all over the thread - so no worries.

I'm not sure why, but suddenly I can't start Fallout with FOSE anymore. I'm crashing at the first intro screen that says "Please stand by".
I'm using version 1.0.0.15 and I have the necessary fose_1_0.dll installed as well. I'm not using any DLC and I have my Windows Live disabled with Quarn's tool. I haven't changed anything about my setup today, but it has just stopped working. I've tried to reinstall FOSE and the game itself, but to no effect.

My fose_loader.log says:


Does anybody have an idea what could be causing this or any suggestions what I should do?

[edit]
I forgot to mention it, I can start the game with the Fallout.exe just fine.


[edit 2]
I just patched the game to 1.4 to see if that would solve my issues, but it didn't. Still crashing at the exact same time.