Rumours spread this script fires only for PC heartbeat, but lately I decided to use it, PC heartbeat was great opportnity to save persistent info about PC. But when I looked into database, I saw strange values so I made few debugs and guess what, any trap made via scripting, fires default script every 6seconds...
Yes you can add [nwscript] if(!GetIsPC(OBJECT_SELF))return;[/nwscript] but I think pseudoheartbeat will be much "clean" way to do this afterall...
default script caution
Débuté par
Shadooow
, juil. 14 2010 03:55
#1
Posté 14 juillet 2010 - 03:55
#2
Posté 14 juillet 2010 - 09:25
Traps fire the script titled "default"? Intresting, you could do the if not pc return OR use that to do specials with trap IE:
if not a PC(assume is trap) and do this
if is PC do this other thing
if not a PC(assume is trap) and do this
if is PC do this other thing
#3
Posté 15 juillet 2010 - 01:13
I wonder if the trap was named 'default' and it triggered the script through 'tag based scripting'.
Just an idea. I'll give this a test when I get time.
Just an idea. I'll give this a test when I get time.
#4
Posté 15 juillet 2010 - 02:01
First I dont use tag based scripting.ElgarL wrote...
I wonder if the trap was named 'default' and it triggered the script through 'tag based scripting'.
Just an idea. I'll give this a test when I get time.
Second, traps cant trigger tag based scripts, because tag based script are in OnPlayer events - (un)equip,(un)acquire,activate.
Third those traps created via CreateTrapAtLocation (guess those on object dont do that) had tag = "" (null).
#5
Posté 16 juillet 2010 - 01:26
I have alway been afraid something like that would happen. Ever since I heard about people useing the defualt script I have wondered about what strange things could happen or what other places bioware my have placed 'default' as the name of a script not filled in. Axe seemed to clear the use of the script for PC heart beat. But if it is running on some other objects also I think I would advoid it for sure. I agree the use of the pseudo heart beat of a known overhead value. Is better then an unknown overhead value checking to make sure it is a PC and a script running on other objects.
just my 2 cents again.
Edit: oh If you did happen to put a script in the HB of the traps, even if it was a blank script, Then it would no longer run the Default script as its HB. another messy solution to the problem. lol
just my 2 cents again.
Edit: oh If you did happen to put a script in the HB of the traps, even if it was a blank script, Then it would no longer run the Default script as its HB. another messy solution to the problem. lol
Modifié par Lightfoot8, 16 juillet 2010 - 01:29 .
#6
Posté 19 juillet 2010 - 01:41
Those traps were 1.69 additions and it isn't surprising they implemented it that way. Wish they would have used a different script name than default so it wouldn't interfere, but oh well. This isn't a problem at all tho because for one thing there is no default script. So the standard behavior is to do nothing. Therefore all you have to do is have the "default" script verify OBJECT_SELF is a PC and you can ignore the trap bit. Of course if you want to hook into the trap or clones too, then you can do something like this in your "default" script:
[dascript]// default Script - player heartbeat, player clone events, scripted traps
void main()
{ if( GetIsPC( OBJECT_SELF ) ) ExecuteScript( "player_heartbeat", OBJECT_SELF );
else if( GetObjectType( OBJECT_SELF ) == OBJECT_TYPE_CREATURE )
ExecuteScript( "pc_clone_event", OBJECT_SELF );
else ExecuteScript( "trap_event", OBJECT_SELF );
}[/dascript]
Once you create three scripts for default "player_heartbeat", player clone events "pc_clone_event", and "trap_event" you can use them to hook into all types of objects separately. And of course if you don't create one of these scripts you'll simply get the standard behavior for that.
[dascript]// default Script - player heartbeat, player clone events, scripted traps
void main()
{ if( GetIsPC( OBJECT_SELF ) ) ExecuteScript( "player_heartbeat", OBJECT_SELF );
else if( GetObjectType( OBJECT_SELF ) == OBJECT_TYPE_CREATURE )
ExecuteScript( "pc_clone_event", OBJECT_SELF );
else ExecuteScript( "trap_event", OBJECT_SELF );
}[/dascript]
Once you create three scripts for default "player_heartbeat", player clone events "pc_clone_event", and "trap_event" you can use them to hook into all types of objects separately. And of course if you don't create one of these scripts you'll simply get the standard behavior for that.
Modifié par Axe_Murderer, 19 juillet 2010 - 01:56 .
#7
Posté 19 juillet 2010 - 03:33
Question is, if its efficient anymore. When I believed it runs only for PC, it was OK, I assume my module could have max 15 players at once, so default script will fire in average rate of 7times per 6secons, but since it runs for traps as well, atm I have 6dungeons which spawns about 10 traps, now thats 60times per 6seconds. And thats only start, I will have more dungeons and more random traps. No matter if the default script will handle it with simple conditional, the script is fired hence I think its more efficient to use pseudo heartbeat.
Btw was that pseudo heartbeat memory blobbing fixed? If not please copypaste original thread from old forums.
Btw was that pseudo heartbeat memory blobbing fixed? If not please copypaste original thread from old forums.
Modifié par ShaDoOoW, 19 juillet 2010 - 03:33 .
#8
Posté 19 juillet 2010 - 03:46
Well it shouldn't be any worse than it was before in terms of the cloning and pc heartbeat. Basically if you don't clone players you don't get the events. Likewise, unless you use scripted traps very often, the difference won't be even noticable.
The script I posted above is very minimal and allows you to efficiently separate them out, but you're right if scripted traps are all over the place, the event will fire more often. Personally I wouldn't worry about it too much until you start trying to do lots of stuff on trap events or player hb. Traps aren't something likely to fire it so much more often as to cause a problem since they are stationary and small. As with all events, if you try to do too much you will suffer. But only testing will tell for sure what the tolerable threshold is.
The script I posted above is very minimal and allows you to efficiently separate them out, but you're right if scripted traps are all over the place, the event will fire more often. Personally I wouldn't worry about it too much until you start trying to do lots of stuff on trap events or player hb. Traps aren't something likely to fire it so much more often as to cause a problem since they are stationary and small. As with all events, if you try to do too much you will suffer. But only testing will tell for sure what the tolerable threshold is.
#9
Posté 19 juillet 2010 - 06:12
1.69 introduced quite few changes I have not liked, and while not knocking the update, I'll say that, it's not something I didn't have to do a lot of reworking to get it to do what I wanted it to, all in all CEP 2.3 & 1.69 have only been a headache for me as a builder.... Enough said
Hi shadoOow XD long time no see mate...
Hi shadoOow XD long time no see mate...





Retour en haut







