Is there a script that forces an initiative roll? or at least creates the event somehow? b4 combat preferably . . .
Quick Fix For Initiative Roll
Débuté par
Morbane
, juil. 21 2010 09:41
#1
Posté 21 juillet 2010 - 09:41
#2
Posté 21 juillet 2010 - 02:22
Hi Morbane,
I am not sure what you are hoping to achieve here, as combat always rolls an initiative as far as I am aware. However, you could try using the OnPerception hook as an event that takes place prior to combat, but it would be a little hit and miss. How you could use this though, I do not know.
I don't think what you are asking for is anything that can be used in any way though.
Lance.
I am not sure what you are hoping to achieve here, as combat always rolls an initiative as far as I am aware. However, you could try using the OnPerception hook as an event that takes place prior to combat, but it would be a little hit and miss. How you could use this though, I do not know.
I don't think what you are asking for is anything that can be used in any way though.
Lance.
Modifié par Lance Botelle, 21 juillet 2010 - 02:23 .
#3
Posté 21 juillet 2010 - 09:20
You can hook into the relevant script event on the creature in question to do whatever it is you're trying to do and you can certainly make die rolls to determine things like initiative, though I don't think you can directly control initiative itself:
OnCombatRoundEnd
OnDamaged
OnPerception
OnPhysicalAttacked
OnSpellCastAt
OnCombatRoundEnd
OnDamaged
OnPerception
OnPhysicalAttacked
OnSpellCastAt
#4
Posté 21 juillet 2010 - 09:29
Sorry - I was just wondering if I could force the start of combat at a distance before certain events take place - without having to edit every creature in the game. But I can see that there really is no way now. Thanks everyone.
#5
Guest_ElfinMad_*
Posté 21 juillet 2010 - 09:47
Guest_ElfinMad_*
You could increase perception ranges in ranges.2da
#6
Posté 21 juillet 2010 - 09:50
Morbane wrote...
Sorry - I was just wondering if I could force the start of combat at a distance before certain events take place - without having to edit every creature in the game. But I can see that there really is no way now. Thanks everyone.
Hi Morbane,
Actually, this is possible.
Lance.
EDIT: I see ElfinMad had the same idea.
Modifié par Lance Botelle, 21 juillet 2010 - 09:51 .
#7
Posté 21 juillet 2010 - 09:50
I've played with perception ranges for some of my creatures to vary how easily they'll go after hostile targets.
There are also lots of variables to play with in nw_i0_generic and x0_i0_behavior (for example, carnivore/omnivore/herbivore can be bitwise set on the NW_BEHAVIOR_MASTER variable).
On that topic, I'd like to be able to see what changes are in TonyK's override event scripts, but they seem to only be available as .NCS. Anyone know where the .NSS files can be found? This is important because of things of scripted handles for things like SpeakOneLinerConvo in the OnPerception script...
Edit: Seems other people had the same idea about perception ranges. The only thing I'd say is to try just setting higher perception ranges on some creatures to start and test it out. Going from default to long makes a big difference. Also, if two creatures with the same faction are close to each other, the one with the shorter perception range will follow the more aggressive one into combat.
Example: A is a warrior creatyure wearing a big ol' helm with a faceplate, and B is a wily scout. C is hostile to them. They are arranged thusly:
A--BC
Both A and B will run and attack C.
There are also lots of variables to play with in nw_i0_generic and x0_i0_behavior (for example, carnivore/omnivore/herbivore can be bitwise set on the NW_BEHAVIOR_MASTER variable).
On that topic, I'd like to be able to see what changes are in TonyK's override event scripts, but they seem to only be available as .NCS. Anyone know where the .NSS files can be found? This is important because of things of scripted handles for things like SpeakOneLinerConvo in the OnPerception script...
Edit: Seems other people had the same idea about perception ranges. The only thing I'd say is to try just setting higher perception ranges on some creatures to start and test it out. Going from default to long makes a big difference. Also, if two creatures with the same faction are close to each other, the one with the shorter perception range will follow the more aggressive one into combat.
Example: A is a warrior creatyure wearing a big ol' helm with a faceplate, and B is a wily scout. C is hostile to them. They are arranged thusly:
A--BC
Both A and B will run and attack C.
Modifié par MasterChanger, 21 juillet 2010 - 09:55 .
#8
Posté 22 juillet 2010 - 05:41
hmmmmmmmmmmm
What I really mean to say is ah-ha...
perception ranges - could make a difference
This is related to my other posts in the 'scripting forum' - the game freezing - now randomly instead of every time my PC got within range to initiate combat - this freeze is an inherited side effect of a while loop - I have scripted a few rather complex heartbeats in this module I am working on - but for some reason the following conditions raise their gnarly heads:
If the NPC makes the first attack when in range - everything is ok
If the PC targets the NPC from far away and runs into range - freezes every time - not ok
*I added a conditional that checks if the pc attacks first to immediately DetermineCombatRound() - in the hopes that would somehow help -
Following the DetermineCombatRound() if the PC targets an NPC from a distance then runs into range the freeze only happens randomly - my observation of the output text during the experiment reveals that if initiative does not immediately fire - freeze-o poof! BUT if the initaitive roll is output everything is ok -no freeze-o - yay! But that seems to be random because every test is done the same way - when the PC can see the NPC through the farplane for creatures (fog) I put the PC to target the NPC - now after this badly explained bug I am trying to workaround happens - it happens randomly - based on whether or not the initiative is output in the text box.
I have tonnes of scripts all knotted into each other but I can solve the freeze with a simple (albeit unknown to me if there is an alternative) to using the while loop to count how many enemies there are in the encounter.
Well I'll stop there because I am probably just rambling - I dont think but I might hope that if some one had the insane notion to check out all my scripts which are dependent on several 2das and roughly 5 separate scripts and test it first hand - your efforts could release me from my obsessive desire to crack this bug open.
//end ramble-athon
What I really mean to say is ah-ha...
perception ranges - could make a difference
This is related to my other posts in the 'scripting forum' - the game freezing - now randomly instead of every time my PC got within range to initiate combat - this freeze is an inherited side effect of a while loop - I have scripted a few rather complex heartbeats in this module I am working on - but for some reason the following conditions raise their gnarly heads:
If the NPC makes the first attack when in range - everything is ok
If the PC targets the NPC from far away and runs into range - freezes every time - not ok
*I added a conditional that checks if the pc attacks first to immediately DetermineCombatRound() - in the hopes that would somehow help -
Following the DetermineCombatRound() if the PC targets an NPC from a distance then runs into range the freeze only happens randomly - my observation of the output text during the experiment reveals that if initiative does not immediately fire - freeze-o poof! BUT if the initaitive roll is output everything is ok -no freeze-o - yay! But that seems to be random because every test is done the same way - when the PC can see the NPC through the farplane for creatures (fog) I put the PC to target the NPC - now after this badly explained bug I am trying to workaround happens - it happens randomly - based on whether or not the initiative is output in the text box.
I have tonnes of scripts all knotted into each other but I can solve the freeze with a simple (albeit unknown to me if there is an alternative) to using the while loop to count how many enemies there are in the encounter.
Well I'll stop there because I am probably just rambling - I dont think but I might hope that if some one had the insane notion to check out all my scripts which are dependent on several 2das and roughly 5 separate scripts and test it first hand - your efforts could release me from my obsessive desire to crack this bug open.
//end ramble-athon
#9
Posté 22 juillet 2010 - 12:24
I found this in the lexicon 1.69
CheckEnemyGroupingOnTarget(object, float)
I am going to try to use this instead of the while loop.
Edit: Kung-Fu'd lol - in a good way though
CheckEnemyGroupingOnTarget(object, float)
I am going to try to use this instead of the while loop.
Edit: Kung-Fu'd lol - in a good way though
Modifié par Morbane, 22 juillet 2010 - 12:26 .
#10
Posté 22 juillet 2010 - 12:24
Hi Morbane,
Unfortunately, I am not in a position to examine all your scripts as I have quite a few of my own to work through.
However, the advise I can offer is to prevent each script you are using from firing in turn (as a test) to which script is causing the problem. Then, when the offending script is found, rem out different sections of this script and test again until you discover which part of the script is giving the grief.
That said, I am surprised you are having issues, as combat is mostly automated from the basic scripts. Have you tested to see what happens using default scripts and just increasing the ranges in the ranges.2da? Does the freeze still happen then?
Although if you have traced the problem down to the while loop you mention, then the problem may simply be to do with the way you have set up your loop.
My overall advise is, simplify what you are doing (remove all scripts) and start adding them back one at a time until you narrow down when and where the problem arises.
Lance.
Unfortunately, I am not in a position to examine all your scripts as I have quite a few of my own to work through.
That said, I am surprised you are having issues, as combat is mostly automated from the basic scripts. Have you tested to see what happens using default scripts and just increasing the ranges in the ranges.2da? Does the freeze still happen then?
Although if you have traced the problem down to the while loop you mention, then the problem may simply be to do with the way you have set up your loop.
My overall advise is, simplify what you are doing (remove all scripts) and start adding them back one at a time until you narrow down when and where the problem arises.
Lance.
Modifié par Lance Botelle, 22 juillet 2010 - 12:25 .
#11
Posté 22 juillet 2010 - 12:29
Yep - I've gone through my stuff like that a few times - that is why it is so confounding... I am a decent scripter - or at least an advanced novice - and debugging is methodical and logic based - but if you see my simultaneous post to yours i might have found a solution.
Thanks for your input - I think I will go bare bones again just to be sure I haven't missed something obvious.
Thanks for your input - I think I will go bare bones again just to be sure I haven't missed something obvious.
#12
Posté 22 juillet 2010 - 12:53
Looking at your other scripts, I'm wondering if the constant application of effects is causing the game to freeze up at times. Most effects have some sort of visual effect tied to them, and that can cause lag, especially if many effects are fired at the same time.
One possible way around it would be to initially apply the effects as permanent effects, and then write a script that removes the effects when the conditions no longer apply, rather than re-applying the effects every round or so.
As for the initiative checks, you could devise a system of triggers that manages spawned encounters and handles initiative checks. Say you have trigger A that spawns-in the encounter creatures out of perception range, then trigger B that runs an initiative check and initiates combat right before the player enters the encounter creature's perception range. The command ActionAttack has a passive mode parameter which you could use for a failed initiative check.
One possible way around it would be to initially apply the effects as permanent effects, and then write a script that removes the effects when the conditions no longer apply, rather than re-applying the effects every round or so.
As for the initiative checks, you could devise a system of triggers that manages spawned encounters and handles initiative checks. Say you have trigger A that spawns-in the encounter creatures out of perception range, then trigger B that runs an initiative check and initiates combat right before the player enters the encounter creature's perception range. The command ActionAttack has a passive mode parameter which you could use for a failed initiative check.
#13
Posté 22 juillet 2010 - 01:14
Thats part of the weirdness - the HB script I'm currently cracking has only a couple of persistent effects - haste, insanity and bonus hit points - none of which are even being applied when the script locks the game - I know it is something really inoculate and even if it compiles there is some sort of a scripting flaw . All the linked scripts are not all firing together but they do rely upon each other such as includes with helper functions. - I have yet to try that CheckEnemyGroupingOnTarget (object, float) function
With good feedback like this really makes it worth while - thanks LotRS
With good feedback like this really makes it worth while - thanks LotRS
#14
Posté 22 juillet 2010 - 01:35
How exactly are you linking them together? Include, execute script? Setting variables that are used by different scripts fired at different events?
ExecuteScript doesn't actually fire, run completely, then return to the parent script. It just runs whenever the engine gets around to it. Using include scripts requires to you re-compile everything whenever you make a change. Using variables invariably means typos, you just have to go back and go over everything with a fine-tooth comb.
If the freeze is more than just a little hiccup, it's probably an infinite loop somewhere that the engine cuts off after a second or two.
ExecuteScript doesn't actually fire, run completely, then return to the parent script. It just runs whenever the engine gets around to it. Using include scripts requires to you re-compile everything whenever you make a change. Using variables invariably means typos, you just have to go back and go over everything with a fine-tooth comb.
If the freeze is more than just a little hiccup, it's probably an infinite loop somewhere that the engine cuts off after a second or two.
#15
Posté 22 juillet 2010 - 02:04
CheckEnemyGroupingOnTarget (oPC, 10.0f) <- Works great - I haven't tested all the variations of combat but oPC = GetAreaOfEffectCreator() seems to keep things tidy - no more while loop! this whole thing was about managing the three effects mentioned above. I LOVE the lexicon!!





Retour en haut







