22 réponses à ce sujet

[Shadooow]

Hey, anyone else saw this issue already? In the module Im maintaining (cca 100 areas, not many placeables per area) there is script to automatically lock and close doors. While lock works well (not an action), closing doors may take instead of ten seconds 30, sometimes more. I didn't paid attention to this as it wasn't much important for me but yesterday I found out it also affects projectile traps which is very bad.

I tried to clean the module a lot (remove scripts from static immortal npcs in area, remove cep heartbeat light script etc.) but nothing helped yet and I really don't know what can even caused this. The module itself run fine, lags are very rare and mostly related to hording monsters and spamming aoe and AOE spells.

[lordofworms]

mine does that alot, especially any doors with script actions on them..
player clicks door, nothin, clicks again, nothin...only after a few seconds (usually 10-15) the door will then open. I am alos unaware of whats causing it, I just associated it with traffic (my server doesnt lag much but at all but this still occurs.)
so basically I can't help you, but your not alone.

[Izk The Mad]

@ShadoOow, did you figure this out yet?

I'm not sure if the problem I had is the same as what you're talking about, but in my module I had several instances where I wanted to do door actions fired from a trigger, like locking/unlocking, or in a couple instances have the door slam and lock right in the player's face, so to speak. Even had several automatic doors like at a store, that opened and closed as the player entered/exited the trigger around it. At first it didn't work fast enough at all.

My workaround was to place an invisible object right in the doorway, and have the trigger send the command to it, and it would close the door instead of having the door close itself. The door closed instantly. I think doors just don't react as fast to the scripted actions the way other objects do. I seem to recall reading something about that on the old forums.

I'm pretty sure I had set up some sort of generic system, where I could reuse the same scripts by using GetTag() and making the door's tag part of the closer placeable's tag and the trigger's tag, instead of unique scripts for each door. If you should decide to try this, be sure to set the placeable to plot, and make it non-static.

I don't know what to say about the projectile traps. Never had any issues with them. It's been a while since I did any of this stuff so forgive me if I'm wrong about this, but IIRC, if you're using the default scripts, are you giving them all unique tags? I think that's faster than letting it find the nearest origin object. *a little fuzzy on that bit*

I hope some of that helps.

Modifié par Izk The Mad, 11 janvier 2012 - 06:24 .

[Rolo Kipp]

<getting slowly to...>

lordofworms wrote...
mine does that alot, especially any doors with script actions on them..
player clicks door, nothin, clicks again, nothin...only after a few seconds (usually 10-15) the door will then open. I am alos unaware of whats causing it, I just associated it with traffic (my server doesnt lag much but at all but this still occurs.)
so basically I can't help you, but your not alone.

I've d/l'd the Arbor Falls from the Vault and run it now and then. I can say very definitely that the boulder-door to the caverns takes so long on my poor machine that I have never managed to get inside it :-P About 30-60sec until the dialog shows up and I've waited perhaps 2 mins for the stone to drop before giving up.

No real problem online on your server, LoW. But running it SP on this old box is problematical.

<...the point>

[DMSelena]

This may or may not be related, but, doors always take forever to load up when editing them in toolset. I have tried over the years to fix this, and never found a way. I always assumed there was something in the Bioware hardcode that was bugged when it came to the engine's dealings with doors. Doesn't seem like a far stretch to think that this lag extends to the mod when it's running in game.

I realize this remark may or may not be at all helpful and/or relevant.

- S.

[Shadooow]

DMSelena wrote...

This may or may not be related, but, doors always take forever to load up when editing them in toolset. I have tried over the years to fix this, and never found a way. I always assumed there was something in the Bioware hardcode that was bugged when it came to the engine's dealings with doors. Doesn't seem like a far stretch to think that this lag extends to the mod when it's running in game.

I realize this remark may or may not be at all helpful and/or relevant.

- S.

you sure you dont have any haks/override especially CeP? by default its not any slower than placeable

also since placeable seems to be affected by this issue as well none of the tips in this thread prove to be useful unfortunately

Modifié par ShaDoOoW, 11 janvier 2012 - 11:54 .

[wyldhunt1]

Is it only the animation itself that is lagging or the entire script?
IE If you add a line of code to the door close script to tell the player when the door should close, are you getting that info when the door should close, or when the door actually closes?

Are you running the code to close/lock the doors via OnDisturbed or HB or other?
If you alter the code to work from a different event, does it seem to help?

If you add a line to your door hb script to log a timestamped log entry every time a door hb fires, how often is it actually firing?

I'm also curious if this could have some connection to the doors taking forever to load in the toolset.
Is there something about doors that require a large chunk of resource somehow?

Is it possible that door/placeable events are somehow given a lower priority than other events in the call stack?

@ShaDoOoW
Are you using a lot of doors in your mod (With or without transitions)?
Could it be directly related to how many doors are in the mod?

Hmm...
Alright.... I'm out of questions.
At the very least, it'd be nice to figure out what causes this so that we can try to avoid it in larger mods.

[wyldhunt1]

@ ShaDoOoW
We do use CEP.
A bit off topic, but...
Is the extra slow door properties opening in the toolset caused by the large number of doors in CEP, or did they break something?

Modifié par wyldhunt1, 12 janvier 2012 - 12:02 .

[Shadooow]

its any action called by door or placeable, script is in OnOpen but in case of projectile placeables its in OnEnter of the trigger.

doors in this module are running ActionCloseDoor afterten seconds, but due to this issue it takes rather around twenty seconds

as I said earlier it also affects placeables. Since projectile traps are using ActionCastSpell this is delayed by a lot.

The module has around 500 areas, though I wouldnt said its crowded by doors however all doors are connected to each other (in my personal never finished PW I always use waypoint, but I have only around 50areas)

wyldhunt1 wrote...

@ ShaDoOoW
We do use CEP.
A bit off topic, but...
Is the extra slow door properties opening in the toolset caused by the large number of doors in CEP, or did they break something?

I didnt said that. Just that in empty module without haks its almost instant. Might be 2DA issue, might be CEP related or maybe its indeed about how many doors are in module (though I dont see there much logic) but I have not proof for this.

[Pstemarie]

I wonder if it has anything to do with the fact that several of the BioWare doors (and placeables) are missing animation keys - making the engine have to fill in the gaps on the fly. However, this wouldn't explain why its affecting triggers as well...

Modifié par Pstemarie, 12 janvier 2012 - 09:15 .

[wyldhunt1]

Izk the Mad's workaround is to use triggers. I don't think it's the actual trigger.
If it can be fixed by a trigger telling something else to close a door, then the problem is... strange.
Judging by the posts so far, it only appears to affect things that directly trigger an animation?
Does this also affect the time it takes for chests to open? It seems like it should.

In fact, can someone else with this problem try Izk's workaround on a door to see if it works?
It may be some type of a clue if a script ordering something to close a door happens faster than a PC triggering the code themselves.

Modifié par wyldhunt1, 12 janvier 2012 - 06:44 .

[Shadooow]

wyldhunt1 wrote...

Izk the Mad's workaround is to use triggers. I don't think it's the actual trigger.
If it can be fixed by a trigger telling something else to close a door, then the problem is... strange.
Judging by the posts so far, it only appears to affect things that directly trigger an animation?
Does this also affect the time it takes for chests to open? It seems like it should.

In fact, can someone else with this problem try Izk's workaround on a door to see if it works?
It may be some type of a clue if a script ordering something to close a door happens faster than a PC triggering the code themselves.

The issue itself is not in animation but in action. Every action performed by door or placeable, even ActionSpeakString is slowed down with this issue. So yes it also affects chests when the command to open/close is called from scripts. The action performed by player ingame (and ActionOpenDoor assing to NPC/PC by script cause NPC/PC to walk to doors and open it, however they need proper key, and action fails when door is locked/trapped) is instant as it is not performed by the door/placeable but by player.

I tried the trigger workaround and it works, however the trigger must be in current area otherwise its slowed the same way as when door tried to close themselves. Unfortunately neither area or bioware spawn encounter seems to be able to perform ActionCloseDoor action neither trigger can perform ActionCastSpell action so this workaround cannot be used for projectile traps unfortunately.

I would like to find the cause and fix the cause in the root preferably as the trigger workaround is really not viable for me. So far I tried to remove all scripts from module, custom 2das etc. but issue still remained.

[Failed.Bard]

Do doors have action queues? Has anyone tried a ClearAllActions call first to see if that affects this issue, it's a bit of a longshot but likely worth trying.

[Rolo Kipp]

<thoughtfully stroking...>

ShaDoOoW wrote...
...
I tried the trigger workaround and it works, however the trigger must be in current area otherwise its slowed the same way as when door tried to close themselves. Unfortunately neither area or bioware spawn encounter seems to be able to perform ActionCloseDoor action neither trigger can perform ActionCastSpell action so this workaround cannot be used for projectile traps unfortunately.
...

Just from reading this thread (especially the clue that the trigger must be in the same area) and my own experiences with Arbor Falls SP, it appears to me that it may have something to do with AI level of detail... From CISC 877 Video Game Development by T.C. Nicholas Graham (Winter 2011)

CPU Time        classification
60%             Player Characters
24%             Creatures fighting or interacting with PC
10%             Creatures within 50m of a PC
04%             Creatures in same large-scale area as PC
02%             Creatures in areas without PC

I'm wondering where in that hierarchy script-generated actions fall.

<...his beard>

Modifié par Rolo Kipp, 13 janvier 2012 - 07:30 .

[wyldhunt1]

That's an interesting thought.
As far as creatures go, you can adjust where they fall on that scale with SetAILevel(Or whatever that command is...). By default, creature AI gets knocked down lower when no PC's are in the area and such...
However, I've no idea where placeables fall on that list, or how to control it.

It may be a potential bug where they coded the action functions to follow that list of yours, which would mean that the action scripts may fire faster when there is a creature and a PC nearby. Especially a hostile creature chasing a pc...
It would be an odd bug for them to make such an assumption about action scripts, but I've seen worse.

[Shadooow]

Failed.Bard wrote...

Do doors have action queues? Has anyone tried a ClearAllActions call first to see if that affects this issue, it's a bit of a longshot but likely worth trying.

they have but their action queve is clean, clear actions was my first thought too, unfortunately no effect

[Failed.Bard]

  If the issue may be that it's an action, skip the ActionCloseDoor entirely.  I just tested this with a door, and it worked, at least in my test right at 10 seconds.  For dual placeable/door use you'd need an object check assigning the proper placeable or door animation before running it, but that's simple enough.

void main()
{
 DelayCommand (10.0, PlayAnimation (ANIMATION_DOOR_CLOSE));
 DelayCommand (10.0, SetLocked (OBJECT_SELF, TRUE));
}

[wyldhunt1]

I'm not sure if that'll help with the rest of the placeables and traps though.

[Shadooow]

Failed.Bard wrote...

  If the issue may be that it's an action, skip the ActionCloseDoor entirely.  I just tested this with a door, and it worked, at least in my test right at 10 seconds.  For dual placeable/door use you'd need an object check assigning the proper placeable or door animation before running it, but that's simple enough.

void main()
{
 DelayCommand (10.0, PlayAnimation (ANIMATION_DOOR_CLOSE));
 DelayCommand (10.0, SetLocked (OBJECT_SELF, TRUE));
}

perfect, I havent realized there is different way how to open or close doors

since this solution doesnt need anything it is very suitaible for the door issue, though its not a fix but a workaround

still need something for projectile traps

[Failed.Bard]

ShaDoOoW wrote...

Failed.Bard wrote...

  If the issue may be that it's an action, skip the ActionCloseDoor entirely.  I just tested this with a door, and it worked, at least in my test right at 10 seconds.  For dual placeable/door use you'd need an object check assigning the proper placeable or door animation before running it, but that's simple enough.

void main()
{
 DelayCommand (10.0, PlayAnimation (ANIMATION_DOOR_CLOSE));
 DelayCommand (10.0, SetLocked (OBJECT_SELF, TRUE));
}

perfect, I havent realized there is different way how to open or close doors

since this solution doesnt need anything it is very suitaible for the door issue, though its not a fix but a workaround

still need something for projectile traps

  I didn't know you could either, I had to look at the animations constants to even see if it'd work with PlayAnimation since I didn't know if door and placeable animations could work with the standard call.
  I'd actually been planning to test out how well DoDoorAction and DoPlaceableObjectAction worked in comparison to ActionCloseDoor, but wanted a non-action based alternative to those to try as well.

[Shadooow]

Update:

I found wrong behavior of the "PlayAnimation (ANIMATION_DOOR_CLOSE)" method of closing doors. This method does not fire OnClosed event and does not automatically close connected doors.

[henesua]

 Yes, you have to close both doors. Here's a snippet from my code that doesn't allow possessed familiars to open doors.

object oDoor     = OBJECT_SELF;
object oDest     = GetTransitionTarget(oDoor);

PlayAnimation(ANIMATION_DOOR_CLOSE);
if(GetObjectType(oDest)==OBJECT_TYPE_DOOR)
{
    AssignCommand(oDest, PlayAnimation(ANIMATION_DOOR_CLOSE));
}

[Failed.Bard]

ShaDoOoW wrote...

Update:

I found wrong behavior of the "PlayAnimation (ANIMATION_DOOR_CLOSE)" method of closing doors. This method does not fire OnClosed event and does not automatically close connected doors.

  I don't think there's a non-nwnx method of checking what scripts an object has, but if you're always using the same named OnClosed script with the OnOpen one, you can just execute it manually.  Otherwise, it'd be a messy work-around needed involving storing the OnClosed event script name as a variable on the door.