Fallout 2 mod FO2 Engine Tweaks (Sfall)

Lexx said:
You sure about debug dll? Because when I use it, the game crashs as well. The new normal file works now.
Click to expand...
Not quite what I meant by debug dll; the dll in the modders pack is still release mode, just with an extra #define. :)
 
I checked whether the motion sensor picked up critters that are set to invisible (NOT the half transparency that's used to simulate StealthBoy effects, but the flag set with the command: set_obj_visibility). Sadly, it doesn't. :cry:

Could that be 'fixed' with sfall? :mrgreen: It would make for some real cool quest posibilities.
 
Lexx said:
Characters with stealth boy? :p
Click to expand...

Yeah, a quest like: "Dispatch the invisible enemy commando". The hostiles are invisible. You check their positioning with the motion sensor (the red dots on the automap), then you go in their general direction. The critters appear with the regular stealthboy effect when you have the motion sensor in your equipment and are no further than e.g. 10 hexes from them.

Or some animals/monsters could be invisible, like the nightstalkers in New Vegas. You're supposed to hunt them. Could make for a pretty cool "Predator-esque" adventure.
 
Thanks for the "get_npc_level function" Timeslip.
Now I just have to figure out how to use it properly. :)
 
Darek said:
Thanks for the "get_npc_level function" Timeslip.
Now I just have to figure out how to use it properly. :)
Click to expand...
Again, the answers you seek are in the modders pack. ;)

Code: 
0x8241 - int  get_npc_level(char* npc)

get_npc_level also takes the npc name as an argument, and returns the npc's current level. Again, the npc needs to be in your party.

And to add something to that; if you give an invalid name or the name of an npc who isn't in your party, it returns 0. npcs start at level 1 and work upwards, so it'll never return 0 for a valid npc.
 
Btw, a question which is somehow related, I'll guess. What exactly does this mean?

Code: 
scr_return(1);

I saw that I am using it in various Sfall related scripts, but I totally don't know anymore why at all. There seems to be no difference if I use it or not.
 
Lexx said:
Btw, a question which is somehow related, I'll guess. What exactly does this mean?

Code: 
scr_return(1);

I saw that I am using it in various Sfall related scripts, but I totally don't know anymore why at all. There seems to be no difference if I use it or not.
Click to expand...
I've also found that return 0 does nothing (at least in the scripts I saw it used)
 
scr_return isn't an sfall function. From the mapper documentation: 'Sets the return value for a scripts C-engine node, to be used by C code.' I guess it's used in a similar way to script_overrides.

And the return 0 isn't a function at all. That's flow control. The compiler adds it automatically to the end of every function, which depending on the decompiler will show up in decompiled scripts. If you remove it, the compiler will just add it again the next time you compile. (And in fact, if you don't remove it the original compiler will add two. sfall's compiler can spot when adding an extra return isn't required, and remove it again.) If you manage to remove it completely, by hex editing the compiled script or hacking at the compiler, then you'll find that not having the return 0 makes a very big difference indeed. ;)

Another random fact is that all functions must return a value, and if you explicitly put in 'return;' with no value, the compiler automatically replaces it with return 0.
 
I have a very interesting script problem with scr_return. I've made one item, which is not usable, but can be used on something, so that I can use it in my inventory (item protos with "usable"-flag are not possible to use in the inventory- one must use "usable on something"-flag). Now in obj_dude script, I am checking if I'll use this item and then do actions, which ends with the object being removed on use.
First I've used normal "remove object from inventory"-stuff, which works everywhere else, but in this case, it only works until I have 1 item left and then it doesn't remove the item anymore. Very annoying and a critical bug.

This is where "scr_return(1);" comes into play. If I add it at the end, now I am removing 2 items instead of 1, but hey.. it works again. Now if I remove my normal "remove object from inventory"-stuff and only have "scr_return(1);" at the end, the game removes 1 item again- exactly what I want to have. That's cool beans and stuff, but I hope it will not ricochet to me at some point.

------------

Anyway, to get to something sfall related again: Would it be possible to allow the "use on"-option for certain weapons? I have a pickaxe, which I want to use on a scenery object, but the pickaxe is a weapon object. In order to use the pickaxe on the scenery, I must right-click the scenery, chose the bag and then the pickaxe weapon. I find this bad to use. Allowing to switch the weapon from "attack" to "use on" and using it on the scenery then, would make things much easier.
 
Another thing: It seems like in_world_map and get_game_mode doesn't work / works only if you visited the worldmap at least once. Can this be fixed? Would be of big help.

read_int() isn't working anymore either?

And: I still don't get how the debug editor is working. I am using the debug dll since forever, but I just see no difference (yes, also debugging entries in ddraw.ini). Are there some keys I have to press or something? The readme is very scarce on information about it.
 
Timeslip said:
scr_return isn't an sfall function. From the mapper documentation: 'Sets the return value for a scripts C-engine node, to be used by C code.' I guess it's used in a similar way to script_overrides.

And the return 0 isn't a function at all. That's flow control. The compiler adds it automatically to the end of every function, which depending on the decompiler will show up in decompiled scripts. If you remove it, the compiler will just add it again the next time you compile. (And in fact, if you don't remove it the original compiler will add two. sfall's compiler can spot when adding an extra return isn't required, and remove it again.) If you manage to remove it completely, by hex editing the compiled script or hacking at the compiler, then you'll find that not having the return 0 makes a very big difference indeed. ;)

Another random fact is that all functions must return a value, and if you explicitly put in 'return;' with no value, the compiler automatically replaces it with return 0.
Click to expand...
This is the advantage to scripting in Fallout 1 (vs Fallout 2) with TeamX's tools, none of this applies :D The code for Fallout 1 scripts is much cleaner than the code generated by Fallout 2 scripting tools.

EDIT: Then again the engine does a lot less, so I suppose that makes sense.
 
Hi Timeslip,

I've got issues with sfall and GPUBlt support on linux and even on Win XP. Every time it crashes.
My graphic Intel GM965 supports vertex/pixel shaders 3.0:
Do you think that something can be done with it?
Thanks

Sfall version v2.16

Code: 
description: VGA compatible controller
             product: Mobile GM965/GL960 Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 03
             width: 64 bits
             clock: 33MHz
             capabilities: vga_controller bus_master cap_list rom
             configuration: driver=i915 latency=0
             resources: irq:44 memory:fc000000-fc0fffff memory:d0000000-dfffffff ioport:1800(size=8)

glxinfo
wine output with debug d3dcaps d3dshaders
wine backtrace
 
eep, lots of stuff.

Lexx said:
Another thing: It seems like in_world_map and get_game_mode doesn't work / works only if you visited the worldmap at least once. Can this be fixed? Would be of big help.
Click to expand...
What's wrong with them? I tried in_world_map a few times, and couldn't get it to return anything unexpected.

Lexx said:
read_int() isn't working anymore either?
Click to expand...
To use read_int, or any of the other functions that let you prod around inside random bits of memory, you need to turn on the AllowUnsafeScripting option. (Which may or may not require the dll from the modders pack rather than the normal one... I forget.)

Lexx said:
And: I still don't get how the debug editor is working. I am using the debug dll since forever, but I just see no difference (yes, also debugging entries in ddraw.ini). Are there some keys I have to press or something? The readme is very scarce on information about it.
Click to expand...
If you're talking about bringing up that window to let you inspect global/map vars/critters/whatever, then yes you need to set a key up for it, and iirc it doesn't need the debug dll but still works fine with it. Make sure FalloutClient.exe is in the same directory as fallout2.exe, add the line 'DebugEditorKey=<whatever key you want>' to the [misc] section of ddraw.ini, then hit that key while on a local map in game. Make sure fallout is running in windowed mode though, or the editor will pop up underneath fallout and you'll get stuck.

Glovz said:
Just wondering if you have looked over the RP bug reports page - http://falloutmods.wikia.com/wiki/Restoration_Project_bug_reports - there are a few bugs there that are suspected to be engine bugs.
Click to expand...
I have looked over them. There's nothing there that struck me as having an obvious cause that I'd be able to fix quickly, and I don't have the time to take a more detailed look at the moment.

Drobovik said:
Here is a russian version for sfall translation ini.
You can include it into the package.
Click to expand...
Thanks, will include it in the next release, whenever that happens.

jirik said:
I've got issues with sfall and GPUBlt support on linux and even on Win XP. Every time it crashes.
My graphic Intel GM965 supports vertex/pixel shaders 3.0:
Do you think that something can be done with it?
Click to expand...
Not really any suggestions I can make, beyond making sure your graphics driver is up to date. You're right that that chip claims it will work, but if it doesn't there's not much I can do about it.

To ask the obvious question, do you have to use GPUblt? It's faster, but the only time doing the conversion on the cpu is slow enough for it to matter is when you're using the res patch to increase the resolution, and in that case you can use the res patches 32 bit colour mode instead. The only time it would be required would be using the res patch together with something else that requires dx9, like avi movies/pixel shaders/whatever.
 
Timeslip said:
Not really any suggestions I can make, beyond making sure your graphics driver is up to date. You're right that that chip claims it will work, but if it doesn't there's not much I can do about it.

To ask the obvious question, do you have to use GPUblt? It's faster, but the only time doing the conversion on the cpu is slow enough for it to matter is when you're using the res patch to increase the resolution, and in that case you can use the res patches 32 bit colour mode instead. The only time it would be required would be using the res patch together with something else that requires dx9, like avi movies/pixel shaders/whatever.
Click to expand...

Yep you are right, I was trying to use GPUBlt because of fallout with Hi-res patch on linux is almost unplayable ( too slow animations, mouse lagging). These lags occured through all wine versions so I think It's not Wine related issue (maybe some regressions in hi-res patch??). And CPU usage is always 95-100%.
My drivers are up to date and other games requiring shaders support running fine.

I was trying earlier to use 16/32 bit depth (depending on my desktop depth) for fallout, but everytime I changed the value, executed f2 and then depth was restored to 8 bit in preferences. Even if I was changing permissions of f2_res.ini only to read. (Maybe some linux issue forcing hi-res patch to use default value.)

And what about your SDL port of fallout graphic engine? Any progress?

Anyway thanks for your effort.
Keep up the good work!
 
Yea, I found out some time ago that you need to have the FalloutClient.exe in your Fallout 2 folder to make it work. Still, the debug editor is very buggy and crashs my game without exception. But it doesn't matter much, because I thought the debug tool is something that gives you more information about what generally happens in the game. I. e. a *real* log which shows you what exactly was the fault if the game crashed and stuff like that. Something like this is missing and makes debugging very hard, imo.

What's wrong with them? I tried in_world_map a few times, and couldn't get it to return anything unexpected.
Click to expand...

I *think* there was a problem with it not changing when you are on the worldmap for the very first time. But I forgot all details about it, because some time has passed already since then and I think the problem with my scriptstuff was workarounded later somehow (I didn't wrote the scripts by myself, because I lack deeper knowledge in this case).
 
jirik said:
And what about your SDL port of fallout graphic engine? Any progress?
Click to expand...
I haven't touched it in a long while. I was waiting on the raspberry pi, since the main point was to get it ported to arm.
 
Timeslip said:
Glovz said:
Just wondering if you have looked over the RP bug reports page - http://falloutmods.wikia.com/wiki/Restoration_Project_bug_reports - there are a few bugs there that are suspected to be engine bugs.
Click to expand...
I have looked over them. There's nothing there that struck me as having an obvious cause that I'd be able to fix quickly, and I don't have the time to take a more detailed look at the moment.
Click to expand...
Really, there are only two issues remaining that are the most annoying. Everything else is probably rooted too deeply in the engine to warrant looking.

1. Planting explosives on a critter and leaving the map to have it explode causes the game to crash. Can't remember if it's all the time, but it is definitely frequent. Darek discovered that if you enter combat mode briefly (before planting the explosives), exit combat mode, and then leave the map, no crash happens. Darek might have more information, but that is all I'm remembering.

2. Can't recall if this happens with all followers, but I know Vic suffers from it. If a follower is knocked out in combat and you leave the map, then (again not sure if this always happens) when you enter another map the follower will be unresponsive and acts like a container when you click on him. He'll keep following you around though. I have a save game with Vic in this state.

Darek did the most research on the above issues, so perhaps he'll have more to add.
 
You must log in or register to reply here.
Back
Top