Fallout 2 mod FO2 Engine Tweaks (Sfall)

1.49a is up.

Code: 
>Added Hero appearance mod code from Mash
>Extra argument to hook script hs_combatdamage to get the weapon used in the attack
>Fixed set_script bug when used with critters
>New script function set_critter_burst_disable

Another set_script change that wasn't really related to the bug is that it now calls the start procedure automatically, and if you add 0x70000000 to the sid it'll call map_enter_p_proc too.
 
Hi Timeslip,
I was trying out the new version and found a problem.
Not sure what you did to fix the patch.dat path changing problem. But as my appearance mod uses some of the same fallout functions its still causing it to occur. To point a finger, the culprit would probably be my LoadHeroDat function.
 
Hey Timeslip, - good to see you're back and working your magic.

Have you had a chance to discover if it's possible to use sfall to make the game play a different animation when the player is hit for 0 damage?
 
Mash said:
Not sure what you did to fix the patch.dat path changing problem. But as my appearance mod uses some of the same fallout functions its still causing it to occur. To point a finger, the culprit would probably be my LoadHeroDat function.
Click to expand...
weird, my fix didn't actually involve modifing any fallout code, it was just a problem with the way I was reading back the paths list, so you didn't do anything that would have effected it.

Even weirder, I now can't cause the original problem, even if I remove my fix and your bit of code...

Edit: ok, if I remove your code completely it goes away, setting EnableHeroAppearanceMod=0 on its own isn't enough. It doesn't look like patch000.dat is getting loaded at all here unless I comment out the 'call LoadHeroAppearance;' line in the main menu function, hence why I couldn't cause the problem without the fix.

Edit2: I think the problem is that you're fooling fallout into thinking a patch dat is already loaded. I believe that changing LoadHeroDat to manually inject the paths into the paths structure instead of calling _db_init will fix it, but it'll have the side effect that any frm's in a patch dat or in the data folder will override those in your apperence folder. Is that going to be a problem? Are there likely to be any file name conflicts?

Edit3: urk, ReloadCritterDat's seems to be stomping on stuff too. I think I should just change it so that disabling it in the ini completely disables it for now, and later maybe we should try and rewrite it using sfalls existing filesystem override functions, rather than messing with fallout's db file functions.

Edit4: And the last edit for now, reuploaded with just that change. (New static variable 'loaded' in HeroApperence.cpp that gets inited to 0, then set to 1 in EnableHeroAppearanceMod(). All other non-static functions instantly return if loaded==0.)
 
question, what is the data i need to put in the elevator ini and what do i put in the script to trigger them(additional elevators)

nevermind,found it
Code: 
[24] 
Image=5 
ID1=0 
Elevation1=0 
Tile1=0 
ID2=10 
Elevation2=1 
Tile2=1000

and then in the spacial
Code: 
 metarule(15, NUMBER_OF_ELEVATOR);
works great except the buttons dont match to the level your on,meaning id1 location arrow was pointing to 3

edit : correction,it shows correctly for all except the first one(1 of 4 but is level 3 on the map) and points to 3

edit : thanks again for the new arg for what weapon was used,unfortunately i cant do what i wanted without min and max damage of the weapon,and weapon skill used in the attack,,dont sweat rushing if you decide to add a way to check for that info,i have lots of stuff to keep me buisy

edit : afaics the arrow is only wrong on elevators that have 4 buttons,and then only the first button
 
Timeslip said:
Mash said:
Not sure what you did to fix the patch.dat path changing problem. But as my appearance mod uses some of the same fallout functions its still causing it to occur. To point a finger, the culprit would probably be my LoadHeroDat function.
Click to expand...
weird, my fix didn't actually involve modifing any fallout code, it was just a problem with the way I was reading back the paths list, so you didn't do anything that would have effected it.

Even weirder, I now can't cause the original problem, even if I remove my fix and your bit of code...

Edit: ok, if I remove your code completely it goes away, setting EnableHeroAppearanceMod=0 on its own isn't enough. It doesn't look like patch000.dat is getting loaded at all here unless I comment out the 'call LoadHeroAppearance;' line in the main menu function, hence why I couldn't cause the problem without the fix.

Edit2: I think the problem is that you're fooling fallout into thinking a patch dat is already loaded. I believe that changing LoadHeroDat to manually inject the paths into the paths structure instead of calling _db_init will fix it, but it'll have the side effect that any frm's in a patch dat or in the data folder will override those in your apperence folder. Is that going to be a problem? Are there likely to be any file name conflicts?

Edit3: urk, ReloadCritterDat's seems to be stomping on stuff too. I think I should just change it so that disabling it in the ini completely disables it for now, and later maybe we should try and rewrite it using sfalls existing filesystem override functions, rather than messing with fallout's db file functions.

Edit4: And the last edit for now, reuploaded with just that change. (New static variable 'loaded' in HeroApperence.cpp that gets inited to 0, then set to 1 in EnableHeroAppearanceMod(). All other non-static functions instantly return if loaded==0.)
Click to expand...

That what I get for implementing something when I don't really understand it. I think I've figured out a better way to get it working though. I'll get back to you once I've got something together and tested it a bit.
Sorry for all the bother. :oops:
 
1.49c is up, only change is Mash's respin of the appearance mod, which can now be used without causing problems with patch dats and saving.
 
In F2 there was for example Vic who was able to repair something... Is there some possibility to let somebody steal something ? Maybe via pickup_p_proc and assign it to all scripts :?... And if so how to tell him what to steal? It seems it's impossible but.... :wink:
 
this is the same thing i asked for a few posts back

get_proto_data(objptr, int element)

have it return whats in the proto file,namly
weapon dmg min
weapon dmg max
is anim thrust or swing,melee skill
is anim punch or kick is unarmed
is anim shoot single or shoot burst and not big gun,is small guns
is anim shoot single or shoot burst and is big gun,is big guns
if is gun and dmg type not normal damage,is energy weapon
if is throw_anim is throwing weapons

or just be able to read those flags,that way anyone can script what they want
 
Hello. I've noticed that item highlight works only on level (elevation) 1 of a map, but not on level 2 or 3. Looks like a bug.

One more question, even when SharpshooterFix is set to 1 in ddraw.ini, it's only possible to get one level of this perk, although its description implies it has several levels. What's the cause?
 
i think set_global_script_type 1, 2 and 3 are broken as far as worldmaploop,this code never fires,metarule(30, 0) is car_curent_town,and will be -1 when not at a town,global 18 is player recieved car

Code: 
#include "..\..\HEADERS\MAPS.H"

procedure start;

procedure start begin
   set_global_script_repeat(1);
   set_global_script_type(3);
   if(game_loaded) then begin
      set_sfall_global("random_3", 1);
   end else begin
      if(metarule(30, 0) == -1) and (global_var(18) != 0) and (get_sfall_global_int("random_3") == 1) then begin
         force_encounter(MAP_SPECIAL_RND_WHALE);
      end
   end
end

maybe it is my script,not sure,but it seems logical to me

Nirran
 
Mr.Wolna said:
what's about a weather mod, that really works? ^^
Click to expand...
No idea. If there's any weather mod around other than my example script, then it's nothing to do with me.

B-2Admirer said:
Hello. I've noticed that item highlight works only on level (elevation) 1 of a map, but not on level 2 or 3. Looks like a bug.
Click to expand...
Oh, looks like the trick I was using to add the highlights only works on one elevation at a time. Easy enough to fix.

B-2Admirer said:
One more question, even when SharpshooterFix is set to 1 in ddraw.ini, it's only possible to get one level of this perk, although its description implies it has several levels. What's the cause?
Click to expand...
That is a fix for the effect, not the number of levels. Whatever the description implies, it's definitely coded to only have one level available. (Probably the description is a carryover from fo1, where there were two levels.)

Nirran said:
<snip>
Click to expand...
You should most certainly move the set_global_script_xxx functions inside the game_loaded block. Calling them every frame may cause breakage. For that script I'd stick with mode 2; calling force_encounter while on a local map is another thing you probably don't want to do.

Does it work without the 'if(metarule...' bit? (I suspect you need to try moving to make force_encounter kick in, in case you were just sitting there waiting for something to happen.) If it works without that, then my guess is that that particular metarule doesn't work from the world map, or that global 18 isn't what you think it is, otherwise somethings probably broken in sfall.

You can use display_msg on the world map for tracing purposes, you just wont see the messages till you next enter a map.
 
this code didnt display anything at all

Code: 
#include "..\..\HEADERS\MAPS.H"

procedure start;

procedure start begin
   set_global_script_repeat(1);
   set_global_script_type(2);
   if(game_loaded) then begin
   end else begin
      if(get_sfall_global_int("random_3") == 0)then begin
         set_sfall_global("random_3", 1);
      end
      if(metarule(30, 0) == -1) and (global_var(18) != 0) and (get_sfall_global_int("random_3") == 1) then begin
         force_encounter(MAP_SPECIAL_RND_WHALE);
         set_sfall_global("random_3", 2);
         display_msg("forced : " + metarule(30, 0));
      end
      display_msg("worldmap loop fired : " + metarule(30, 0));
   end
end
 
You haven't moved the set_global_script_xxx functions...

Also put display_msg's in elsewhere. (i.e. one in the game_loaded block, one at the very start of the else block.) If it is the metarule that's crashing it, that script wont show you anything because it never gets as far as a display_msg.
 
game loaded fired,nothing else

Code: 
#include "..\..\HEADERS\MAPS.H"

procedure start;

procedure start begin
   if(game_loaded) then begin
      set_global_script_repeat(1);
      set_global_script_type(2);
      if(get_sfall_global_int("random_3") == 0)then begin
         set_sfall_global("random_3", 1);
      end
      display_msg("game loaded fired : ");
   end else begin
      display_msg("worldmap loop fired : ");
      if(metarule(30, 0) == -1) and (global_var(18) != 0) and (get_sfall_global_int("random_3") == 1) then begin
         force_encounter(MAP_SPECIAL_RND_WHALE);
         display_msg("forced : ");
      end
   end
end

thought u ment set_global variable,missread
 
Nirran said:
game loaded fired,nothing else
Click to expand...
ok, traced it to an sfall bug. Will be fixed next version, but for now you can bypass it by changing WorldMapFPSPatch to 0 in ddraw.ini.
 
You must log in or register to reply here.
Back
Top