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

Postby carperbr » 21 Jan 2016, 09:38

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_6
object '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_excl
suitable = {!surge_started} true
prior = 60

[meet@general]
close_anim       = nil
close_victim    = nil
far_anim       = nil
far_victim       = nil
close_distance  = 0
far_distance    = 0
use = {=actor_enemy} false, {=dist_to_actor_le(3)} true, false
snd_on_use = {!dist_to_actor_le(3)} nil
meet_on_talking = false

[beh@general]
sound_idle = state
behavior_state = beh_move
target = waypoint
walk_dist = 100
jog_dist = 220
wait_anim = rush
walk_anim = rush
jog_anim = rush
run_anim = rush
delay_anim = guard
gather_items_enabled = false
help_wounded_enabled = false
corpse_detection_enabled = false
meet = meet@general

[beh@idle]:beh@general
on_info = {!has_enemy} beh@agr_smart_terrain_1_6_minigunner_excl

[beh@agr_smart_terrain_1_6_minigunner_excl]:beh@general
pt1 = 1000,guard | pos:-105.93,7.39,-152.20 look:-60.24,1.23,-159.31
path_end = beh@agr_smart_terrain_1_6_minigunner_excl_ready

[beh@agr_smart_terrain_1_6_minigunner_excl_ready]:beh@general
no_combat_job = true
pt1 = 20000,ward | pos:-105.93,7.39,-152.20 look:-60.24,1.23,-159.31
path_end = loop
on_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_1
suitable = {=is_night !surge_started} true
prior = 45

[logic@agr_smart_terrain_1_6_camp_work_2]
active = animpoint@agr_smart_terrain_1_6_camp_work_2
suitable = {=is_night !surge_started} true
prior = 45

[logic@agr_smart_terrain_1_6_camp_work_3]
active = animpoint@agr_smart_terrain_1_6_camp_work_3
suitable = {=is_night !surge_started} true
prior = 45

[logic@agr_smart_terrain_1_6_camp_work_4]
active = animpoint@agr_smart_terrain_1_6_camp_work_4
suitable = {=is_night !surge_started} true
prior = 45

[logic@agr_smart_terrain_1_6_camp_work_5]
active = animpoint@agr_smart_terrain_1_6_camp_work_5
suitable = {=is_night !surge_started} true
prior = 45

[animpoint@agr_smart_terrain_1_6_camp_work_1]
cover_name = agr_smart_terrain_1_6_animpoint_kamp1
use_camp = true
turn_on_campfire = true

[animpoint@agr_smart_terrain_1_6_camp_work_2]
cover_name = agr_smart_terrain_1_6_animpoint_kamp2
use_camp = true
turn_on_campfire = true

[animpoint@agr_smart_terrain_1_6_camp_work_3]
cover_name = agr_smart_terrain_1_6_animpoint_kamp3
use_camp = true
turn_on_campfire = true

[animpoint@agr_smart_terrain_1_6_camp_work_4]
cover_name = agr_smart_terrain_1_6_animpoint_kamp4
use_camp = true
turn_on_campfire = true

[animpoint@agr_smart_terrain_1_6_camp_work_5]
cover_name = agr_smart_terrain_1_6_animpoint_kamp5
use_camp = true
turn_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)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;freedom trader
[logic@faction_controlled_freedom_trader]
suitable = {=check_npc_name(sim_default_freedom_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;bandit trader
[logic@faction_controlled_bandit_trader]
suitable = {=check_npc_name(sim_default_bandit_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;duty trader
[logic@faction_controlled_dolg_trader]
suitable = {=check_npc_name(sim_default_dolg_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;monolith trader
[logic@faction_controlled_monolith_trader]
suitable = {=check_npc_name(sim_default_monolith_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;stalker trader
[logic@faction_controlled_stalker_trader]
suitable = {=check_npc_name(sim_default_stalker_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;ecologist trader
[logic@faction_controlled_ecolog_trader]
suitable = {=check_npc_name(sim_default_ecolog_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;clear sky trader
[logic@faction_controlled_csky_trader]
suitable = {=check_npc_name(sim_default_csky_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

;merc trader
[logic@faction_controlled_killer_trader]
suitable = {=check_npc_name(sim_default_killer_trader)} true
prior = 200
active = animpoint@trade
level_spot = trader
trade = misc\trade\trade_military.ltx
can_select_weapon = false
dont_keep_items = true

[animpoint@trade]
cover_name = agr_smart_terrain_1_6_smart_cover_trader
reach_movement = walk_noweap
avail_animations = jup_b41_novikov_stand
reach_distance = 10
combat_ignore_cond = {=actor_enemy =check_enemy_name(actor)} false, true
combat_ignore_keep_when_attacked = true
gather_items_enabled = false
help_wounded_enabled = false
corpse_detection_enabled = false
invulnerable = {!actor_enemy} true, false
meet = meet@trade

[meet@trade]
close_anim       = nil
close_victim    = nil
far_anim       = nil
far_victim       = nil
close_distance  = 0
far_distance    = 0
close_snd_distance = 3
use = {=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)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_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)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;bandit mechanic
[logic@faction_controlled_bandit_mechanic]
suitable = {=check_npc_name(sim_default_bandit_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;duty mechanic
[logic@faction_controlled_dolg_mechanic]
suitable = {=check_npc_name(sim_default_dolg_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;monolith mechanic
[logic@faction_controlled_monolith_mechanic]
suitable = {=check_npc_name(sim_default_monolith_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;stalker mechanic
[logic@faction_controlled_stalker_mechanic]
suitable = {=check_npc_name(sim_default_stalker_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;ecologist mechanic
[logic@faction_controlled_ecolog_mechanic]
suitable = {=check_npc_name(sim_default_ecolog_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;clear sky mechanic
[logic@faction_controlled_csky_mechanic]
suitable = {=check_npc_name(sim_default_csky_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

;merc mechanic
[logic@faction_controlled_killer_mechanic]
suitable = {=check_npc_name(sim_default_killer_mechanic)} true
prior = 200
active = animpoint@stand
level_spot = mechanic
can_select_weapon = false

[animpoint@stand]
cover_name = agr_smart_terrain_1_6_smart_cover_mechanic
avail_animations = jup_b41_novikov_stand
use_camp = false
meet = meet@mechanic
combat_ignore_cond = {=actor_enemy =check_enemy_name(actor)} false, true
combat_ignore_keep_when_attacked = true
invulnerable = {!actor_enemy} true, false
reach_distance = 10
gather_items_enabled = false
help_wounded_enabled = false
corpse_detection_enabled = false

[meet@mechanic]
close_anim       = nil
close_victim    = nil
far_anim       = nil
far_victim       = nil
close_distance  = 0
far_distance    = 0
close_snd_distance = 3
use = {=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.

User avatar
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

Postby Alundaio » 21 Jan 2016, 19:16

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 loads jobs
    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

Postby carperbr » 21 Jan 2016, 23:07

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 = nil
gulag_general.add_exclusive_job(): Invalid job_type! job_type = nil scheme = nil
gulag_general.add_exclusive_job(): Invalid job_type! job_type = nil scheme = nil
gulag_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_6
object 'sim_default_military_221089': activate_by_section: section 'camper@agr_smart_terrain_1_6_sniper_1_walk' does not exist
You 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

Postby carperbr » 22 Jan 2016, 04:46

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.

User avatar
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

Postby Alundaio » 22 Jan 2016, 16:38

pastebin your configs\scripts\agroprom\smart\agr_smart_terrain_1_6.ltx and gamedata\configs\scripts\agroprom\agr_smart_terrain_1_6_smart_logic.ltx
"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

Postby carperbr » 24 Jan 2016, 20:57

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.

User avatar
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

Postby Alundaio » 25 Jan 2016, 17:42

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_general
object '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

Postby carperbr » 25 Jan 2016, 18:37

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.

User avatar
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

Postby Alundaio » 25 Jan 2016, 18:53

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

Postby carperbr » 25 Jan 2016, 20:38

Cool, sounds good. Thanks for taking a look.

User avatar
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

Postby Alundaio » 26 Jan 2016, 18:13

! ERROR on rejecting: entity not found. parent_id = [0], entity_id = [42004], frame = [1371].
! WARNING: SV: can't find children [19787] of parent [280937744]
compiling shader deffer_model_flat_3
compiling shader shadow_direct_model_aref_3
! auto-generated bump map: wpn\wpn_val_bump#
### PRE UPDATE ###
register_squad(monster)
CREATED simulation_zombie AT mar_smart_terrain_6_10
register_squad(monster)
CREATED simulation_tushkano AT esc_smart_terrain_2_14
register_squad(monster)
CREATED simulation_cat AT ros_smart_monster5
register_squad(monster)
CREATED simulation_chimera AT mil_smart_terrain_4_7
register_squad(monster)
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

Postby carperbr » 26 Jan 2016, 19:59

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.

User avatar
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

Postby Alundaio » 28 Jan 2016, 18:41

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

Postby carperbr » 30 Jan 2016, 00:36

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.

User avatar
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

Postby Alundaio » 30 Jan 2016, 02:45

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."


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest