## At a bit of a loss regarding smart terrain logic

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### At a bit of a loss regarding smart terrain logic

Hey. So recently, I've been getting a few reports of a crash regarding a patrol path in agroprom at agr_smart_terrain_1_6. The issue stops people from loading their quicksaves, but the weird thing is: if you exit to windows, then relaunch coc and load the save, it'll load.

Here is the crash:

Code: Select all

ERROR: xr_logic.configure_schemes: object 'sim_default_military_218884': unable to find section 'logic@agr_smart_terrain_1_6_patrol_2_walk' in '*agr_smart_terrain_1_6' gulag_name=agr_smart_terrain_1_6object 'sim_default_military_218884': activate_by_section: section 'patrol@agr_smart_terrain_1_6_patrol_2_walk' does not exist! [SCRIPT ERROR]: ...er call of pripyat coc\gamedata\scripts\xr_patrol.script:565: attempt to concatenate field 'patrol_key' (a nil value)FATAL ERROR[error]Expression : fatal error[error]Function : CScriptEngine::lua_error[error]File : ..\xrServerEntities\script_engine.cpp[error]Line : 193[error]Description : <no expression>[error]Arguments : LUA error: ...er call of pripyat coc\gamedata\scripts\xr_patrol.script:565: attempt to concatenate field 'patrol_key' (a nil value)stack trace:0023:0099717F xrCore.dll, xrDebug::fatal()0023:0664147A xrGame.dll, CDialogHolder::IgnorePause()

I've tried comparing vanilla smart terrain logic and my own mods but to no avail. For reference, here is my agr_smart_terrain_1_6_smart_logic.ltx file:

Code: Select all

;minigunner[logic@agr_smart_terrain_1_6_minigunner_excl]active = beh@agr_smart_terrain_1_6_minigunner_exclsuitable = {!surge_started} trueprior = 60[meet@general]close_anim       = nilclose_victim    = nilfar_anim       = nilfar_victim       = nilclose_distance  = 0far_distance    = 0use = {=actor_enemy} false, {=dist_to_actor_le(3)} true, falsesnd_on_use = {!dist_to_actor_le(3)} nilmeet_on_talking = false[beh@general]sound_idle = statebehavior_state = beh_movetarget = waypointwalk_dist = 100jog_dist = 220wait_anim = rushwalk_anim = rushjog_anim = rushrun_anim = rushdelay_anim = guardgather_items_enabled = falsehelp_wounded_enabled = falsecorpse_detection_enabled = falsemeet = meet@general[beh@idle]:beh@generalon_info = {!has_enemy} beh@agr_smart_terrain_1_6_minigunner_excl[beh@agr_smart_terrain_1_6_minigunner_excl]:beh@generalpt1 = 1000,guard | pos:-105.93,7.39,-152.20 look:-60.24,1.23,-159.31path_end = beh@agr_smart_terrain_1_6_minigunner_excl_ready[beh@agr_smart_terrain_1_6_minigunner_excl_ready]:beh@generalno_combat_job = truept1 = 20000,ward | pos:-105.93,7.39,-152.20 look:-60.24,1.23,-159.31path_end = loopon_info = {=pure_enemy_dist_le(20)} beh@idle;camping[logic@agr_smart_terrain_1_6_camp_work_1]active = animpoint@agr_smart_terrain_1_6_camp_work_1suitable = {=is_night !surge_started} trueprior = 45[logic@agr_smart_terrain_1_6_camp_work_2]active = animpoint@agr_smart_terrain_1_6_camp_work_2suitable = {=is_night !surge_started} trueprior = 45[logic@agr_smart_terrain_1_6_camp_work_3]active = animpoint@agr_smart_terrain_1_6_camp_work_3suitable = {=is_night !surge_started} trueprior = 45[logic@agr_smart_terrain_1_6_camp_work_4]active = animpoint@agr_smart_terrain_1_6_camp_work_4suitable = {=is_night !surge_started} trueprior = 45[logic@agr_smart_terrain_1_6_camp_work_5]active = animpoint@agr_smart_terrain_1_6_camp_work_5suitable = {=is_night !surge_started} trueprior = 45[animpoint@agr_smart_terrain_1_6_camp_work_1]cover_name = agr_smart_terrain_1_6_animpoint_kamp1use_camp = trueturn_on_campfire = true[animpoint@agr_smart_terrain_1_6_camp_work_2]cover_name = agr_smart_terrain_1_6_animpoint_kamp2use_camp = trueturn_on_campfire = true[animpoint@agr_smart_terrain_1_6_camp_work_3]cover_name = agr_smart_terrain_1_6_animpoint_kamp3use_camp = trueturn_on_campfire = true[animpoint@agr_smart_terrain_1_6_camp_work_4]cover_name = agr_smart_terrain_1_6_animpoint_kamp4use_camp = trueturn_on_campfire = true[animpoint@agr_smart_terrain_1_6_camp_work_5]cover_name = agr_smart_terrain_1_6_animpoint_kamp5use_camp = trueturn_on_campfire = true;army trader[logic@agr_smart_terrain_1_6_army_trader]suitable = {=check_npc_name(agr_smart_terrain_1_6_army_trader_stalker)} true, {=check_npc_name(sim_default_army_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;freedom trader[logic@faction_controlled_freedom_trader]suitable = {=check_npc_name(sim_default_freedom_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;bandit trader [logic@faction_controlled_bandit_trader]suitable = {=check_npc_name(sim_default_bandit_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;duty trader [logic@faction_controlled_dolg_trader]suitable = {=check_npc_name(sim_default_dolg_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;monolith trader [logic@faction_controlled_monolith_trader]suitable = {=check_npc_name(sim_default_monolith_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;stalker trader[logic@faction_controlled_stalker_trader]suitable = {=check_npc_name(sim_default_stalker_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;ecologist trader [logic@faction_controlled_ecolog_trader]suitable = {=check_npc_name(sim_default_ecolog_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;clear sky trader[logic@faction_controlled_csky_trader]suitable = {=check_npc_name(sim_default_csky_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true;merc trader[logic@faction_controlled_killer_trader]suitable = {=check_npc_name(sim_default_killer_trader)} trueprior = 200active = animpoint@tradelevel_spot = tradertrade = misc\trade\trade_military.ltxcan_select_weapon = falsedont_keep_items = true[animpoint@trade]cover_name = agr_smart_terrain_1_6_smart_cover_traderreach_movement = walk_noweapavail_animations = jup_b41_novikov_standreach_distance = 10combat_ignore_cond = {=actor_enemy =check_enemy_name(actor)} false, truecombat_ignore_keep_when_attacked = truegather_items_enabled = falsehelp_wounded_enabled = falsecorpse_detection_enabled = falseinvulnerable = {!actor_enemy} true, falsemeet = meet@trade[meet@trade]close_anim       = nilclose_victim    = nilfar_anim       = nilfar_victim       = nilclose_distance  = 0far_distance    = 0close_snd_distance = 3use = {=actor_enemy} false, true;army mechanic[logic@agr_smart_terrain_1_6_army_mechanic]suitable = {=check_npc_name(agr_smart_terrain_1_6_army_mechanic_stalker)} true, {=check_npc_name(sim_default_army_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;freedom mechanic[logic@faction_controlled_freedom_mechanic]suitable = {=check_npc_name(mil_smart_terrain_7_7_freedom_mechanic_stalker)} true, {=check_npc_name(sim_default_freedom_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;bandit mechanic [logic@faction_controlled_bandit_mechanic]suitable = {=check_npc_name(sim_default_bandit_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;duty mechanic [logic@faction_controlled_dolg_mechanic]suitable = {=check_npc_name(sim_default_dolg_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;monolith mechanic [logic@faction_controlled_monolith_mechanic]suitable = {=check_npc_name(sim_default_monolith_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;stalker mechanic[logic@faction_controlled_stalker_mechanic]suitable = {=check_npc_name(sim_default_stalker_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;ecologist mechanic [logic@faction_controlled_ecolog_mechanic]suitable = {=check_npc_name(sim_default_ecolog_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;clear sky mechanic[logic@faction_controlled_csky_mechanic]suitable = {=check_npc_name(sim_default_csky_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false;merc mechanic[logic@faction_controlled_killer_mechanic]suitable = {=check_npc_name(sim_default_killer_mechanic)} trueprior = 200active = animpoint@standlevel_spot = mechaniccan_select_weapon = false[animpoint@stand]cover_name = agr_smart_terrain_1_6_smart_cover_mechanicavail_animations = jup_b41_novikov_standuse_camp = falsemeet = meet@mechaniccombat_ignore_cond = {=actor_enemy =check_enemy_name(actor)} false, truecombat_ignore_keep_when_attacked = trueinvulnerable = {!actor_enemy} true, falsereach_distance = 10gather_items_enabled = falsehelp_wounded_enabled = falsecorpse_detection_enabled = false[meet@mechanic]close_anim       = nilclose_victim    = nilfar_anim       = nilfar_victim       = nilclose_distance  = 0far_distance    = 0close_snd_distance = 3use = {=actor_enemy} false, true

Any ideas on why it can't find logic@agr_smart_terrain_1_6_patrol_2_walk? Looks like it should be being created in gulag_general.script if I'm not mistaken.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

What is your mod and what does it do? Does it change anything with smart_terrain.script? Are you the warfare guy?

If the job section actually exists then it looks like NPCs is activating it's job via smart_terrain.setup_gulag_and_logic_on_spawn in xr_motivator.net_spawn before the smart terrain calls load_jobs.

So it's either that or there is truly no such thing as path agr_smart_terrain_1_6_patrol_2_walk. Do you increase max squad count above 3? There could be an unknown error I'm not aware of with jobs for squads with more then 3 members. I will look at patrol code.

EDIT:

No, it's correct but if you increase squad count then job_count = 3 should be increased as well. Patrol jobs are the jobs where a squad follows a leader on a path.

That job definitely exists. For some reason the NPC is activating his job before it's loaded which shouldn't happen.

Possibility One:

There could be a silent script error in smart_terrain.script if it was modified which could lead to the script breaking without any warning. I've experienced this before with other scripts. It's because lua is on it's own thread (yes, cop is multi-threaded) and some errors can cause the thread to break and the game will still run. It leads to some pretty crazy and impossible to debug errors and is the cause of the infamous C-Stack Overflow in vanilla COP. The best way to detect if this is happening is to watch the update method with a print line. If it isn't printing the line then that instance of the smart_terrain class is broken silently; completely lost in the void. Not sure why or how it happens, most likely stack corruption.

In plainer terms, what should happen:
smart terrain does before register
smart terrain does register
smart terrain does update on interval
npc is in switch distance so it comes online, calling net spawn and activates logic

So between the Smart registering and updating that instance of the class is deleted due to an error.
When npc calls smart_terrain.setup_gulag_and_logic_on_spawn (where configure schemes is triggered) it can't find it's job because it was never created as load_jobs never fired off. Theoretically it's impossible for a npc to come online and not have logic in the dynamic ltx by gulag general unless there is some strange voodoo going on.

The only solution here is to thoroughly and slowly go through each line of code in smart_terrain.script and make sure there isn't anything that can lead to an error, specifically an engine error, like something crazy like alife():object(nil) or npc:position():distance_to(nil) or passing a string instead of a number or visa versa. Lua syntax or lua specific errors won't cause such a problem. How I solved the C Stack overflow issue with COP is because in vanilla script sometimes rarely best_weapon would be nil in state_manager_weapon.script and would do this: self.object:is_weapon_going_to_be_strapped(nil). Completely undetectable without lua logging enabled by -dbg in which case it would warn you that state_mgr_weapon evaluate was returning nil. If this kind of error wasn't in an evaluator there would be no warning at all! Very nasty to debug.

Possibility Two:

This is a red herring and the real problem is the NPC isn't even on agroprom and is trying to load a job on another level. This could happen if NPC is teleported via script and it's logic is not removed. If you suspect this, then check axr_logic.script on how to go about clearing these before teleporting a squad.
"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

Yeah I'm the warfare guy.

Yeah I checked for the patrol path agr_smart_terrain_1_6_patrol_2_walk in the agroprom way file and it was there. I don't personally use larger squad numbers, and I have been tempted to remove it as it does lead to some odd npc behavior (though apparently people use it somewhat frequently even though you could configure my mod to pump out more squads instead of having larger squads), but nothing like this before.

It could be an error in smart_terrain.script. I know I had isolated an issue that was likely what you're talking about a couple days ago using a bunch of print statements throughout my code, where the smart terrain was silently broken. That was related to how I calculate squad power (same way they do in Clear Sky, using each squad members rank; probably due to me calling alife():object possibly with a nil member id). I fixed the portion that caused that to break though and haven't had reports of updates ceasing since.

I don't teleport any squads, so I suspect that the first possibility is the culprit. I do modify smart_terrain.script a good amount in my mod. I'm going to go and compare the smart_terrain.script from a version of my mod before people were experiencing this issue, hopefully that should lead me to find what is causing it. Hopefully its something as simple as passing a nil value into a function like distance_to_sqr or alife():object().

Edit: So I put in a print statement within the laod_jobs() method and am getting this error relating to gulag_general:

Code: Select all

agr_smart_terrain_1_6 load_jobs()agr_smart_terrain_1_6_near_1 load_jobs()agr_smart_terrain_1_6_near_2 load_jobs()gulag_general.add_exclusive_job(): Invalid job_type! job_type = nil scheme = nilgulag_general.add_exclusive_job(): Invalid job_type! job_type = nil scheme = nilgulag_general.add_exclusive_job(): Invalid job_type! job_type = nil scheme = nilgulag_general.add_exclusive_job(): Invalid job_type! job_type = nil scheme = nil

and that was before this crash with a stack traceback popped up:

Code: Select all

ERROR: xr_logic.configure_schemes: object 'sim_default_military_221089': unable to find section 'logic@agr_smart_terrain_1_6_sniper_1_walk' in '*agr_smart_terrain_1_6' gulag_name=agr_smart_terrain_1_6object 'sim_default_military_221089': activate_by_section: section 'camper@agr_smart_terrain_1_6_sniper_1_walk' does not existYou are trying to set 'path_look' equal to 'path_walk' in section [camper@agr_smart_terrain_1_6_sniper_1_walk] for npc [sim_default_military_221089] stack traceback:   ....e.r - call of pripyat\gamedata\scripts\xr_camper.script:547: in function 'set_scheme'   ...k.e.r - call of pripyat\gamedata\scripts\xr_logic.script:206: in function 'activate_by_section'   ...k.e.r - call of pripyat\gamedata\scripts\xr_logic.script:1334: in function 'initialize_obj'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:2590: in function 'setup_gulag_and_logic_on_spawn'   ...r - call of pripyat\gamedata\scripts\xr_motivator.script:153: in function <...r - call of pripyat\gamedata\scripts\xr_motivator.script:44>   [C]: in function 'section_exist'   ....l.k.e.r - call of pripyat\gamedata\scripts\utils.script:168: in function 'cfg_get_string'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:229: in function 'read_params'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:1016: in function <... - call of pripyat\gamedata\scripts\smart_terrain.script:1012>   [C]: in function 'section_exist'   ...   ... - call of pripyat\gamedata\scripts\smart_terrain.script:229: in function 'read_params'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:1016: in function <... - call of pripyat\gamedata\scripts\smart_terrain.script:1012>   [C]: in function 'section_exist'   ....l.k.e.r - call of pripyat\gamedata\scripts\utils.script:168: in function 'cfg_get_string'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:229: in function 'read_params'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:1016: in function <... - call of pripyat\gamedata\scripts\smart_terrain.script:1012>   [C]: in function 'section_exist'   ....l.k.e.r - call of pripyat\gamedata\scripts\utils.script:168: in function 'cfg_get_string'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:229: in function 'read_params'   ... - call of pripyat\gamedata\scripts\smart_terrain.script:1016: in function <... - call of pripyat\gamedata\scripts\smart_terrain.script:1012>

Not sure if those exclusive jobs would be the issue though as they print out after the load_jobs() calls from what I can tell.

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

Alright, so at this point I'm starting to think there is something wrong somewhere in the smart terrains files, because I renamed my gamedata\configs\scripts\agroprom folder to agroprom_ and it works fine. Haven't had the crash recently even though it was relatively common previously, took over agroprom with some pretty long gun fights and quicksaved and reloaded plenty, yet no crash in areas that were prone to it. Been trying to reproduce the crash to no avail. Gonna keep looking at the agroprom files and see if any typos were made or anything.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

Here is agr_smart_terrain_1_6.ltx - http://pastebin.com/31g4hcwa

And here is agr_smart_terrain_1_6_smart_logic.ltx - http://pastebin.com/CJuVSPtE

Had done another run through in agroprom and wasn't getting the crash. Maybe I was just getting lucky though.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

Yes, after reading some comments it's more likely that Possiblity One is happening

1. http://imgur.com/IDLnW2P
2.

Code: Select all

ERROR: xr_logic.configure_schemes: object 'sim_default_duty_119071': unable to find section 'logic@bar_dolg_general_patrol_2_walk' in '*bar_dolg_general' gulag_name=bar_dolg_generalobject 'sim_default_duty_119071': activate_by_section: section 'patrol@bar_dolg_general_patrol_2_walk' does not exist! [LUA] SCRIPT RUNTIME ERROR! [LUA] ...ne - call of chernobyl\gamedata\scripts\xr_patrol.script:565: attempt to concatenate field 'patrol_key' (a nil value)! [SCRIPT ERROR]: ...ne - call of chernobyl\gamedata\scripts\xr_patrol.script:565: attempt to concatenate field 'patrol_key' (a nil value)FATAL ERROR[error]Expression : fatal error[error]Function : CScriptEngine::lua_error[error]File : ..\xrServerEntities\script_engine.cpp[error]Line : 193[error]Description : <no expression>[error]Arguments : LUA error: ...ne - call of chernobyl\gamedata\scripts\xr_patrol.script:565: attempt to concatenate field 'patrol_key' (a nil value)

So this is happening even on bar. Need to get a reproducible save from someone with this issue.
"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

I'm going to have to work on trying to reproduce the crash. I added in checks to be sure that no nil value was being passed into distance_to_sqr or alife():object and haven't had a crash in a while so maybe that was the culprit. Going to try to reproduce it some more after I return home from work.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

I'm going to test a hand merge of 1.2.33 with 0.6.3 warfare. I noticed some things missing that might cause problems, like the change to heli hide jobs. I also did some minor sanity on some things

Here is the branch https://bitbucket.org/revo_lucas/call-o ... ch/warfare
"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

Cool, sounds good. Thanks for taking a look.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

! ERROR on rejecting: entity not found. parent_id = [0], entity_id = [42004], frame = [1371].
! WARNING: SV: can't find children [19787] of parent [280937744]
! auto-generated bump map: wpn\wpn_val_bump#
### PRE UPDATE ###
CREATED simulation_zombie AT mar_smart_terrain_6_10
CREATED simulation_tushkano AT esc_smart_terrain_2_14
CREATED simulation_cat AT ros_smart_monster5
CREATED simulation_chimera AT mil_smart_terrain_4_7
CREATED simulation_zombie AT lim_smart_terrain_7
### POST UPDATE ###
stack trace:

! ERROR on rejecting: entity not found. parent_id = [0], entity_id = [42004], frame = [1371].

Long ago CoC had this issue when we had tons of alife (Which the alife unbalance addon re-implements). I'm wondering if Warfare is pushing the limits of engine. Look at that ID number 42k, that is pretty high. There can only be 65534 IDs and I'm not sure if you can even have 65k objects because there is a hard limit on the NET packet size. This player's game has at the very least 42k objects.

Switching USE_MARSHAL for smart_terrain.script (Will only work with the re-merge because it was missing some fixes) could help keep the packet size down as it forces all the smart terrains to save to .scoc instead of the NET packet. SIM_PASSIVE_SQUAD_COUNT would help but it might mess up some of the features.
"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

Yeah I had implemented your passive squad count. It worked for the most part, but even after removing the distance check from the if statement there still were around 1 to 2 NPCs max. But thats probably something that is easily fixable, I didn't read through the code very much.

I've been getting reports of that kind of thing pretty frequently, the blank stack trace crashes. I'm going to download your merge to work with and reimplement the passive squad count. I haven't been getting the crashes myself frequently, but I haven't actually played much of warfare, mainly just worked on it.

One thing I'm also considering is revamping my level expansion targets. It looks at which level the faction is invading from and will use an expansion set based on that, so if invading Marshes from Agroprom you'd take the upper smart terrains first and move downward. Doing this I could limit active squad count pretty well by just having two or maybe three active targets, and would allow for a bit more customization for people. Removed its implementation at one point but I think I'm going to begin working on it now.

And by the way, with the smart logic related crash in Agroprom, I tested it some more and the only times I get the crash is when the smart logic for faction traders and mechanics is being used. I'm not sure if maybe the traders / mechanics taking jobs causes the issue on those levels? I'm going to try debugging that some more, hopefully make some progress on that.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

merged dev_build into the warfare branch for version 1.2.35

The SIM_PASSIVE_SQUAD_COUNT problem should be fixed.
"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."

carperbr
Scavenger
Posts: 27
Joined: 15 Oct 2015, 00:44

### Re: At a bit of a loss regarding smart terrain logic

Cool, I'll merge it in with my own stuff; I am running 1.2.35 currently via the manual patch and its working fine but I'll compare files and see if there are any differences. I'm also about to make a 0.6.4 release. Haven't really looked into using bitbucket before, but I can see about merging the 0.6.4 code, that or you can after I release it.

So I still don't know why, but I did manage to fix the patrol issue. I did my own versions of the smart terrain files (originals were by someone else) and things are working well. I took a more minimalistic approach, editing only the jobs currently existing on the smart terrains and using a longer conditional for the suitable value. I got the error in Cordon regarding esc_smart_terrain_5_7 and couldn't load the quicksave I had made. After going in and redoing the smart terrain files for esc_smart_terrain_5_7 and editing the logic@esc_smart_terrain_5_7_loner_mechanic suitable value to include all of the custom sim squad mechanics, I was finally able to load the save without getting the patrol error.

Maybe there was a typo somewhere in there that got copied throughout the files. Another thing that I'm wondering is if adding 8 extra exclusive jobs for the various factions mechanics might overwhelm the smart terrain somehow? Either way, its working now and I was able to salve the afflicted save, so this issue seems solved now.

I think I've been able to solve a lot of the bugs, though I still get squads who pause movement in offline mode even when they have an assigned target id. I also made it so that whenever their update method is called, it increments a counter and then the counter is appended to the info string for the pda. This value never stops incrementing, so it seems the squads are updating but still not moving. Pretty weird, but its also relatively uncommon. I've had reports of this before, but not a whole lot. One thing I've considered is writing a little system to move squads around in offline mode using smart terrains as nodes and just calculating a path using A*. If I could position squads arbitrarily along a path via an interpolated value based on the target smart terrains position and current smart terrains position then I think it could work pretty well, and shouldn't have that much of a performance impact as a calculated path could be put inside of a table and then saved using the save calback. Maybe a bit overkill, but it would be fun to try at least.

Alundaio
S.T.A.L.K.E.R.
Posts: 1368
Joined: 26 May 2012, 22:26

### Re: At a bit of a loss regarding smart terrain logic

You need a fix for bar, not sure if it's in the merge but it's not in 1.2.35 patch

configs\scripts\bar\bar_zastava_2_minigun.ltx
configs\scripts\bar\bar_zastava_minigun.ltx

They are missing an equal sign before obj_on_job. It's possible it can cause issue but I don't know. But it's been an error in CoC for long time.
"I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self-evident; that all mods are created equal."