Nice work guys, it's good to see another beta release.

I don't think Fallout 3 uses "hair length" data in any way, so any information about that is probably vestigial from Oblivion. Unless someone knows otherwise, I suppose.

Cipscis

That will come in handy! Thanks, guys!

*brainstorm copied from another topic*

Hey....I just had a thought...and yes, it was mildly painful

There are functions, both vanilla (limited) and FOSE (I think...) to write things to an external file, such as a .txt file while the game is running, such as the console dump, etc.

*IF* the function(s) are there in FOSE (I'll have to wade through the bazzillion commands heh), WOULD there be a way to export CURRENT gamesettings/globals/etc into a file, triggered, lets say, by the player doing a save, and/or everytime they hit the ESC key to enter the game menu?

If so, this could go a long way toward helping with continuity issues that we've all had issues with. You could theoretically force-save and force-load everything from object/npc positional data to current AI packages on an NPC to the state of a trap (triggered or not)...even door states, heck the list goes on and on.

*IF* this isn't in the vanilla or FOSE commands yet...I think this would be a helluva addition to FOSE. And since there are at least basic functionalities for exporting data already (console dump, etc) I should think customizing a similar command(s) for dumping all kinds of variables, globals, etc. should be doable, yes?


What I'm 'picturing', if you'll bear with me, is each mod that wants to export data would dump that data to a sequential text file with the mods name, so if a mod has an .esm and three .esp files, theoretically, the mod could maintain four separate .txt files, each with data specific to that .esp or .esm.

The data in the file could be force loaded via script whenever the game is loaded from a savegame, and from there could be applied to...well...ANYTHING that might need it.

This could conceivably solve everything from traps breaking to NPC's not being where they should.

Also, a GREAT command I'd like to see, if it isn't in there already: GetExists.

This would return a (1) if the object or NPC or creature in question is physically in the game world....ANYWHERE in the game world. and a (0) if not.

This would go hand in hand with the data export/import functions to solve things like vanishing NPC's.

Example: I have a cavern system with a scripted NPC ghost. The ghost is spawned when the player enters the caverns, and the exit is blocked off behind them. The player has to travel a short distance to encounter the 'ghost'.

*PROBLEM*: If the player saves the game and later reloads it before/during/after meeting the 'ghost'...the npc vanishes, never to be seen again.

By storing the fact that the player is 1) in the caves and 2) has not triggered/has triggered/has talked to/whatever the npc state is, and by running a script that fires everytime the game is loaded up from savegame, even with quickload/save....I can grab or respawn the vanished NPC and plop him back where he belongs, and set his current state to what it should be.

Is there any current list of the commands (and their parameters) in the latest 1.2 beta? I know I could go through the various FOSE threads, but that's a bit slow.

Thanks .

Awesome! Thanks so much for making this happen!

I can't wait to play with the new commands.

Ooooo GetRefCount! Yummy!

The SetRefCount... I wonder how this would be used? I would imagine it could be quite dangerous if set beyond what there are valid pointers to.

GetCurrentQuestObjective and GetNthQuestObjective should be interesting!

How is documentation normally done for new FOSE toys? Is that up to us chickens to pluck our way through the new commands and update the WIKI as we figure it out?

Miax

I may be mistaken here but I believe the commands in 1.2 beta 1 are the same as in 1.1 beta 9. Only plugin support has been added.


Edit: sorry, that's really incorrent.

Interesting - that would probably explain why setting/getting the didn't seem to do anything useful. I was blaming it not rebuilding the blended model. If it really does nothing then I'll take those out for the next release.


For gamesettings and globals this is relatively easy, but the rest of your post talks about the "etc" part which apparently means "the entire state of the game". To do that would require that we determine how all of the game state is stored, which we haven't even come close to in Oblivion.


Exists meaning that you have a proper reference, or exists meaning exists in the scenegraph, or... what? Please be more specific.


With that function, you aren't setting the reference count of an object, you're setting the count attribute on a reference object. I assume this would be used for ammo and money and things like that.


Usually behippo updates the HTML documentation, which then gets propagated out to the wiki, but I haven't heard from him in a while. In this case my main goal was to push out a release with bugfixes and support for the nogore runtime.

Cool, thanks! I already have uses... neat.



Sounds good - I was just curious more than anything. I use FOSE so much now that I spend a fair amount of time in the docs, and plan to start playing with some of these immediately!

Cheers

Offhand I would say proper reference. I'm not entirely certain what you mean by 'scenegraph', but my thinking was in reference to objects and NPC's that have a properly defined REF from having been handplaced in the world.

If I'm thinking correctly about what you mean by scenegraph, however, an extension to the function to grab 'any' reference that matches what you input would be interesting as well...but preferably as either a separate function or an option (such as checking to see if any raidergun01 have been spawned in the players current cell, perhaps).

Ideally though, as I say, I want to be able to keep track of my hand-placed objects and NPC's that have specific references, so yes, I would say 'proper reference'.





I'm not referring necessarily to predefined gamestates, but to any variable the modder desires, with the value he desires. The CONTEXT of the data would be the problem of the modder, not FOSE itself.

This would simply be a matter of: EXPORT , and would encompass the standard numeric variable types, string data, and hexidecimal.

So instead of you having to figure out how to export, say, the specific gamedata for what time of day it is (although that would be nice), the player would GET that data from the game in his script using commands that already exist (why reinvent the wheel?) then ASSIGN that data to a variable, again from within his script, and then perform the EXPORT function on that variable.

That way you, the FOSE folks don't have to worry about defining 'the entire state of the game', as you say, and the onus falls on the modder to define and use his data on his own terms.

It would be nice with some way of interacting with an external file. Loading or saving mod settings could be quite useful for configurable mods. I think, I requested something like that a while ago ...


Is there a way to get information on how to call the new functions from the dlls or source code?

Here are some not overly great docs for the commands added since the last documentation update (since 1.1)

float form.GetCurrentHealth() - returns the health of form
void SetCurrentHealth(float health, ref form) - sets the health of a form
float Rand(float min, float max) - returns a random value between min and max
int form.GetNumItems() - returns the number of items in a container
ref form.GetInventoryObject(int idx) - returns the type of the specified item in the container
int form.GetRefCount() - returns the number of items in a stack
void form.SetRefCount(int count) - sets the number of items in a stack
float Pow(float a, float b) - returns a ^ b (b does not need to be an integer)
int form.IsQuestItem(ref obj = NULL) - returns if form (or obj if present) is a quest item
void form.SetQuestItem(int arg, ref obj) - sets if form/obj is a quest item
int form.IsOffLimits(ref actor) - returns if the specified door is off-limits to the actor (note: apparently not 100% reliable for the player yet)
ref form.GetParentCellOwner() - returns a ref to form's parent cell
ref form.GetOwner() - returns a ref to form's owner
int form.GetOwningFactionRequiredRank() - returns the rank someone must be of the owning faction to be considered an owner of form
int form.GetOwningFactionRequiredRank() - returns the rank someone must be of the owning faction to be considered an owner of form's parent cell
ref GetCurrentQuest() - returns the current quest
ref GetCurrentObjective() - returns the current objective
int GetQuestObjectiveCount(ref quest) - returns the number of objectives for the specified quest
ref GetNthQuestObjective(ref quest, int idx) - returns the specified objective of the specified quest
void SetCurrentQuest(ref quest) - sets the player's current quest
int form.IsPersistent() - returns if form is persistent
int form.SetEyes(ref eyes, ref target = NULL) - sets the eyes of form (or target if specified)
int form.SetHair(ref hair, ref target = NULL) - sets the hair of form (or target ir specified)
int form.SetHairLength(float length, ref target = NULL) - sets the hair length of form (or target if specified)
ref form.GetEyes(ref target = NULL) - gets the eyes of form (or target if specified)
ref form.GetHair(ref target = NULL) - gets the hair of form (or target if specified)
float form.GetHairLength(ref target = NULL) - gets the hair length of form (or target if specified)

edit: emoticons are the cancer killing forums

Thanks a lot!

So, if I were to iterate through all items in a container, I would have to do something like this:

ref containerref itemset count to container.GetNumItemsset i to 0label 1if i < count   set item to container.GetInventoryObject i    set i to i + 1 ; do something using item   goto 1endif

That is going to be useful!

+1 as well, Thank You!

Sorry, a newbie (me) needs help on your version numbering.

When the final version of what you call v2 is released, what will be its "official" version number? 1.2 beta ? 2.0? And what will GetFOSEVersion, GetFOSERevision and GetFOSEBeta return?

It was kinda clearer in OBSE.

Minor bug report: Using GetNumItems writes "item count: " followed by the number of items in the container to the console when used in a script. Otherwise, it works

Thanks !

I would like to see a Clone Item command so we can have sorter systems that don't fully repair the sorted items.

x.y.z, where x = version, y = revision, z = beta. The version number is incremented whenever a really major change happens (with the current target being porting over strings/arrays/etc from OBSE, which won't happen until there's a stable release of that). The revision number is incremented for smaller changes like turning on the plugin manager or adding a block of functions. The beta number is incremented every time a version is posted in the thread.

Addition of complex variable types will probably be 2.0.. A final version of 1.2 where we have a block of tested known-working stuff will similarly be 1.2.. These versions go up on the website as the "current stable version", everything else goes up as the "current beta version". The most important thing about releases before we hit is that functionality may change, and scripts may need to be recompiled in-between releases.

If it were purely up to me then we would just have a single number corresponding to the perforce changelist making up the release, but /shrug. I blame the marketing department.

Minor bug report: Using GetNumItems writes "item count: " followed by the number of items in the container to the console when used in a script. Otherwise, it works

Fixed.

@ianpatt: Thanks much for your explanation.

I'm having some trouble with these two functions. I use the code below, where only one of lines marked with A, B, C, D, E are active at a time.

ref containerref itemshort ishort countfloat itemHealthset count to container.GetNumItemsset i to 0label 1if i < count   set item to container.GetInventoryObject i    set i to i + 1   set itemHealth to item.GetCurrentHealth	   ; A - compiles but stops script execution   set itemHealth to GetCurrentHealth item	   ; B - compiles but stops script execution   SetCurrentHealth( item, 0 )				   ; C - does not compile with error "Missing parameter float"   SetCurrentHealth( 0, item )				   ; D - does not compile with error "Missing parameter float"   item.SetCurrentHealth 0					   ; E - compiles but does nothing   goto 1endif

Removing the parentesis in lines C and D changes the error to "Expected end of line". Curiously, in the console, using GetCurrentHealth on a dropped weapon does nothing, but SetCurrentHealth actually changes the health of the dropped item. Am I missing something obvious?

To get the easy one out of the way, we need to write code to print results back in the console, and GetCurrentHealth doesn't have that set up right now. The next one is more complicated and is more of a misunderstanding about what GetInventoryObject does. GetInventoryObject returns a reference to the /type/ of the object in the inventory, not a reference to the actual object. This is because there are no actual references to inventory objects due to the way they are stored. Custom functions are required to modify the state of an inventory object, and right now we haven't implemented any.

So I did miss something Thanks for the clarification.

Well, I tried to run the FOSE editor, however, both ways give errors. It just doesn't work. I use the two ways as they are described in the Wiki, but CommandPrompt doesn't work, and the shprtcut method aslo doesn't work. I type in the command rpompt D:\>Program Files\Bethesda Softworks\Fallout 3\fose_loader.exe -editor\ and it doesn't get rocognised.

Anybody know why?

Harmy52

The problem is that the command prompt in Windows (and most other OSes) view space characters as separators between function call and arguments. The solution is to enclose the path to the program in quotes, so that it becomes

"D:\Program Files\Bethesda Softworks\Fallout 3\fose_loader.exe" -editor

Note that the argument -editor must be placed outside the quote.

Hey Ianpatt, Did my clumsy explanation of my thoughts regarding a potential 'Getexists' command, and regarding the possibility of a generic variable export/import function make any more sense this time? I'm not very good at explaining things, and your reference to a 'scenegraph' kind of went over my head (I've never heard the term in reference to fallout 3 or oblivion), but if need be, if the ideas interest you and the community at all, lets dialogue about it via PM til we can hash something out?