Stuff for define_extra.h

J

JimTheDinosaur

Vault Dweller
Modder
Because I don't want to keep cluttering up the engine tweaks thread with this, here's some random other stuff @phobos2077 might consider for the sfall header files:

Code: 
#define dude_base_st    (get_critter_base_stat(dude_obj, STAT_st))
#define dude_base_ag    (get_critter_base_stat(dude_obj, STAT_ag))
#define dude_base_pe    (get_critter_base_stat(dude_obj, STAT_pe))
#define dude_base_lu    (get_critter_base_stat(dude_obj, STAT_lu))
#define dude_base_iq    (get_critter_base_stat(dude_obj, STAT_iq))
#define dude_base_ch    (get_critter_base_stat(dude_obj, STAT_ch))
#define dude_base_en    (get_critter_base_stat(dude_obj, STAT_en))
//these are useful for making fake perks (don't want to replicate the game's mistake of allowing you to get perks using drugs ;))


#define random_encounter_is     (cur_town==-1 or (cur_town > 18 and cur_town < 48))



#define is_humanoid(x)     (critter_kill_type(x) < 5)



#define xp_val(x)    (get_proto_data(obj_pid(x), 392))



#define left_hand_is 0
#define right_hand_is 1


#define dude_worn       (critter_inven_obj(dude_obj,INVEN_TYPE_WORN))
#define dude_left       (critter_inven_obj(dude_obj,INVEN_TYPE_LEFT_HAND))
#define dude_right       (critter_inven_obj(dude_obj,INVEN_TYPE_RIGHT_HAND))


#define is_on_dude_team(x)    (has_trait( TRAIT_OBJECT, x, OBJECT_TEAM_NUM ) == TEAM_PLAYER)



#define current_hp(x)      get_critter_stat(x, STAT_current_hp)
#define max_hp(x)      get_critter_stat(x, STAT_max_hit_points)
#define num_of_cripplings(critter)   ((critter_state(critter) BWAND (DAM_CRIP_LEG_LEFT)) + (critter_state(critter) BWAND (DAM_CRIP_LEG_RIGHT)) + (critter_state(critter) BWAND (DAM_CRIP_ARM_LEFT)) + (critter_state(critter) BWAND (DAM_CRIP_ARM_RIGHT)) + Is_Blind(critter))



#define rest_healing_tick     (200*ONE_GAME_MINUTE)
//when resting or traveling, this is the amount of time it takes before the healing rate does its business.


#define straight_behind(x, y)    ((rot_to_tile(x,y)) == (get_rot(y)))
#define side_behind(x, y)        (((rot_to_tile(x,y)) == (get_rot(y) + 1) % 6) or ((rot_to_tile(x, y)) == (get_rot(y) + 5) % 6))
#define side_front(x, y)         (((rot_to_tile(x,y)) == (get_rot(y) + 2) % 6) or ((rot_to_tile(x, y)) == (get_rot(y) + 4) % 6))
#define front(x, y)              ((rot_to_tile(x,y)) == (get_rot(y) + 3) % 6)



#define rot_to_tile(x,y)	(rotation_to_tile(tile_num(x), tile_num(y)))
#define get_rot(x)			(has_trait(TRAIT_OBJECT,x,OBJECT_CUR_ROT))

#define team(x)                  has_trait(TRAIT_OBJECT,x,OBJECT_TEAM_NUM)


#define is_robot(x)              (proto_data(obj_pid(x),cr_body_type) == CR_BODY_ROBOTIC) 


#define inc_proto_data(x, y, z)           set_proto_data(x, y, get_proto_data(x, y) + (z))
#define dec_proto_data(x, y, z)           set_proto_data(x, y, get_proto_data(x, y) - (z))


#define inc_critter_base_stat(x, y, z)    set_critter_base_stat(x, y, get_critter_base_stat(x, y) + (z))
#define dec_critter_base_stat(x, y, z)    set_critter_base_stat(x, y, get_critter_base_stat(x, y) - (z))


#define inc_critter_extra_stat(x, y, z)    set_critter_extra_stat(x, y, get_critter_extra_stat(x, y) + (z))
#define dec_critter_extra_stat(x, y, z)    set_critter_extra_stat(x, y, get_critter_extra_stat(x, y) - (z))


#define inc_critter_skill_points(x, y, z)    set_critter_skill_points(x, y, get_critter_skill_points(x, y) + (z))
#define dec_critter_skill_points(x, y, z)    set_critter_skill_points(x, y, get_critter_skill_points(x, y) - (z))


#define sfall_ini_int(x)                      get_ini_setting("JimsMods.ini|MODS|" + x + "")
#define sfall_ini_string(x)                      get_ini_string("JimsMods.ini|MODS|" + x + "")
//x being a string. Just replace "JimsMods.ini|MODS|" with your .ini and your category header; note that you shouldn't use separate categories for this method to work
 
Last edited:
Just a small addition to the excellent new tile_light function, because it (counter-intuitively) doesn't give you the light level of a tile, but the light level that the tile adds to the general lighting level. So, a piece of dirt in the full light of day doesn't return a high light level, but a minimum one, while only a tile underneath, e.g., a torch actually adds maximum light. So, it'd be better to use:

Code: 
#define get_tile_light(x)     ((tile_light(dude_elevation, x)/65536.0) + (get_light_level/65536.0))

to actually get a representation of the light on a certain tile. However, you'd also need to take into account that a torch doesn't make a bright day any brighter by adding:

Code: 
if get_tile_light(tile) > 1.0 then
    light:=1.0;
else
    light:=get_tile_light(tile);


. This way, you accurately get the lighting of a certain tile on a scale of 0.0 (totally dark), to 1.0 (totally light).
 
Hm, didn't knew that about tile_light. I only tested it during the night and it never occurred to check in day light :)

As for the define_extra business, the purpose of this file, in my opinion, is to hold only simple constants for things that were in game originally, but were not accessible due to limitations lifted by sfall. Like offsets into prototype structures.
sfall.h is meant to hold all stuff directly related to sfall functions.

As for macros like is_humanoid, I think this doesn't belong in sfall modderspack as a must-use header. Maybe only like a set of useful examples in separate file.
 
phobos2077 said:
As for the define_extra business, the purpose of this file, in my opinion, is to hold only simple constants for things that were in game originally, but were not accessible due to limitations lifted by sfall. Like offsets into prototype structures.
sfall.h is meant to hold all stuff directly related to sfall functions.

As for macros like is_humanoid, I think this doesn't belong in sfall modderspack as a must-use header. Maybe only like a set of useful examples in separate file.
Click to expand...

Yeah, you're right, I decided to just use this thread to post random scripting stuff/shortcuts I think of. ;)
 
Some stuff for when you need to get/remove a value from a list (doesn't work with maps). I'm pretty sure none of these were possible with arrays so far, but maybe @phobos2077 can correct me.

Code: 
#define remove_list_unsorted(location, array)                        \
   array[location]:=get_array(array, len_array(array)-1);            \
   resize_array(array, len_array(array)-1);


#define remove_list_sorted(location, array)                          \
   counter:=location;                                                \
   while counter < len_array(array)-1 do begin                       \
      array[counter]:=get_array(array, counter+1);                   \
      counter+=1;                                                    \
   end                                                               \
   resize_array(array, len_array(array)-1);


procedure pop_list_unsorted(variable location, variable array) begin
   value:=get_array(array, location);
   array[location]:=get_array(array, len_array(array)-1);
   resize_array(array, len_array(array)-1);
   return value;
end


procedure pop_list_sorted(variable location, variable array) begin
   value:=get_array(array, location);
   counter:=location;
   while counter < len_array(array)-1 do begin
      array[counter]:=get_array(array, counter+1);
      counter+=1;
   end
   resize_array(array, len_array(array)-1);
   return value;
end

edit: here's another one:

Code: 
#define add_to_end_of_list(value, array)         \
   resize_array(array, len_array(array)+1);      \
   set_array(array, len_array(array)-1, value);
 
Last edited:
A couple of suggestions:
1) STOP using function-like macros, use procedures instead! If you want inlining for some purist reasons, add inline keyword to procedure definition and use sslc optimization.
2) Check out SSL library in my signature, it already contains a lot of functions to work with arrays and more.
3) "add to end of list" is usually called "push"
 
Ok, here they are as I added them to lib.arrays.h should some mysterious future modder need it :P

Code: 
// push new item at the end of array, no return value
procedure array_push_no_return(variable array, variable item) begin
   variable n;
   n := len_array(array);
   resize_array(array, n + 1);
   set_array(array, n, item);
end


// pop item from list at location
procedure pop_list_unsorted(variable location, variable array) begin
   value:=get_array(array, location);
   array[location]:=get_array(array, len_array(array)-1);
   resize_array(array, len_array(array)-1);
   return value;
end


// pop item from list at location, keep order
procedure pop_list_sorted(variable location, variable array) begin
   value:=get_array(array, location);
   counter:=location;
   while counter < len_array(array)-1 do begin
      array[counter]:=get_array(array, counter+1);
      counter+=1;
   end
   resize_array(array, len_array(array)-1);
   return value;
end




//remove item from list at location
procedure remove_list_unsorted(variable location, variable array) begin
   array[location]:=get_array(array, len_array(array)-1);
   resize_array(array, len_array(array)-1);
end


//remove item from list at location, keeping order
procedure remove_list_sorted(variable location, variable array) begin
   counter:=location;
   while counter < len_array(array)-1 do begin
      array[counter]:=get_array(array, counter+1);
      counter+=1;
   end
   resize_array(array, len_array(array)-1);
end
 
Code: 
#define item_obj_active_hand(x)  (critter_inven_obj(x, INVEN_TYPE_LEFT_HAND)+critter_inven_obj(x, INVEN_TYPE_RIGHT_HAND))


   variable weapon_obj_active_hand := item_obj_active_hand(dude_obj) if (item_obj_active_hand(dude_obj)>0 and obj_item_subtype(item_obj_active_hand(dude_obj)) == item_type_weapon) else 0;
    variable item_pid_active_hand := obj_pid(item_obj_active_hand(dude_obj)) if (item_obj_active_hand(dude_obj) > 0) else 0;
    variable weapon_pid_active_hand := obj_pid(item_obj_active_hand(dude_obj)) if (item_obj_active_hand(dude_obj)>0 and obj_item_subtype(item_obj_active_hand(dude_obj)) == item_type_weapon) else 0;

This is what I think is the most economic way for finding the pid or object of the item/weapon someone (in this case dude_obj) is carrying in their active hand. You're going to need this a lot when modding combat-related mechanics (except if the hook is something that already includes the weapon, say combatdamage). Given that you need it a lot, you need to get around the problem of obj_pid(0) crashing the script, which this does (or rather should do).

edit: also, some defines for getting a weapon pid's main attack and secondary attack mode

Code: 
   #define MainAttack(pid)   (((get_proto_data(pid, 24) bwand 0x000000FF) bwand 0xF0) / 16)
   #define SecondaryAttack(pid)        (((get_proto_data(pid, 24) bwand 0x000000FF) bwand 0x0F))
 
Last edited:
Still using complex function-like macros instead of simpler procedures, eh? :)

About active hand stuff - note that there are no such thing as an active hand for a critter. It's just a UI thing for a player character. All NPCs always use right hand slot.
Your item_obj_active_hand(x) itslelf is strange. What would happen if both hand slots will contain objects?

To get active hand slot of player character there is an active_hand sfall scripting function.
 
Still using complex function-like macros instead of simpler procedures, eh? :smile:
Click to expand...

I'm a simple man with an unhealthy fobia for procedures :oops:

Your item_obj_active_hand(x) itslelf is strange. What would happen if both hand slots will contain objects?
Click to expand...

Given that the engine only checks for the active hand and automatically returns 0 for the off-hand even if it contains something, left hand + right hand should always return what is in the active hand, right?
 
The engine checks for an active hand for dude_obj only. Other critters can theoretically have both hands used. Even if it might work for your tests, you shouldn't rely on such logic. Instead you can just check if it's a dude_obj and use slot depending on active hand and if it's another critter - just always assume right hand. And remember that the game doesn't track active hand for critters.

Also, instead of + operator in such cases I recommend using or in conjunction with short-circuit evaluation in latest sslc. In that case you won't risk using an invalid object pointer.
 
phobos2077 said:
The engine checks for an active hand for dude_obj only. Other critters can theoretically have both hands used. Even if it might work for your tests, you shouldn't rely on such logic. Instead you can just check if it's a dude_obj and use slot depending on active hand and if it's another critter - just always assume right hand. And remember that the game doesn't track active hand for critters.
Click to expand...

Without knowing too much about it in depth, my guess has always been that for all intents and purposes there is only one hand in the engine, and that for the dude the engine uses a bit of sleight of hand to convince you that what is in practice just another slot in your inventory is actually your off-hand. I simply cannot conceive of the possibility that if it's impossible to tell what is carried in the off-hand for the dude, it would be possible for an npc: just look at some of their inventories, they already use their off hands as extra inventory slots in practice (stuffing ammo clips in there, etc.). I suppose I could be ultra-safe like you suggest, but you can tell from some of the scripts (such as checking for whether the dude is unarmed) that the scripters were annoyed they couldn't tell what was in the off-hand; I just can't conceive of them making this possible only for npc's, but maybe I'm thinking about this totally wrong.

I know that safety is best, but I like economy too ;)
 
Because of how annoying it is that you can't tell which team is fighting which, I decided to make a little something that should accomplish this:

Code: 
procedure setup_hostility(variable target, variable attacker) begin
   if len_array(get_array(hostile_teams_array, team(attacker))) == -1 then begin
      hostile_teams_array[team(attacker)]:=create_array(0,0);
   end if len_array(get_array(hostile_teams_array, team(target))) == -1 then begin
      hostile_teams_array[team(target)]:=create_array(0,0);
   end if not is_in_array(team(target), get_array(hostile_teams_array, team(attacker))) then begin
      call array_push_no_return(get_array(hostile_teams_array, team(attacker)), team(target));
      call array_push_no_return(get_array(hostile_teams_array, team(target)), team(attacker));
   end
   debug_msg("hostile: " + debug_array_str(hostile_teams_array));
end


procedure tohit begin
   variable hitchance:=get_sfall_arg;
   variable attacker:=get_sfall_arg;
   variable target:=get_sfall_arg;
   if attacker!=dude_obj then begin    //dude is only one who doesn't have to aim with intent 
      call setup_hostility(target, attacker);
   end
end
procedure combatdamage begin
   variable target := get_sfall_arg;
   variable attacker := get_sfall_arg;
   if target!=afterhitroll_target then begin // in case the target is hit coincidentally or mistakenly, hostility is also initiated
      if not is_in_array(team(target), hostile_teams_array) then     //mistaken target is not yet part of combat, so let him be pacifist
         call array_push_no_return(critter_stop, target);
      else
         call setup_hostility(target, attacker);
   end
end
procedure afterhitroll begin
    variable hit:=get_sfall_arg;
    variable attacker:=get_sfall_arg;
    variable target:=get_sfall_arg;
    if attacker == dude_obj then begin
      call setup_hostility(target, attacker);
    end
    afterhitroll_target:=target;
end


procedure start begin
   variable critter;
   if game_loaded then begin
      register_hook_proc(HOOK_TOHIT, tohit);
      register_hook_proc(HOOK_COMBATDAMAGE, combatdamage);
      register_hook_proc(HOOK_AFTERHITROLL, afterhitroll);
      set_global_script_type(1);
      set_global_script_repeat(100);
      critter_stop:=create_array(0,0);
      hostile_teams_array := create_array_map;
   end else begin
      if len_array(hostile_teams_array) > 0 and not combat_is_initialized then begin
         resize_array(hostile_teams_array,0);
      end
      if len_array(critter_stop) > 0 then begin
         foreach critter in critter_stop begin
            critter_stop_attacking(critter);
         end
         resize_array(critter_stop,0);
      end
   end
end

What you get as a result is a map array with each team engaged in hostilities as keys, and a list of the teams they are engaged with as the value. The only way (I think) it isn't foolproof, is that if you were to tell someone to attack another critter via script during combat, they'd only be registered as combatants once their turn arrives and they target their opponent.

Now, what I've added to this script already is one possible application of this script, namely in causing accidental targets not to automatically engage. Tired of every prostitute in new reno attacking you with knives once you accidentally scrape one of them while fighting bouncers? This script should do that.

One final note: for the debugging to work properly, you should probably override @phobos2077's array debugging procedure with mine, given that his doesn't allow for stringifying associative arrays:

Code: 
procedure debug_array_str(variable arr) begin
   variable i := 0, k, s, len;
   len := len_array(arr);
   if (array_is_map(arr)) then begin  // print assoc array
      s := "{";
      while i < len do begin
         k := array_key(arr, i);
         if len_array(get_array(arr, k)) == -1 then
            s += k + ": "+ get_array(arr, k);
         else
            s += k + ": "+ debug_array_str(get_array(arr, k));
         if i < (len - 1) then s += ", ";
         i++;
      end
      if (strlen(s) > 254) then s := substr(s, 0, 251) + "...";
      s += "}";
   end else begin  // print list
      s := "[";
      while i < len do begin
         if len_array(arr[i]) == -1 then
            s += arr[i];
         else
            s += debug_array_str(arr[i]);
         if i < (len - 1) then s += ", ";
         i++;
      end
      if (strlen(s) > 254) then s := substr(s, 0, 251) + "...";
      s += "]";
   end
   return s;
end

An example of the information you get is, suppose you attack someone with team #11 with a grenade, and someone with team #9 gets caught in the blast. Then without my "mod" causing them to abstain from combat, you get this:

Code: 
hostile: {0: [11], 11: [0]}
hostile: {0: [11, 9], 11: [0], 9: [0]}

First the actual target of the attack goes hostile (team 11 becomes hostile to the player team, 0, and vice versa), then the accidental target becomes hostile (teams 11 and 9 are hostile to the player). With my mod, the second event doesn't happen.
 
That's strange, my debug_array_str worked perfectly with assoc arrays. Maybe you meant nested arrays? I see you have added recursion.
 
phobos2077 said:
That's strange, my debug_array_str worked perfectly with assoc arrays. Maybe you meant nested arrays? I see you have added recursion.
Click to expand...

Yeah, that's what I meant, um, I think. Is recursion potentially a problem? It worked out fine in my testing, but I'm not sure (I assume by recursion is meant calling the the same procedure within the procedure).
 
I made something to make randomized critter placement (e.g. in caravans) safer to use. The main reason why caravan maps are always so dull, is that the script doesn't have access to all the random encounter tables with their meticulous tile locations for enemy groups. Without this data, placing a critter at a certain distance from the caravan could mean having him stick out of the side of a mountain. To partially solve this issue, I've made this:

Code: 
              counter:=100;     //the higher you makes this, the less likely a failure becomes, but the more calculating power it takes
              while counter > 0 do begin
                 dist:=fibonacci_random(18, 20);     //(min_dist, max_dist)
                 //the reason we can't use a regular random int is that we want the max distance of 10 to occur 10 times as often as a min distance of 1
                 //this is because there are ten times more hexes available at that distance (60) than at 1 hex distance (6).
                 direction:=random(0,5);
                 first_step:=tile_num_in_direction(dude_tile, direction, dist);
                 tile:=tile_num_in_direction(first_step, (direction + 2)%6, random(1, dist));
                 if len_array(path_find_to(dude_obj, tile, 0)) > 0 then begin   //this is far from perfect: if someone is standing in a door opening, or a door is closed, everything inside is treated as "blocked"
                    //this is why you can really only use this in random encounters more or less reliably.
                    debug_msg(debug_array_str(path_find_to(dude_obj, tile, 0)));
                    create_object(PID_PRIMITIVE_VILLAGER_MALE, tile, dude_elevation);
                    //counter:=0;     //for this example we don't want just one placement, but a whole lot.
                 end else begin
                    counter-=1;
                 end
              end

        

procedure fibonacci_random(variable min, variable max) begin
   variable counter,fib_max,value,fib_counter,outcome;
   counter:=max;
   fib_max:=0;
   while counter >= min do begin
      fib_max+=counter;
      counter-=1;
   end
   value:=random(1, fib_max);
   counter:=max;
   while counter >= min do begin
      fib_max-=counter;
      if value > fib_max then begin
         outcome:=counter;
           counter:=0;
      end else begin
         counter-=1;
      end
   end
   debug_msg("outcome" + outcome);
   return outcome;
end

The result of this example in a mountain random encounter map is this:

5aiFsw0.png


The point of this example isn't to show the amount of successes before a failure (clogging up tiles with critters has raised the failure rate steadily; tho the chance of failure will of course never become zero even without such clogging), but that you'll never get an "unsafe" critter placement.

The biggest problem with it, as I say in the script, is that it doesn't handle closed doors very well: it'll treat a closed off house as being inaccessible and thus that no critters should be placed there. The reason for this is that before it makes a placement it checks whether the dude can potentially find a path to walk to that critter upon placement.

edit: hmm then again maybe doors are not seen as blocking... would make sense I suppose, should've tested it first :P

The second "innovation" of the script is that it lets you spread out randomized critter placements properly: putting a critter at 18-20 distance gives an equal chance of putting him at any of the hexes at that distance, rather than just those in one of the 6 cardinal directions.
 
Last edited:
Great stuff! I planned to make random encounters more interesting for my mod, was thinking of doing something with critter placement too.
Don't bother so much about doors though, as there aren't many in random encounter maps... Hey, here's an idea: you can iterate over all doors (list_as_array(LIST_SCENERY)) and temporarily open them (obj_open), then make your path finding calculations, then revert them to default state.
 
An addendum to my last post: suppose you don't want to place critters just at a certain distance from the player, but within a specific area (say, a building). There's always been a function for checking within an area (tile_in_tile_rect), but not for giving an actual list of possible positions within an area (I think). I've made a small script that makes this possible. In the example, you set the 4 "corners" (as leather armors) with the first four J-key strokes, and then build the possible locations with the 5th (as 10mm pistols). Now, I say "corners, because tile_in_tile_rect doesn't work as drawing a shape from your four corners. As it says, it draws a rectangle in hex geometry. It builds this rectangle from the upper left and lower right corners, with the other two corners serving only one purpose (afaik), namely to limit the width of the rectangle based on their distance from each other:

Code: 
procedure keypress begin
   variable type,key_dx ,key_vk,min,max,tile;
      type:=get_sfall_arg;   //event type: 1 - pressed, 0 - released
      key_dx:=get_sfall_arg;   //key DX scancode
      key_vk:=get_sfall_arg;   //key VK code (very similar to ASCII codes)
   if type == 1 then begin
      if key_dx == (J_key) then begin
         if corner_counter < 4 then begin
            corner_array[corner_counter]:=tile_under_cursor;
            corner_counter+=1;
            create_object(PID_LEATHER_ARMOR, tile_under_cursor, dude_elevation);
            display_msg(debug_array_str(corner_array));
         end else begin
            min:=array_min(corner_array);
            max:=array_max(corner_array);
            tile:=min;
            while tile < max do begin
               if tile_in_tile_rect(corner_array[0], corner_array[1], corner_array[2], corner_array[3], tile) then      //upper left, upper right, lower left, lower right, tile
                  create_object(PID_10MM_PISTOL, tile, dude_elevation);
               tile+=1;
            end
         end
      end
   end
end

First an example without limiting the width (actually I did limit it a bit by accident I just noticed, heh):

P2itUXa.png


Next an example with limiting:

xGezugW.png


as you can see, it doesn't matter in the slightest where on the map you put the upper right and lower left corners, all that matters is their distance from each other (in this case 6 hexes) which limits the width of the rectangle drawn.

So anyone trying to use tile_in_rect_tile in an unconventional way, keep this in mind.
 
You must log in or register to reply here.
Back
Top