BGforgeNet/Fallout2_Restoration_Project

Script: scripts\wcsecbot.int ERROR: attempt to reference map var out of range: 133.

Closed this issue ยท 6 comments

What happened

This message is spamming the console. Seems like the headers reference invalid map var index or the number of map vars in map file is incorrect.

Script: scripts\wcsecbot.int ERROR: attempt to reference map var out of range: 133.

What you expected to happen

Screenshot

Savegame

The cause should be sierra_cur_level_sec_on macro that wcsecbot and wcbrnbot keep calling in their critter_p_proc:
https://github.com/BGforgeNet/Fallout2_Restoration_Project/blob/master/scripts_src/headers/depolvz.h#L55

This is one of the cases where short circuiting would help.
Not sure where to fix it or just leave and wait until short circuit is enabled.

Maybe change the macro to a procedure? Not exactly pretty but it should work for current build setup?

procedure sierra_cur_level_sec_on begin
   if (cur_map_index == MAP_SIERRA_123) then begin
      if ((self_elevation == LEVEL_ONE and map_var(MVAR_Security_Level_1) == 1) or
          (self_elevation == LEVEL_TWO and map_var(MVAR_Security_Level_2) == 1) or
          (self_elevation == LEVEL_THREE and map_var(MVAR_Security_Level_3) == 1)) then begin
         return true;
      end
   end else if (cur_map_index == MAP_SIERRA_4) then begin
      if (map_var(MVAR_Security_Level_4) == 1) then return true;
   end
   return false;
end

This is one of the cases where short circuiting would help.

Or you can use Stalin's andAlso operator. But I consider it a hack. I don't really know of any downsides to enabling SCE globally, except for a rare case or two where some expression would have side effects. But I can't think of any example like this in FO2 scripts. If anything, it prevents bugs like this.

Well, regardless of short circuiting, procedures are just better code than multi-line defines. Maybe a bit more overhead, but I don't think we're hitting engine limits any time soon.
So it's likely worth changing to a procedure either way.

I agree, procedures are better. The only minor "downside" is that if there are thousands of procedures in common header that are used for just a few scripts, they get processed by compiler every time and need to be cut by optimizer at the last moment. I guess preprocessor does something similar but with less computation involved.