A "top-level exception handler" would be the outer most structured exception handler (which you can find by using the current exception handler pointer from the TIB and work your way outwards).

"Vectored exception handlers" are totally different. They are not in any way specific to the current context. Instead the OS keeps a simple linear list for the whole process of all registered vectored exception handlers. When an exception is raised, _before_ the normal structured exception handling starts unwinding the stack, all vectored exception handlers are called.

No matter if FNV already registeres a VEH of it's own (highly unlikely) or not, if you register an VEH and make sure to return EXCEPTION_CONTINUE_SEARCH you will not in any way interfere with the exception handling as already implemented by FNV.

A VEH gives you a first chance exception handler which is called before any others, while a "top-level exception handler", being the outermost SEH, represents a last chance exception handler, right before the exception escapes back into the OS code which started the current thread (and which will terminate the process if it ever sees an exception).

I think we are on the same page here. I understand how VEH works (it plays an important role in the memory management system of the very large commercial software product I work on for my day job.) From my experience using it, I know that other VEHs can interfere with ones we want to use. Windows will use various VEHs at times (which causes us all sorts of problems) and New Vegas could be using one and returning that it handled the exception. So yes, assuming our VEH gets called we ought to be able to make sure that we don't mess up New Vegas' handling.

Still - I am not sure how useful this will be or whether we'll be able to tell exactly what caused the crash. We'd have to dump the stack and investigate the current script handling (if script handling is even happening at all.) Certainly this isn't going to be high on our list for right now. We want to get the basic functionality up and working.

This has been an ultra-geek excursion to the depths of windows programming. Now back to our regularly scheduled program.

Its fascinating stuff though. Kinda like John Carmac's tweets; sometimes I can understand exactly what he is saying and sometimes, no clue.

This wasn't too-far off the beaten path, though I'm not a windows programmer so and deal in very different environments. I wish there were a better way to show thanks for all the work you folks do for the community. Endorsemants seem inadequate for the smarts that go into this.

does anyone know what the eta is for fomm for nv?

I'm curious about one thing though: how did you guys manage to run beta/alpha versions of NVSE if the exe is encrypted? Did you use "other exes" for your tests?

Note: I'm not judging you, just curious

I just remembered another feature, and I don't see it on the OP's list. I'd like effect scripts to have access to the Duration, Magnitude and Area fields. I heard that had been done for OBSE, so I'm guessing it's possible (unfortunately it probably won't be available in time to save me from the task I'd need it for.)

There is no ETA at this point. They need to wait for Bethesda to finish patching stuff. These things rely on knowing where stuff exists in the executable. Every time a new EXE is released, they have to redo a bunch of work. Even if Bethesda stops patching, they also need some cooperation from Steam. They need to provide them with a hook into the executable. If they don't get it, they'll have to implement a new method of hooking.


Trust me, people that are capable of writing a program like these script extenders are more than capable of getting around a little code obfuscation. Like most companies, you aren't allowed to discuss such topics on their forums.

OK, very good news. I've just finished talking with an engineer at Valve, and we've worked out a way to make NVSE compatible with the Steam wrapper. This means that our main worry about releasing is gone.

Massive thanks to Valve on this, you guys rock. (not sure if the person I talked to wants to be individually named)

Now we just need to implement enough commands to make for a good first release, and hope Bethesda doesn't update the runtime while we aren't looking.

Can I get a Hell Yeah?

That's awesome news guys, thanks for the hard work on this. And I'd like to thank Valve also, you guys have always helped the modding community and rock.

Well, that answers that question. Time to rock some socks with some mods.

First and foremost, getting my dll loaded. Dealing with those issues myself is no fun, particularly once Steam gets involved.
Beyond that (and really basic stuff like identifying the version of FalloutNV present) there's no hard and fast requirements. Stutter Remover likes to use OBSE to issue console commands, print messages to the console, basic things like that, but it doesn't strictly require anything beyond getting loaded so it can start modifying the executable image.

However, unrelated to Stutter Remover there is a feature I want to suggest - having your loader automatically enable (controlled by a command line option, but perhaps defaulting to enabled) the LAA flag in FalloutNV.exe. Oblivion didn't really need LAA, but it looked to me like Fallout was a lot closer to needing it, so probably a heavily modded New Vegas will be really getting close. I think that has to be done by the loader (though I'm not confident) and since presumably nvse_loader will handle the loading...

Sounds good. I know Ian is working on bringing over the plugin API - so getting you loaded should be no problem.

Unfotunately, I don't think we're going to be able to do anything about that. Because this is a real steam app, we won't actually have a loader application. Instead we'll have a loader dll, and we'll be loaded after the exe is already running. So we don't have quite the control we used to over loading executables. We can patch things, but I think we may be too late to change the Large Address Aware flag. Ian would know for certain, however.

Awesome.
In less than a week, you have pulled off something that would have taken a team of developers and a private law firm a month or two to do.

I personally wish there were some other way to show my appreciation for what you put in to this project other than just saying "thanks".
If it weren't for you guys doing this, it wouldn't be getting done.
Thank you.

We will only need a loader executable for the editor, everything else will be automatically handled via Steam. This also means that the method posted in http://www.gamesas.com/index.php?/topic/1128540-req-remove-the-2-gig-memory-limit/page__st__40 will be compatible with us.

Gratz on the steam-compatible loader! Valve does it once again! And nice to see you back, behippo

It is good to be back. I'm recharged and ready to really get this done. Just added all of the GetWeaponXXX functions from FOSE. They were a straight port over, so went quite fast.

behippo and Valve are credit to team!

As a player who cannot even think of Bethesda gaming experience without OBSE & FOSE, a huge thanks to Ian and behippo. Hats off to you.
The entire modding community owes you so much. Thanks.

Not enough :foodndrink: and :icecream: to express :mohawk:

Your guys' work is, not exaggerating, the single most important community contribution, in my estimation.

I've only recently started fiddling with FOSE scripts in the GECK in FO3 (I've been using FOSE/OBSE mods for quite some time) and it's a great tool. I have a few ideas for mods that I'd like to see in NV.

Anyway, wanted to say thanks for all your work, the modding community wouldn't be the same without these awesome script extenders.

And a request: I looked for a way of toggling the crosshair but wasn't very lucky. Is it possible to to implement something like GetShowCrosshair (returns 0 if the crosshair is off and 1 if it's on) and SetShowCrosshair (accepts values of 0 or 1 to deactivate or activate it)?

sounding good, glad to here valve is on board as well. Cant wait for the release to see what people start creating for NV

Good to hear Valve is still as helpful as ever, they really are good guys Looking forward to what the community can do with with the extender :foodndrink:

great work behippo (and valve!)

i'm actually suprised valve is helping as i know most companies wouldn't.

*glares at GFWL*

Actually, Valve is very good to the modding community. They've hired modders to come work for them.

It is still awesome though seeing developers that "Get it".

Go NVSE team! Go Valve! :celebration: