Author Topic: Persistent merchants?  (Read 996 times)

Baaleos

  • Administrator
  • Hero Member
  • *****
  • Posts: 1916
  • Karma: +0/-0
Persistent merchants?
« Reply #15 on: April 27, 2015, 06:00:01 pm »


               

The reason I mentioned Memory - is because i think I read years ago on the old lexicon or old forums something around the reasoning of why AI Scripts are able to generate TMI, even if they themselves are small.


 


It was something to do with a 'memory' limit (perhaps it wasn't memory) : being hit across the different entities that were calling the same script.


 


Eg: 500 NPC's all calling the same script: I experienced this when I had 30 npc's who suddenly tried to summon minions at the same time.


Each one would be its own individual ExecuteScript call - in essence, but it was something like too many instructions in too short a time for that one script.


               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Persistent merchants?
« Reply #16 on: April 27, 2015, 08:42:47 pm »


               

@WhiZard: Wow, okay. That makes my head hurt... ':blink:'  I'll have to poke at that.  


As to the seven levels, yes I've hit that. It sucks because there is no error. I'd love it if there was a TML (too many levels) error instead of the undefined results caused by not actually executing the script you get now '<img'>


@Baaleos: I bet those AI scripts have lots of GetNearestObject/Creature loops (or other loops that depend on the number of nearby objects/creatures, number of effects on the objects etc) in them. It does not take a large script to get to TMI, just a lot of objects to loop over.


 



               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Persistent merchants?
« Reply #17 on: April 28, 2015, 02:11:33 pm »


               

To completely finish hijacking Surek's thread...


 


@WhiZard


No, SignalEvent gets resolved within the script (as does the OnDamaged script if applying damage without a delay).

 



 


This is not born out by my testing for general SignalEvent calls. I did not have a lot of time so did not explicitly test the EffectDamage path.


I did two tests. The first was simply having a lever onused event something like this :



void main() {
    SendMessageToPC(GetFirstPC(), "Starting signal event");
    SignalEvent(GetObjectByTag("TESTME1"), EventUserDefined(501));
    SendMessageToPC(GetFirstPC(), "Done with signal event.");
}

The userdefined event handler on TESTME1 just prints a message saying it got an event.


 


The results were:


      Starting signal event


      Done with signal event


      TESTME1 got event


 


If it worked the way you described the "TESTME1 got event" line would have been in the middle.


 


Test 2 was similar but I had TESTME1 send the event to TESTME2 when it got the first event. TESTME2 then sent it right back, creating a loop of two objects sending each other events as fast as possible, no delays. If this was all happening it the context of the original script this loop would have stopped with a TMI. Instead the CPU was pegged and the game completely stopped until I killed nwmain.


 


Interestingly in this case none of the messages printed. It must have tied up the server before the client side could do anything. This was single player so it was all the same process.


               
               

               
            

Legacy_WhiZard

  • Hero Member
  • *****
  • Posts: 2149
  • Karma: +0/-0
Persistent merchants?
« Reply #18 on: April 28, 2015, 04:29:22 pm »


               


To completely finish hijacking Surek's thread...


 


@WhiZard


 


This is not born out by my testing for general SignalEvent calls. I did not have a lot of time so did not explicitly test the EffectDamage path.


I did two tests. The first was simply having a lever onused event something like this :



void main() {
    SendMessageToPC(GetFirstPC(), "Starting signal event");
    SignalEvent(GetObjectByTag("TESTME1"), EventUserDefined(501));
    SendMessageToPC(GetFirstPC(), "Done with signal event.");
}

The userdefined event handler on TESTME1 just prints a message saying it got an event.


 


The results were:


      Starting signal event


      Done with signal event


      TESTME1 got event


 


If it worked the way you described the "TESTME1 got event" line would have been in the middle.


 


Test 2 was similar but I had TESTME1 send the event to TESTME2 when it got the first event. TESTME2 then sent it right back, creating a loop of two objects sending each other events as fast as possible, no delays. If this was all happening it the context of the original script this loop would have stopped with a TMI. Instead the CPU was pegged and the game completely stopped until I killed nwmain.


 


Interestingly in this case none of the messages printed. It must have tied up the server before the client side could do anything. This was single player so it was all the same process.




 


Thanks.  I modified the fireball spell to get rid of the DelayCommands() and then had "SPELL" returned for the OnSpellCastAt event and "DAMAGE" returned for the OnDamaged event.  I marked "Fireballstart" and "Fireballend" for each creature in the loop and got the following return.


 


Fireballstart


DAMAGE


Fireballend


Fireballstart


DAMAGE


Fireballend


SPELL


SPELL


 


So it looks like Signal event does delay to after script execution, while the applying EffectDamage() does not.


               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Persistent merchants?
« Reply #19 on: April 28, 2015, 06:44:38 pm »


               

Cool! That hurts less '<img'>


 


Thanks. Now I don't have to do that one.  I'm not too surprised they are different. One is an explicit raising of an event while the other is applying an effect which has a side effect of calling one of the creatures scripts. That is, I don't think of ApplyEffect(EffectDamage()) as synonymous with SignalEvent(EventOnDamaged()) - if there was such a thing.  Good to know... OnDamaged script is not the place to do heavy lifting.



               
               

               
            

Legacy_Valgav

  • Full Member
  • ***
  • Posts: 118
  • Karma: +0/-0
Persistent merchants?
« Reply #20 on: April 28, 2015, 10:21:19 pm »


               

I've read whole topic and i have question?


 


I need to run few scripts on some intervals for example every time when module change hour. 


 


Is it better to use signal event or ExecuteScript +/- delay?


 


My scripts are quite big and have lot stuff to do.



               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Persistent merchants?
« Reply #21 on: April 29, 2015, 01:16:51 am »


               

As long as you do the ExecuteScript in a delay (even 0.0) it probably does not matter.  Both cases will give you a full instruction limit script execution environment. Personally, I like ExecuteScript for this because it keeps things compartmentalized without needing to be in include files or in a really big userdefined handler scripts. If I signalled an event on the module for hours passing I'd probably end up having the userdefined event handler


ExecuteScript the work anyway.


 


Also if you had several unrelated things to do every hour you could spread them out a bit with different delays so they don't all fall right on the heartbeat.