|
|
|
addict
|
OP
addict
Joined: Sep 2015
|
Sure! I don't have any file sharing technology, so I'd just abuse my JunkBox if that's okay. I'll upload the files this evening then (that's in about 10 hours).
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Whatever works best for you is great 
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
All right. I uploaded the file and gave you access, so you can delete the file after downloading it. http://www.nexusmods.com/divinityoriginalsin/mods/98?Some notes on what it contains: 4 scripts: 1) 'ABRAX_PathBlockAI' (new script) 2) '_SKILLFROMITEM_Base' (original file since there doesn't seem to be a modified version in Epic Encounters; tell me if I missed it) 3) '_SKILL_Base' (taken from Epic Encounters) 4) 'DefaultCharacter' (taken from Epic Encounters) Changes: - included (#) script 1 in the 'DefaultCharacter' (4) script - added the movement interrupt code to the relevant combat reactions in script 2, 3 and 4, and removed DelayReaction OnMovementFailed for better functionality (you probably have some special scripts with movement; they could be regarded later) - disabled 'CallFunction("AMER_ScanForIceWalls")' in the reaction 'Combat_MoveToSetEnemy' (in 'DefaultCharacter' script), the new script replaces its function The ZIP folder already contains the correct folder structure, so you only have to copy the 'Data' folder to the main directory. If it seems that I forgot anything in the scripts, just tell me.
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Awesome, I got it downloaded and deleted it as you had asked. I'll have Elric start testing with it tonight!
EDIT: _SKILLFROMITEM_Base will need to be added to the mod via resource manager/have its UUID replaced by the original version's (just as was done with the other script replacements), correct?
Last edited by Ameranth; 22/02/17 07:40 PM.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
Great!
EDIT: I had the impression that this isn't necessary for scripts which are just included in another script and not added to a character (then you'd need the ID). But I can't say for sure. I'll check it.
EDIT 2: Yes, the game reads the new script 'ABRAX_PathBlockAI' and the modified '_SKILLFROMITEM_Base' from the scripts folder of a module, although the script location in the Content lsb is still Shared, not YourMod. Only scripts that are directly added to a character need extra treatment, it seems.
Last edited by Abraxas*; 22/02/17 08:11 PM.
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Cool, good to know
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Elric had his game crash while in Cyseal, but he was unable to reproduce or pinpoint the cause. He had two party members far off-screen from the controlled character, one in the marketplace near the cheese vendor, and another in the King Crab upper-floors near Shereth. When his controlled character attempted to leave the city toward the Black Cove (opening the door out of the docks), the game crashed.
Hardly enough information here to diagnose a problem, but it makes me wonder whether a far off-screen NPC attempting to move an object will cause a crash?
Last edited by Ameranth; 23/02/17 03:31 AM.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
Never had such an issue. I'll try to reproduce it.
But the script worked in general?
Edit: I'm testing with your mod now, and trying to reproduce this.
Beside a possible problem with item movement, maybe there's a particular issue with this gate. The first things that come to my mind are the auto-save (had Elric triggered it already?) and the open/close door mechanic in Osiris which isn't triggered when the Guard is in combat or dead but, as far as I see, the dialog will be triggered when the door is locked - was it locked?
Last edited by Abraxas*; 23/02/17 10:27 AM.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
After a few tests under the conditions you mentioned (one character near Shereth, I started the fight here and blocked the path with objects, so NPCs would start moving them); one character near the cheese vendor; my active character near the gate to Black Cove, opening/closing the door and moving in and out the whole time), I couldn't reproduce this either. And I've no idea what this crash could have been caused by.
Did Elric trigger the auto-save when he walked through the door?
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Sorry for the delay, I doubt that crash was related to your AI honestly. Elric had already triggered the autosave when it happened.
I do have some feedback from our testers though, but I fear is stuff that isn't going to be easy to fix/fixable at all.
In the Luculla Mines, there is a room with a zombie troll. The tester, Furin, experienced that since the Troll was too large to move around the room, he spent his turns throwing things around the room. At one point the Troll moved an object in front of the door, which caused the others in the room to toss objects around the room instead of taking actions.
In Diederik's fight, Elric placed two chests to block the iron gate, the enemies would run up to the chests and either stare at them without doing anything, or they would turn and move the small candles that are just a short distance up the staircase. My guess here is that they could not see the area where they were trying to move the chests to?
Last edited by Ameranth; 24/02/17 08:25 PM.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
First, thanks for testing the script! The second case can be solved, the first one might remain as a situation that a character can't handle properly (i. e. he'd need some turns) or at all (mostly when other characters block the path; but, at least, those characters closest to the blocking items would be able to solve the situation immediately or after a few attempts; some unnecessary behaviour might be solved by a new event we add, s. below). 2) Second first: it happens due to item weight: Chests have 50,000 weight, so I have to increase the limit. This would also include Straw, Anvil B and Grain Sack, but unfortunately also a few unmovable objects. For special barrels (ooze, oil, water) we'd need 60,000 which isn't a problem since there don't seem to be other objects between 50,000 and 60,000 and no other items with 60,000. Do you think it would be okay to increase the weight of some unmovable 50,000 items to 61,000 to exclude them?* This would be: GEN_HeavyMetal (probably; do you know what items this is for?) Gen_Door_Weak (though doesn't seem to be used often, only found one in Cyseal, a tutorial door) Gen_Stone_Indestructible Gen_HeavyMetalLightSource (maybe, don't know which items have this stat) Gen_SpawnHole_Weak (though probably irrelevant) Gen_SpawnHole_Strong (same) _TrapObjects To leave them included wouldn't be too much of a problem but require more attempts to solve the situation. *or decrease the weight of relevant 50,000 and 60,000 weight items to 40,000. 1) Yeah, big characters are quite limited in some situations. They often don't have an alternative path and often can't reach the temporary target either (due to blocking characters and other objects), so they move the wrong items, which are closer to them. Though smaller characters should be able to solve the situation after a while. With 'instead of taking actions' you mean there would have been a possible target to attack but they had chosen another, unreachable one? It's hard to judge without knowing the exact circumstances, but they must have chosen an unreachable target by default (not my script) or the GetClose and MoveItems reactions where still active from their previous turns, so they didn't return to their default behaviour as long as they didn't reach the temporary target and the target where their movement initially failed. For this case - and other unintended behaviour related to unnecessarily active GetClose/MoveItems reactions - there should this event be added to the 'ABRAX_PathBlockAI' script, to make sure that they always try to execute default behaviour first on their turn and never execute actions that aren't necessary any more:
EVENT SetPathAIPriorities
ON
OnTurnEnded() //also thrown when __Me kills the last enemy to end combat
ACTIONS
SetPriority("GetClose",0)
SetPriority("MoveItems",0)
Whole script:
INIT
CHARACTER:__Me
EXTERN FLOAT3:%TargetPos = null
FLOAT3:%TempTarget
INT:%ItemMoveSuccess = 0
/* //to be added to every reaction with movement
VARS
FLOAT3:_Pos
INTERRUPT
Reset()
ON
OnMovementFailed(_Pos)
ACTIONS
SetVar(__Me,"TargetPos",_Pos)
CharacterEvent(__Me,"ActivateGetClose")
*/
BEHAVIOUR
REACTION GetClose, 0
USAGE PEACE
USAGE COMBAT
VARS
FLOAT:_distance
FLOAT:_MyX
FLOAT:_MyZ
FLOAT:_TargetX
FLOAT:_TargetZ
FLOAT:_AttemptCounter = 0
FLOAT:_AddX
FLOAT:_AddZ
FLOAT:_Divisor
FLOAT3:_Target
FLOAT3:_MyPos
FLOAT3:_TargetPosition
ACTIONS
IF "c1&c2"
GetPosition(__Me,_MyPos)
GetVar(_TargetPosition,__Me,"TargetPos")
THEN
Set(%TempTarget,_TargetPosition)
ENDIF
IF "c1&c2&c3&c4&c5"
GetX(_MyPos,_MyX)
GetZ(_MyPos,_MyZ)
GetX(_TargetPosition,_TargetX)
GetZ(_TargetPosition,_TargetZ)
GetDistance(_distance,__Me,_TargetPosition)
THEN
Subtract(_TargetX,_MyX)
Subtract(_TargetZ,_MyZ)
GetRandom(_Divisor,1.8,1.9,2,2.1,2.2)
Divide(_TargetX,_Divisor)
Divide(_TargetZ,_Divisor)
Add(_MyX,_TargetX)
Add(_MyZ,_TargetZ)
SetX(%TempTarget,_MyX)
SetZ(%TempTarget,_MyZ)
CharacterLookAt(%TempTarget)
IF "c1"
IsGreaterThen(_AttemptCounter,4)
THEN
Set(_AttemptCounter,0)
SetPriority("MoveItems",0)
IF "c1"
IsInCombat(__Me)
THEN
CharacterEndTurn()
ELSE
DelayReaction("GetClose",5)
ENDIF
SetPriority("GetClose",0)
ELIF "c1"
IsLessThen(_distance,4)
THEN
CharacterLookAt(_TargetPosition)
IF "c1"
IsInCombat(__Me)
THEN
CharacterMoveTo(_TargetPosition,1,0,0,0.2,1)
ELSE
CharacterMoveTo(_TargetPosition,0,0,0,0.2,1)
ENDIF
SetPriority("GetClose",0)
ELIF "!c1"
IsLessThen(_distance,4)
THEN
IF "!c1"
FindValidPosition(%TempTarget,4,__Me)
THEN
Interrupt("GetClose")
ENDIF
IF "c1"
IsInCombat(__Me)
THEN
CharacterMoveTo(%TempTarget,1,0,0,0.2,1.4)
ELSE
CharacterMoveTo(%TempTarget,0,0,0,0.2,1.4)
ENDIF
SetPriority("MoveItems",0)
ELSE
Set(_AttemptCounter,0)
SetPriority("MoveItems",0)
SetPriority("GetClose",0)
ENDIF
ENDIF
INTERRUPT
Reset()
ON
OnMovementFailed(_)
OnManualInterrupt("GetClose")
ACTIONS
Add(_AttemptCounter,1)
SetPriority("MoveItems",3000)
SetPriority("GetClose",0)
REACTION MoveItems, 0
USAGE PEACE
USAGE COMBAT
VARS
ITEM:_Item
ITEM:_Item2
ITEM:_IgnoreItem1
ITEM:_IgnoreItem2
ITEM:_IgnoreItem3
FLOAT:_Weight
FLOAT:_X
FLOAT:_Z
FLOAT:_MyPosX
FLOAT:_MyPosZ
FLOAT3:_MyPos
CHARACTER:_Enemy
CHECK "(((((c1&c2)|(c3&c4))&c5&c6&((!c7&c8)|c9))|(c10&c11&c12&((!c13&c14)|c15)))&!c16)|(c17&c18)"
IsRandom(0.4)
ItemGet(_Item,__Me,6,Lowest,Distance,"")
ItemGet(_Item,__Me,6,Random,Distance,"")
CanSee(__Me,_Item)
IsFacing(__Me,_Item)
ItemGetStat(_Weight,_Item,Weight)
IsLessThen(_Weight,1000)
IsLessThen(_Weight,60001)
IsEqual(_Weight,200000) //Ice_Crystal
ItemGet(_Item,%TempTarget,6,Random,Distance,"")
IsFacing(__Me,_Item)
ItemGetStat(_Weight,_Item,Weight)
IsLessThen(_Weight,1000)
IsLessThen(_Weight,60001)
IsEqual(_Weight,200000) //Ice_Crystal
ItemIsDestroyed(_Item)
IsInCombat(__Me)
CharacterGet(_Enemy,__Me,5,Lowest,Distance,Enemy)
ACTIONS
IF "!c1"
IsEqual(_Enemy,null)
THEN
CharacterMoveTo(_Enemy,1)
CharacterAttack(_Enemy)
Goto("End")
ENDIF
IF "c1"
IsInCombat(__Me)
THEN
CharacterMoveTo(_Item,1)
ELSE
CharacterMoveTo(_Item)
ENDIF
IF "c1"
IsEqual(_Weight,200000) //Ice_Crystal
THEN
WHILE "!c1"
ItemIsDestroyed(_Item)
DO
CharacterAttack(_Item)
ENDWHILE
ELSE
GetPosition(__Me,_MyPos)
GetRandom(_X,-3,-2,2,3)
GetRandom(_Z,-3,-2,2,3)
IF "!c1&c2&c3"
ItemIsDestroyed(_Item)
GetX(_MyPos,_MyPosX)
GetZ(_MyPos,_MyPosZ)
THEN
Subtract(_MyPosX,_X)
Subtract(_MyPosZ,_Z)
SetX(_MyPos,_MyPosX)
SetZ(_MyPos,_MyPosZ)
IF "c1"
FindValidPosition(_MyPos,6,_Item)
THEN
StartTimer("CheckMoveItemSuccess",3,0)
CharacterMoveItem(_Item,_MyPos)
Set(%ItemMoveSuccess,1)
ENDIF
ENDIF
ENDIF
Label("End")
Set(_Enemy,null)
SetPriority("MoveItems",0)
INTERRUPT
Reset()
Set(_Enemy,null)
SetPriority("MoveItems",0)
EVENTS
EVENT CheckItemMoveSuccess
ON
OnTimer("CheckMoveItemSuccess")
ACTIONS
IF "c1"
IsEqual(%ItemMoveSuccess,1)
THEN
Set(%ItemMoveSuccess,0)
ELSE
Interrupt("MoveItems")
ENDIF
EVENT GetCloseActivation
ON
OnCharacterEvent(__Me,"ActivateGetClose")
ACTIONS
SetPriority("GetClose",2000)
EVENT SetPathAIPriorities
ON
OnTurnEnded() //also thrown when __Me kills the last enemy to end combat
ACTIONS
SetPriority("GetClose",0)
SetPriority("MoveItems",0)
Edit: Also looking through the object stats to improve the item selection. Seems a lot of small items (paintings, weapons etc.) can be excluded without much effort.
Last edited by Abraxas*; 24/02/17 10:43 PM.
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Those enemies probably didn't have a valid target anyway because, as you said, they would have attacked if they did. I don't have any specifics to give unfortunately, just what he mentioned to me.
I'm relatively confident that changing the weight of unmovable objects won't impact the game in any way, since weight only matters when moving things. So you should be able to change these without worry.
Decreasing weight of objects would mean that you could throw them further with less telekinesis/strength, but unless the difference is massive I don't think it matters much (it probably doesn't matter much anyway).
Excluding those smaller objects would make a huge difference I think, as many of those objects don't influence pathing anyway.
I'm excited to see what you get figured out! I'll update the testers when you have all the stuff ready to go.
Last edited by Ameranth; 25/02/17 01:36 AM.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
All right! I won't have time to work on it today, but I'll prepare the update for Sunday.
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Of course, no rush Furin suggests that, in the case that no better alternatives are found, allow creatures to break objects near them with some sort of AoE. I thought about this and I think it's possible to do without risking destruction of important objects, but this is clearly a last resort.
Last edited by Ameranth; 25/02/17 08:29 PM.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
Destroying items with AoE spells might only be a solution when the destruction of an unmovable object would offer an alternative path, i. e. the only path the character can take (this is only the case when characters block the path to a character's actual target or the path to items that block the path). Destruction of movable objects would not achieve what moving items couldn't achieve, though be a bit more effective in some situations - but I would not know when to prioritize this (and I can't check which items are destructible). As you say: it would be the last hope for a desperate man, but solving anything otherwise unsolvable with this is very unlikely.
The main source of desperate/unsolvable situations are the path blocking characters (though there's always at least one NPC who's able to act, if you don't control him with status effects). I'm currently thinking about strategies here, but they would produce more flaws than benefits; characters don't know if their path is blocked by items or characters (or both) and can't know if an NPC standing around is actually blocking their path or just there for sightseeing (not relevant). They'd have to guess, and not only trying to move items but also asking and causing nearby characters to step aside, often for no reason (and where shall they step to without risking to block another character's path or block a path to blocking items).
I suppose this is a field of impossible improvements.
I would really like to offer quick and elegant solutions for every situation, but some situations will remain complicated - though a permanent all-characters-skip-turn situation should never happen in any case any more.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
Okay, made a list of item stats where changes to weight would be useful/necessary or should/could be considered to improve item selection. To avoid adding more conditions to the MoveItems reaction, I'll define 5,000 as min and 60,000 as max weight and try to keep irrelevant items out by changing weight where possible: 1,000 weight items (weight change for inclusion):1.1) Gen_Wood_Weak (for FUR_Citz_Screen_A or FUR_Citz_Chair_A): increase from 1,000 to 1,100 1.2) Gen_Stone_Weak (no idea): I'd leave it as is for now 1.3) Gen_Metal (no idea): I'd leave it as is for now 1.4) Gen_LightSource (e g. candleholders, unfortunately also used for some unmovable items): increase from 1000 to 1100 --> To change the weight of 1.1 and 1.4 shouldn't be a problem for puzzles which require to drop items of certain weights on pressure plates (one trial as part of the Immaculates' initiation quest). Citizen chairs, candleholders and screens are neither necessary nor available to solve the puzzle (or is there any other puzzle where such items might come into play?). 5,000 weight items (weight change for exclusion):2.1) Gen_FireOnly (no idea): I'd leave it 2.2) Gen_PoisonousMushroom (unmovable): decrease from 5,000 to 4,900 2.3) Gen_UnstableCorpse (explosive zombie corpses, unmovable): decrease from 5,000 to 4,900 2.4) PUZ_Totem (unmovable): decrease from 5,000 to 4,900 10,000 weight items (weight change for exclusion):3.1) FARM_Beehive_A: too rare to bother, I think 3.2) LOOT_Ore_A_Silver_A, LOOT_Ore_A_Iron_A, LOOT_Ore_A_BlackRock_A: too rare to touch 20,000 weight items (for exclusion):4.1) Gen_Stone_Strong (no idea): I'd leave it as is for now 4.2) FARM_Chickenhouse_A: too rare to bother (don't remember any) 30,000 weight items (for exclusion):5.1) Gen_Corpse_Light (didn't see it used): I'd leave it as is 5.2) FARM_Scarecrow: too rare to bother 5.3) LTS_Campfire_A (unmovable): might be useful to exclude it by changing weight from 30,000 to 61,000, though it would be a bit against 'lore' 50,000 weight items (for exclusion):6.1) GEN_HeavyMetal (no idea): I'd leave it as is for now 6.2) Gen_Door_Weak (unmovable): increase from 50,000 to 61,000 6.3) Gen_Stone_Indestructible (no idea): increase from 50,000 to 61,000 6.4) Gen_SpawnHole_Weak (unmovable): increase from 50,000 to 61,000 6.6) Gen_SpawnHole_Strong: increase from 50,000 to 61,000 6.7) _TrapObjects (should all be unmovable): increase from 50,000 to 61,000 70,000 weight items (for inclusion):7.1) TOOL_Smith_Anvil_A: decrease from 70,000 to 60,000 (to compare: TOOL_Smith_Anvil_B, without the wood block which Anvil A is standing on, weighs 50,000) Just tell me which changes you'd be okay with.
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Those changes seem fine to me; I can't think of any reason why they wouldn't be. If it's not too much trouble, could you make the modifications directly to Epic Encounters' object.txt so that I can just drop the file in?
Also, the testers haven't run into any other issues yet. Though I don't believe they are actively trying to trap things with objects at the moment.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
Those changes seem fine to me; I can't think of any reason why they wouldn't be. If it's not too much trouble, could you make the modifications directly to Epic Encounters' object.txt so that I can just drop the file in? Sure. I'll directly edit your file and create the appropriate folder structure. I'll run a few tests myself first and then upload the updated version to Nexus.
|
|
|
|
|
|
addict
|
|
OP
addict
Joined: Sep 2015
|
Uploaded the new version. I made some additional changes to reduce the amount of item check conditions, to guide the character closer to the target, and hopefully achieve small improvements: http://www.nexusmods.com/divinityoriginalsin/mods/98/?Script:
INIT
CHARACTER:__Me
EXTERN FLOAT3:%TargetPos = null
FLOAT3:%TempTarget
INT:%ItemMoveSuccess = 0
/* //to be added to every reaction with movement
VARS
FLOAT3:_Pos
INTERRUPT
Reset()
ON
OnMovementFailed(_Pos)
ACTIONS
SetVar(__Me,"TargetPos",_Pos)
CharacterEvent(__Me,"ActivateGetClose")
*/
BEHAVIOUR
REACTION GetClose, 0
USAGE PEACE
USAGE COMBAT
VARS
FLOAT:_distance
FLOAT:_MyX
FLOAT:_MyZ
FLOAT:_TargetX
FLOAT:_TargetZ
FLOAT:_AttemptCounter = 0
FLOAT:_AddX
FLOAT:_AddZ
FLOAT:_Divisor
FLOAT3:_Target
FLOAT3:_MyPos
FLOAT3:_TargetPosition
ACTIONS
IF "c1&c2"
GetPosition(__Me,_MyPos)
GetVar(_TargetPosition,__Me,"TargetPos")
THEN
Set(%TempTarget,_TargetPosition)
ENDIF
IF "c1&c2&c3&c4&c5"
GetX(_MyPos,_MyX)
GetZ(_MyPos,_MyZ)
GetX(_TargetPosition,_TargetX)
GetZ(_TargetPosition,_TargetZ)
GetDistance(_distance,__Me,_TargetPosition)
THEN
Subtract(_TargetX,_MyX)
Subtract(_TargetZ,_MyZ)
IF "c1&c2"
IsGreaterThen(_distance,11)
IsLessThen(_distance,18)
THEN
GetRandom(_Divisor,3.0,3.2,3.5)
ELIF "c1"
IsGreaterThen(_distance,17.9)
THEN
GetRandom(_Divisor,3.8,4.0,4.3)
ELSE
GetRandom(_Divisor,1.8,2.0,2.2)
ENDIF
Divide(_TargetX,_Divisor)
Divide(_TargetZ,_Divisor)
Add(_MyX,_TargetX)
Add(_MyZ,_TargetZ)
SetX(%TempTarget,_MyX)
SetZ(%TempTarget,_MyZ)
CharacterLookAt(%TempTarget)
IF "c1"
IsGreaterThen(_AttemptCounter,4)
THEN
Set(_AttemptCounter,0)
SetPriority("MoveItems",0)
IF "c1"
IsInCombat(__Me)
THEN
CharacterEndTurn()
ELSE
DelayReaction("GetClose",5)
ENDIF
SetPriority("GetClose",0)
ELIF "c1"
IsLessThen(_distance,4)
THEN
CharacterLookAt(_TargetPosition)
IF "c1"
IsInCombat(__Me)
THEN
CharacterMoveTo(_TargetPosition,1,0,0,0.2,1)
ELSE
CharacterMoveTo(_TargetPosition,0,0,0,0.2,1)
ENDIF
SetPriority("GetClose",0)
ELIF "!c1"
IsLessThen(_distance,4)
THEN
IF "!c1"
FindValidPosition(%TempTarget,6,__Me)
THEN
Interrupt("GetClose")
ENDIF
IF "c1"
IsInCombat(__Me)
THEN
CharacterMoveTo(%TempTarget,1,0,0,0.2,1.4)
ELSE
CharacterMoveTo(%TempTarget,0,0,0,0.2,1.4)
ENDIF
SetPriority("MoveItems",0)
ELSE
Set(_AttemptCounter,0)
SetPriority("MoveItems",0)
SetPriority("GetClose",0)
ENDIF
ENDIF
INTERRUPT
Reset()
ON
OnMovementFailed(_)
OnManualInterrupt("GetClose")
ACTIONS
Add(_AttemptCounter,1)
SetPriority("MoveItems",3000)
SetPriority("GetClose",0)
REACTION MoveItems, 0
USAGE PEACE
USAGE COMBAT
VARS
ITEM:_Item
ITEM:_Item2
ITEM:_IgnoreItem1
ITEM:_IgnoreItem2
ITEM:_IgnoreItem3
FLOAT:_Weight
FLOAT:_X
FLOAT:_Z
FLOAT:_MyPosX
FLOAT:_MyPosZ
FLOAT:_distance
FLOAT3:_MyPos
CHECK "(((c1&c2)|(c3&(c4|c5)))&c6&c7&((!c8&c9)|c10|c11))&!c12"
IsRandom(0.4)
ItemGet(_Item,__Me,7,Lowest,Distance,"")
ItemGet(_Item,__Me,7,Random,Distance,"")
CanSee(__Me,_Item)
IsRandom(0.3)
IsFacing(__Me,_Item,120)
ItemGetStat(_Weight,_Item,Weight)
IsLessThen(_Weight,5000)
IsLessThen(_Weight,60001)
IsEqual(_Weight,200000) //Ice_Crystal
IsEqual(_Weight,1100)
ItemIsDestroyed(_Item)
ACTIONS
IF "c1"
IsInCombat(__Me)
THEN
CharacterMoveTo(_Item,1)
ELSE
CharacterMoveTo(_Item)
ENDIF
IF "c1"
IsEqual(_Weight,200000) //Ice_Crystal
THEN
WHILE "!c1"
ItemIsDestroyed(_Item)
DO
CharacterAttack(_Item)
ENDWHILE
ELSE
GetPosition(__Me,_MyPos)
GetRandom(_X,-3,-2,2,3)
GetRandom(_Z,-3,-2,2,3)
IF "!c1&c2&c3"
ItemIsDestroyed(_Item)
GetX(_MyPos,_MyPosX)
GetZ(_MyPos,_MyPosZ)
THEN
Subtract(_MyPosX,_X)
Subtract(_MyPosZ,_Z)
SetX(_MyPos,_MyPosX)
SetZ(_MyPos,_MyPosZ)
IF "c1"
FindValidPosition(_MyPos,6,_Item)
THEN
StartTimer("CheckMoveItemSuccess",3,0)
CharacterMoveItem(_Item,_MyPos)
Set(%ItemMoveSuccess,1)
ENDIF
ENDIF
ENDIF
SetPriority("MoveItems",0)
INTERRUPT
Reset()
SetPriority("MoveItems",0)
EVENTS
EVENT CheckItemMoveSuccess
ON
OnTimer("CheckMoveItemSuccess")
ACTIONS
IF "c1"
IsEqual(%ItemMoveSuccess,1)
THEN
Set(%ItemMoveSuccess,0)
ELSE
Interrupt("MoveItems")
ENDIF
EVENT GetCloseActivation
ON
OnCharacterEvent(__Me,"ActivateGetClose")
ACTIONS
SetPriority("GetClose",2000)
EVENT SetPathAIPriorities
ON
OnTurnEnded() //also thrown when __Me kills the last enemy to end combat
ACTIONS
SetPriority("GetClose",0)
SetPriority("MoveItems",0)
The following changes have been made: - reduced the max distance to the temporary target to about 6m, so characters hopefully get a bit closer to the relevant items; therefore, an item check near the temporary target shouldn't be necessary any more - increased/decreased the weight of several items to exclude/include them for item movement behaviour (list s. above) - reduced the item check conditions - the priorities of 'GetClose' and 'MoveItems' are set to 0 OnTurnEnded to avoid unnecessary movement/item movement and issues with redhanded reactions NPCs might trigger after combat (making them unresponsive) From my testings: I think I've created a similar (or same) situation as Furin did, but I can hardly help NPCs here. The following complications will probably remain: 1) Other characters block the path, so the active character will try to move items but can't solve the situation. Turn will be skipped after four attempts. 2) The character doesn't face the blocking items and will try to move irrelevant items. With some luck he will change his position in a way that he will face the relevant items. I could try letting characters change their direction to face other areas and hopefully find the right items by chance. Though I don't know if/how much it would help. 3) The character has no possible line of sight to the enemy because everything is blocked with massive items (like crates). I'm not sure what the default combat behaviour of NPCs would be; do they try to change their position to get sight? Because currently characters sometimes seem to look into completely different directions than they should and do either nothing, if they don't find items, and skip turn after a while or move irrelevant items. I produced this situation by blocking the door to Shereth's room with crates. When I replaced one crate with a candleholder or left little space between the crates (and positioned my character so that the character could see me) the characters used their distance skills and could handle the items better/at all. 4) Low weight items won't be moved now, but the character still checks over them of course. This can lead to the character needing several/many attempts to finally solve the situation, if many small items are dropped between the character and the blocking items (so the irrelevant items are closer to the character). Small, winding and crowded (by characters and/or items) locations are the most complicated ones and can be used to the player's advantage most. The AI and the scripting show the greatest limitations and flaws here. In Boss fights NPCs should usually handle the player's attempts to block path quite well. Often the areas are open and wide enough. A strategy like this from Ragshak would definitely lead to a surprise, and a quick end: http://steamcommunity.com/sharedfiles/filedetails/?id=860124545.That's all I have for now.
|
|
|
|
|
|
member
|
|
member
Joined: Dec 2016
|
Sounds great! I'll get the testers working with this right away.
The AI doesn't need to be 100% perfect, I think, especially given the limitations that you are working within, here. As long as it doesn't interfere with standard play and can handle some cheese, I would say it's a victory.
As a note: Furin experienced that, in the 3rd fight with shadow creatures near the Icara's hut, hiding inside the hut and closing the door with Ice Wall caused enemies to move objects around outside, rather than destroy the Ice Walls.
|
|
|
Moderated by Bvs, ForkTong, gbnf, Issh, Kurnster, Larian_QA, LarSeb, Lar_q, Lynn, Monodon, Raze, Stephen_Larian |
|
