47 réponses à ce sujet

[RecklezzRogue]

obsolete

Modifié par RecklezzRogue, 17 avril 2010 - 06:31 .

[Magic]

Oops. I haven't looked at your last area script but I see that there's some misunderstanding. It's best to have a look at the core files (creature_core.nss, rules_core.nss, area_core.nss) and see which events they are handling. Your current script is probably mixed.



area events: EVENT_TYPE_AREALOAD_PRELOADEXIT, EVENT_TYPE_TEAM_DESTROYED

creature event: EVENT_TYPE_PERCEPTION_DISAPPEAR

"core" event: EVENT_TYPE_COMMAND_COMPLETE



Area and creature events go to the scripts assigned in the script field of the corresponding resource, respectively. The event I called "core" goes directly to rules_core.nss. This is specified in file \\Dragon Age\\tools\\Source\\2DA\\events.xls. Override that entry there and you are redirecting events. There are others who can help you better with this since I haven't done it. I fail to see what above creature script repairs or why the fireballs are delayed but let's sort things out first.

[RecklezzRogue]

got it - thanks...I'll clean some things up and see what happens.



I guess my basic question is, how are you implementing your AOE (fireball) fix and your perception fix? Where did you put the code --> did you modify rules_core & creature core?



ps - where do I send the checks for technical support ;-)

[Magic]

I'm handling it in a way I wouldn't recommend. Otherwise I would have already. For a stand-alone module it's easy to give all the creatures a custom creature script. Here I don't need to override anything and EVENT_TYPE_PERCEPTION_DISAPPEAR is handled here, then passed to creature_core.nss. If you have an own creature script, this approach seems fine to me.

Without overriding core scripts, I don't get EVENT_TYPE_COMMAND_COMPLETE, nor EVENT_TYPE_APPLY_EFFECT. So I'm using EVENT_TYPE_DROP_STEALTH for the fireball-like effects. For an easier and quicker approach, I suggest to redirect events and use a system which handles event broadcasting to any add-on your module is going to support. From my understanding anakin's Event Manager add-on is doing this.

[RecklezzRogue]

I see.



So - this is a standalone module (Dark Alliances)...that said, if I create a 'standard' custom creature script, will it "hear" EVENT_TYPE_COMMAND_COMPLETE? Sounds like it won't based on your comment :



"Without overriding core scripts, I don't get EVENT_TYPE_COMMAND_COMPLETE, nor EVENT_TYPE_APPLY_EFFECT."



Thanks for everything....slowly but surely learning how all this works...definately curious as to how you got so good (and don't work for Bioware)...muhuihahaha....

[Magic]

You're right, it won't. Your script assigned in the creature's script field receives only events which have no entry in the Script column of events.xls. Basically, the core game is using event redirection itself.

You're welcome, and don't worry. I've been programming for over 20 years now. The toolset has a lot for me to learn as well. In fact, I estimate that I'm familiar with only 10-15% of its functionality so far. So let's continue the fun.

[RecklezzRogue]

Approach Update --- I did some poking around on re-directs...I like this approach as there will be no need to mess with core files...I am going to try to get all three pieces of code in a redirect script (Fireball Fix,Idle NPC after Combat fix, and the Perception Fix) Based on what I read, it seems that this should be the most efficient (and contained) way to address these issues...I'll post the results, hopefully in a couple hours....man I am really looking forward to getting past this so I can get back to the storyline...

=====

for sure....(continue the fun).

btw - I went ahead and modified creature_core with the perception fix trying to solve the hand grenade timed fireball issue - it helped..but I don't think I have not quite figured out what introduced the degraded performance yet...I am doing the line by line thing again...thinking though the logic.

My biggest concern in modifying core scripts is portability when I want to release the module - so - I am going to back to the custom creature script, and perhaps redirect CC-32 to the custom creature script if I can get that granular (i will use an 'if' 32, else send off to rules_core). I think that might hurt performance though....

On a similar topic, the code that you provided to get idle NPC's moving after combat - I am having some timing issues with that, meaning, there is a gap between fiights where I want some NPC's to stay put, but they Rubber_GoHome...so...I can either Set_RubberHome when I position them, or, I Am thinking the Ambient commands might work better, and get them where I want them after the 3 battles...sounded like that was your approach. It seems that the ambient system runs on it's own clock though, and it's not always in sync with the desired results.I've noticed that moves with Ambient_Start sort of kick in when they please, and moves UT_QuickMove happen right away...

Modifié par RecklezzRogue, 16 avril 2010 - 12:32 .

[carmadaum]

This thread has been very helpful! Thanks!!

[RecklezzRogue]

carmadaum wrote...

This thread has been very helpful! Thanks!!

Thanks to Magic for being a source of code and ideas....  ;-)

[RecklezzRogue]

Ok - doing the override via m2da (engineevents.xls) works...and performance is much much better...however - with the way I've combined the "idle npc after combat fix" with the "idle NPC after AOE" fix in the redirect for EVENT_TYPE_COMMAND_COMPLETE, I am now wed to commands that Rubber_SetHome in order to keep NPC's at temporary waypoints between battles, becuase when there is no combat, they Rubber_GoHome. Noteworthy, though, is that this does not mess with my Archer Patrols (MOVE_PATTERN_LOOP - Ambient) - YAHOO!!!!

I can live with that (the Rubber issue) until it becomes a headache for some unforseen reason...this works and I am moving on....many many many thanks Magic...you got me here...(with a lil wiki help)....

ps - best of all, I was able to undo my changes to creature_core and rules_core...phew... ;-)


engineevents.xls (in  "module/core/override/"):

ID--| Label------------------------------------------------------| Visualizer--| Script-------------------------
26  |  EVENT_TYPE_PERCEPTION_DISAPPEAR   |                   | dmo001_event_intercept
36  |  EVENT_TYPE_COMMAND_COMPLETE         |                   | dmo001_event_intercept


My Override Script (in "toolsetexport") :


See Later Post...(improved script)

Modifié par RecklezzRogue, 17 avril 2010 - 04:34 .

[RecklezzRogue]

hrmp...I tweaked something and my archers stopped working - I'll figure it out - I really just wanted to post that - wow - everything works, the battles are fluid, the fireballs go off instantly as well as their affects...Magic - how long you been helping me tryin to get here? Anyway - it's a nice thing to see it all come together.

UPDATE - I fixed the archers by excluding them specifcally by tighten the conditional on the Rubber_GoHome call. What is did not scalable (if statement for specific objects), so I am going to find a variable in the creature template (like ready for vo or something), and set that for creatures that I need to be certain will follow ambient movement paths. This may result in those excluded suffering the problem I put the code in  to fix, but it seems a fair risk...it is very annoying when the npc's are in the wrong place at the end of action (and don't go where they belong).

or....I could just check for MOVE_PATTERN not equal to zero...hmm....? (how do i check creature variables?)

Modifié par RecklezzRogue, 16 avril 2010 - 06:42 .

[Magic]

Ugh, attack of the text walls!

I guess you already proceeded further while I'm responding, so just a few random points. It seems you're encountering many same problems I had. ^^ Your decision on redirecting the disappear event is an interesting one.

- creature_core.nss is calling Rubber_GoHome() in EVENT_TYPE_COMBAT_END. If you don't want this,
SetLocalInt(OBJECT_SELF, RUBBER_HOME_ENABLED, FALSE);
If you use it together with ambient behavior, you might encounter race conditions.
- rules_core.nss continues ambient behavior in EVENT_TYPE_COMMAND_COMPLETE with Ambient_CommandComplete(). Additionally, the engine sends EVENT_TYPE_AMBIENT_CONTINUE based on player proximity to perform ambient behavior.
- When you check for command 32, maybe add a GetCombatState(OBJECT_SELF) check as well. Mostly for clarity, though, as AI_DetermineCombatRound() doesn't seem to make problems outside combat.
- That's nice what you did with Rubber_GoHome() and Ambient_Start(). I've seen something similar before.
- AMBIENT_MOVE_PATTERN is simply checked with GetLocalInt().
- Good work.

[Magic]

I've two another things on Ambient_Start(), and I was going to write them on the wiki (will do) but actually, I'm interested in other people's opinion when it comes to finding a workaround. So I state my findings first. This discussion was inspiring for me as well, thanks for that.

- If Ambient_Start() is called without second parameter (default: AMBIENT_SYSTEM_ENABLED), it resets its state. Especially this means, that AMBIENT_STATE_ALWAYSON will be removed.
- If Ambient_Start() is called the first time, it will start with animation. Not sure how much time I spent on this. I kept on overlooking the root cause repeatedly. Ambient_DoSomething() is calling Ambient_ReachedDestination() first but when starting the first time, no waypoint is set in the ambient system's parameters, so this function will return TRUE! No movement is assigned despite the fact that the first waypoint might not be reached at all, then animation is triggered.

[RecklezzRogue]

Magic -


Regarding Ambient_Start() w/o second parameter:

In order to keep my archer patrols moving, I am calling Ambient_Start() with all the parameters (using 19 - always on) at each trigger point. In other words, once both archers arrive at check point triggers, they are sent along their merry way with the same Ambient_Start arguments I initially used to get them to the checkpoint. The Move pattern figures out where to send them based on the "ap_" waypoint tags at each each checkpoint. This seems to work quite well...but the Rubber_GoHome piece needs to be managed (as you indicate in the previous post, now that I've run throug this a few times, I think I am encountering race conditions...).

Regarding the intial Ambient_Start() with all  parameters:

The first time you set Ambient_Start, I believe that if you have not set a home waypoint or valid destination with amove command setting bNewhome=true, the location the creature spawned is the home location - so it  is TRUE that the NPC's has reached its destination. I use Ambient_Start () w/o parameters initially for NPC's that do not need to move but I do want to  make sure they start their Ambient_Behaviour (from the creature template), and that works aok. Else - I use the same technique I use with the archers - even if it's just one waypoint I need to get the NPC to, I use the "ap_<tag>" approach and set the move pattern accordingly (like MOVE_PATTERN_ONCE).

I not sure if that helps with your 'opinions' questions --- I definately think a Wiki article is called for though as my two observations above are the result way too much trial & error

Magic wrote...

I've two another things on Ambient_Start(), and I was going to write them on the wiki (will do) but actually, I'm interested in other people's opinion when it comes to finding a workaround. So I state my findings first. This discussion was inspiring for me as well, thanks for that.

- If Ambient_Start() is called without second parameter (default: AMBIENT_SYSTEM_ENABLED), it resets its state. Especially this means, that AMBIENT_STATE_ALWAYSON will be removed.
- If Ambient_Start() is called the first time, it will start with animation. Not sure how much time I spent on this. I kept on overlooking the root cause repeatedly. Ambient_DoSomething() is calling Ambient_ReachedDestination() first but when starting the first time, no waypoint is set in the ambient system's parameters, so this function will return TRUE! No movement is assigned despite the fact that the first waypoint might not be reached at all, then animation is triggered.

Modifié par RecklezzRogue, 16 avril 2010 - 06:54 .

[RecklezzRogue]

Magic wrote...

- When you check for command 32, maybe add a GetCombatState(OBJECT_SELF) check as well. Mostly for clarity, though, as AI_DetermineCombatRound() doesn't seem to make problems outside combat.
- That's nice what you did with Rubber_GoHome() and Ambient_Start(). I've seen something similar before.
- AMBIENT_MOVE_PATTERN is simply checked with GetLocalInt().
- Good work.

Thanks...still tweaking...I tried putting some more conditionals in place, escpecially around the Rubber_GoHome piece and have not quite found right combination. Trying to check Combat State (flase) and Ambient_Move_State (zero) to allow the condition to pass....those did not work at first, but then I had to go to the office...more results later...

[RecklezzRogue]

Latest Event Intercept Script - this allows for Ambient move patterns, and handles all the issues we set out to address. That said - I am getting some poor performance, so I may be passing off to the core scripts more than I need to. I am going to tweak bEventHandled and get the best setting I can performancewise while maintaining functionality. Anyway - here it is...

UPDATE - Added AI_DetermineCombat Round to the Perception fix and set bEventHandled = TRUE. Now all events intercepted are handled and there are no calls to core scripts. It seems that performance is better, but in the thicker battles, I still see some Effects delays (stone fist, fire ball), but not so bad...the thing is, I have seen this all happen really fast --- no delays no matter which battle/how many combatants --- I just can't seem to consistently get back to that level of performance...going through my area and other scripts to see if I am doing something silly...the following does work though:

UPDATE - Added a condition to check whether NPC is in a party member for the Rubber code. My party member was trying to Rubber_GoHome, then go to hero, then go home, then....etc....  :-\\\\

UPDATE - Added conditions so the rubber go home & ambient start workarounds do not affect the controlled character or followers.

UPDATED Cinco de Mayo --- see latest script in my latest post

Modifié par RecklezzRogue, 05 mai 2010 - 06:43 .

[Magic]

- Why oOwner != oHero? Did you really intend to refer to

object oOwner = GetEventCreator(ev);

?

- I need the EVENT_TYPE_PERCEPTION_DISAPPEAR threat update for followers as well, unfortunately. They might become idle else.

- The Ambient_Start() part is currently checking for !GetLocalInt(OBJECT_SELF, AMBIENT_MOVE_PATTERN). Doesn't seem right.

- Is the event redirection causing the performance loss?

[RecklezzRogue]

Magic wrote...

- Why oOwner != oHero? Did you really intend to refer to
object oOwner = GetEventCreator(ev);
?

yes - I do not want the intercepts to function for the player character.  Am I doing that wrong?

Magic wrote...
- I need the EVENT_TYPE_PERCEPTION_DISAPPEAR threat update for followers as well, unfortunately. They might become idle else.

I have not done enough combat testing with followers yet to know - I excluded followers because of the Rubber_GoHome piece, and just assumed that followers would be using custom AI (AI_CUSTOM_AI_ACTIVE = 1), so...I'll run a test case or two and see what happens.

Magic wrote...
- The Ambient_Start() part is currently checking for !GetLocalInt(OBJECT_SELF, AMBIENT_MOVE_PATTERN). Doesn't seem right.

Hmmm - what this does is it prevents creatures with move patterns from getting hit by the Ambient Start (w/o parms) and the Rubber_GoHome. Becuase I am using ambient system to the loop the archers (MOVE_PATTERN_LOOP). It is working - I think...is OBJECT_SELF not who I think it is? 8-0

Magic wrote...
- Is the event redirection causing the performance loss?

I don't think so anymore - things are running much better, but I still get some occasional slow downs, especially for fire balls...usually when there are a lot of creatures fighting (but sometimes large fights are aok). Any ideas on troubleshooting?

ps - I set the majority of NPC's AI_LIGHT_ACTIVE with very interesting results - performance seemed generally better, but really what happened (noticeably) is that the battles became MUCH more difficult...I don't understand why, but the effect is great.

Modifié par RecklezzRogue, 18 avril 2010 - 04:18 .

[Magic]

- GetEventCreator() returns nothing in my test for EVENT_TYPE_PERCEPTION_DISAPPEAR. The creature disappearing is GetEventObject(ev,0). I just wondered if you wanted to check for OBJECT_SELF being the hero. Even then though, please remember that the hero character might not be under control as well, thus it should use the threat table, too. I have no idea whether GetEventCreator() returns anything meaningful for EVENT_TYPE_COMMAND_COMPLETE.

- Rubber_GoHome() can be taken care of with SetLocalInt(oCreature,RUBBER_HOME_ENABLED,FALSE); - if you don't want them to return home.

- AI_CUSTOM_AI_ACTIVE is FALSE unless you set it yourself. Followers are indeed using another AI than standard but this is not the custom AI. If you turn on AI_CUSTOM_AI_ACTIVE, they will do little in combat unless scripted by you explicitly.

- I see you scripted the archers as you intended. I assumed you actually want Ambient_Start() to affect creatures with move patterns.

- No idea with the performance. Mine is becoming worse with core scripts alone when numbers are high. You could remove parts of your custom scripts again to identify the root cause.

[RecklezzRogue]

GetEventCreator --- I see, I changed to OBJECT_SELF (and including followers) Thanks...

  case EVENT_TYPE_PERCEPTION_DISAPPEAR:
        {
            if (IsObjectHostile(OBJECT_SELF,GetEventObject(ev,0))
             && OBJECT_SELF != GetMainControlled())
             //              && !IsPartyMember(OBJECT_SELF)
            {

Rubber_GoHome - this will make laugh, but I am using both types of commands move the archers, ambient out of combat, and rubber commands in combat...I realize there is probably another way, but getting this working has produced a cool behavioural pattern, and is forcing me to solve & understand a bunch of issues which I think will help as I progress...

AI_CUSTOM_AI_ACTIVE - I might be mixed up, but I am using "hirecustomfollower" from the follower tutorial, and I think, to make that work, all my followers had to have AI_CUSTOM_AI_ACTIVE set...but I could be mistaken - it's been a while since I mucked with party stuff. I stopped excluding them from the perception fix.

Performace - I've been tightening condintionals in general, and, using Light AI as much as possible...seems to help...beyond that - I suspect my fireballs are creating some sort of race condition, somtimes...it's the only thing that makes sense - I just need to figure out why and where it's happening.


ps - updated the script a couple of posts back...

Modifié par RecklezzRogue, 18 avril 2010 - 05:44 .

[RecklezzRogue]

Some observations -

Perception Fix -

The event intercept script is working well, but it modifies the flow of combat - I actually really like the impact, the battle moves around a lot. Attacker engages, then disengages and attacks someone else most of the time an EVENT_TYPE_PERCEPTION_DISAPPEAR happens.

The only downside is that the oPC will stop physically chasing an NPC if it updates its threat table and changes targets - for example, you attack an NPC, between that attack and your next, the NPC updates his threat table and moves to engage someone else - the oPC does not follow unless you select an ability, like riposte, or shield bash, in which case the oPC will move to engage. I am ok with this as it creates a different battle flow - but it's a lil weird.

Performance -

I seem to have my performance issues licked by doing the following:

- Eliminated all 'Display Floaty Messages' I was using for debug.
- Set the majority of the NPC's AI_LIGHT_ACTIVE to 1
- Rationed high ranks among groups (reducing high ranks on both sides)
- Kept number of combatants at any one time just below a max of 22 or 23.
- Made all Triggers self destruct after use
- Generally tightened all conditions to reduce calls as much as possible

So, the battle mechanics and flow are now working as desired - and even better with fluid motion of any given battle rocking from one side of the map to the other. This was observered with a Rogue and a Warrior of oPC - trying mage now. Fire balls are working 95% of the time (as in no delays).

Basically - the event script is as posted a few posts up. The only diff (i think) is that I am no longer excluding oPC from the perception fix.

UPDATE - Tested mage with lots of AOE and all's well...finally...everything works

Modifié par RecklezzRogue, 20 avril 2010 - 01:52 .

[RecklezzRogue]

UPDATE ---

It would appear that the Event intercepts are only required when pushing the performance envelope...I just did a couple of test while trying to figure out how to intercept events ONLY for my module...as part of that process, I eliminated the override, and guess what - everything works fine...everyone fights to the last man...(i have not checked fireballs before combat - about to do that). Anyway - I have some more work to do to profile this, but in case anyone is using this thread for help, I wanted to get this update out...more to come...

ps - I resolved all my performance issues after setting up the event intercepts...and since then this is the first I tested without event intercepts...I do suspect fireballs may still cause issues with NPC's that are not yet hostile, and moving to a trigger to become hostile (before they would just stand there after the fireball - checking that out now).

UPDATE --

In order to control when the following script actually intercepts events, I have done the following (thanks to some help form David Sims in another thread)

RecklezzRogue said..

David - thank you - you got me there - I can now do event intercepts, without impacting (in any noticeable way) other modules...here's what I did in the end:


1 - created a 2da override for var_module wherein the variable DMO001_EVENT_INTERCEPT is defined as an int with a default value of '0'


2 - used Manage Modules/Properties/Variables to set DMO001_EVENT_INTERCEPT to '1'


3 - check for value of DMO001_EVENT_INTERCEPT in my events override script as follows:


        case EVENT_TYPE_PERCEPTION_DISAPPEAR:
        {
            // If this isn't Dark Alliances, bail to default handler
            //
            object oModule = GetModule();
            if (GetLocalInt(oModule, "DMO001_EVENT_INTERCEPT") == 0)
            {
                HandleEvent(ev,RESOURCE_SCRIPT_CREATURE_CORE);
            }



4 - Placed my engineevents.gda, my var_module.gda, dmo001_event_intercept.nss & ncs in ../addin/core/override



And everything works...now I'll post this where someone trying to solve this will find it - clearly the wrong thread now that I found the root cause...

THANK YOU!

Following is the latest, and fully functional, event override script:

// Event Intercept Script to solve NPC behaviour problems
//
// File: dmo001_event_intercept.nss
// Module: Dark Alliances
// Sources: code from Magic (Bioware Social) & DA Builder Wiki
// Sources: David Sims forum assistance with module variables vs. constants ;-)
// Author: RecklezzRogue
// Date: 5-5-2010
// Revision 0.11
#include "utility_h"
#include "wrappers_h"
#include "events_h"
#include "sys_ambient_h"
#include "ai_main_h_2"

void main()
{
    event ev   = GetCurrentEvent();
    int nEvent = GetEventType(ev);
    object oOwner = GetEventObject(ev,0);
    object oHero = GetHero();
    int bEventHandled = FALSE;
//    DisplayFloatyMessage(GetHero(), "Event Intercept Called", FLOATY_MESSAGE, 16777215,5.0); //Debug
   
    switch (nEvent)
    {
        // If a hostile creature disappeared, update the threat table with the
        // remaining perceived enemies.
        //
        // This code solves the problem of NPC's standing and taunting in combat
        // mode, but not attacking visible combatant hostiles unless they are
        // directly attacked
        //
        case EVENT_TYPE_PERCEPTION_DISAPPEAR:
        {
            // If this isn't Dark Alliances, bail to default handler
            //
            object oModule = GetModule();
            if (GetLocalInt(oModule, "DMO001_EVENT_INTERCEPT") == 0)
            {
//                DisplayFloatyMessage(GetHero(), "Event Int Exit - Line 42", FLOATY_MESSAGE, 16777215,5.0); //Debug
                HandleEvent(ev,RESOURCE_SCRIPT_CREATURE_CORE);
            }
            //Perception Fix Follows
            //
            if ((IsObjectHostile(OBJECT_SELF,GetEventObject(ev,0)))
             && OBJECT_SELF != GetMainControlled()
              && !IsPartyMember(OBJECT_SELF))
            {
//                DisplayFloatyMessage(GetHero(), "Event Int - Perception", FLOATY_MESSAGE, 16777215,5.0); //Debug
                int i;
                object[] oEnemies = GetNearestObjectByGroup(OBJECT_SELF,TRUE,OBJECT_TYPE_CREATURE,AI_THREAT_SIZE,TRUE,TRUE);
                int nEnemyCount = GetArraySize(oEnemies);
                if (GetThreatTableSize(OBJECT_SELF)<nEnemyCount)
                {
                        for (i = 0; i<nEnemyCount; i++)
                        {
                            if (GetThreatValueByObjectID(OBJECT_SELF,oEnemies[i])==0.0)
                            {
                                AI_Threat_UpdateEnemyAppeared(OBJECT_SELF,oEnemies[i]);
                            }
                        }
                 int bEventHandled = FALSE;
                }
                else
                HandleEvent(ev,RESOURCE_SCRIPT_CREATURE_CORE);
            }
         break;
        }
        // NPC's Re-engage after an AOE effect (fireball, freeze, etc)
        //
        // This solves the problem of NPC's disengaging from combat
        // after recoveing from an AOE attack, especially Fireballs.
        //
        case EVENT_TYPE_COMMAND_COMPLETE:
        {
            // If this isn't Dark Alliances, bail to default handler
            //
            object oModule = GetModule();
            if (GetLocalInt(oModule, "DMO001_EVENT_INTERCEPT") == 0)
            {
            HandleEvent(ev,RESOURCE_SCRIPT_RULES_CORE);
            }
            // Creature finished the ExecuteEffect command
            //
            if ((GetEventInteger(ev,0)==32) && (bEventHandled == FALSE)
             && !IsPartyMember(OBJECT_SELF)
              && OBJECT_SELF != GetMainControlled())
            {
//                DisplayFloatyMessage(GetHero(), "Event Int - EV = 32", FLOATY_MESSAGE, 16777215,5.0); //Debug
                WR_ClearAllCommands(OBJECT_SELF,TRUE);
                AI_DetermineCombatRound();
                int bEventHandled = TRUE;
            }
            // The following code makes sure that NPC's go home after the battle
            // Using this means that you will need to use commands that
            // Rubber_SetHome (like UT_Quickmove) to keep NPC's at waypoints.
            // This code also accomodates Ambient move patterns, but those with
            // active move patterns still risk being stuck after battle...
            //
            else if (GetCommandType(GetCurrentCommand(OBJECT_SELF))==COMMAND_TYPE_INVALID
             && GetCommandQueueSize(OBJECT_SELF)==0
              && !IsPartyMember(OBJECT_SELF)
               && OBJECT_SELF != GetMainControlled())
            {
                DisplayFloatyMessage(GetHero(), "Event Int - EV = RGH", FLOATY_MESSAGE, 16777215,5.0); //Debug
                // Issue Rubber_GoHome and Ambient_Start if not fighting, not at
                // home wp, event not handled, and there is no ambient move
                // pattern variable set (other than 0 or FALSE), and the Ambient
                // system is enabled (the creature associated with the event)
                //
                // Adding conditional for PartyMembers...(must be false)
                //
                if (!GetCombatState(OBJECT_SELF)
                  && GetDistanceBetweenLocations(GetLocation(OBJECT_SELF),Rubber_GetHome())>1.0
                   && bEventHandled == FALSE
                    && !GetLocalInt(OBJECT_SELF, AMBIENT_MOVE_PATTERN)
                     && !IsPartyMember(OBJECT_SELF)
                      && OBJECT_SELF != GetMainControlled())
                {
                    Rubber_GoHome();
                    int bEventHandled = FALSE;
                }
                else
                HandleEvent(ev,RESOURCE_SCRIPT_RULES_CORE);
                if (GetLocalInt(OBJECT_SELF,AMBIENT_SYSTEM_STATE) & AMBIENT_SYSTEM_ENABLED
                  && bEventHandled == FALSE
                   && !GetCombatState(OBJECT_SELF)
                    && !GetLocalInt(OBJECT_SELF, AMBIENT_MOVE_PATTERN)
                     && !IsPartyMember(OBJECT_SELF)
                      && OBJECT_SELF != GetMainControlled())
                {
                    Ambient_Start();
                    int bEventHandled = TRUE;
                }
                else
                HandleEvent(ev,RESOURCE_SCRIPT_RULES_CORE);
            }
            break;
        }
    }
    if (!bEventHandled)
    {                                                                        
      HandleEvent(ev); // pass to the event to the default handler for Event
    }
}
// --- script end ---

 

Modifié par RecklezzRogue, 06 mai 2010 - 08:48 .

[RecklezzRogue]

got a bug...maincontrolled() won't leave combat mode...

Script fixed above...any more work I do on this will be back over here (i keep updating both threads...egadz..)

http://social.biowar...1/index/2094315

Modifié par RecklezzRogue, 06 mai 2010 - 09:23 .