Author Topic: Problem with petrified creatures  (Read 509 times)

Legacy_Ali Akabba

  • Newbie
  • *
  • Posts: 10
  • Karma: +0/-0
Problem with petrified creatures
« on: January 29, 2012, 05:24:04 am »


               I'm having a problem with statues created from petrified creatures. I've seen other threads on how to do it, and the basic idea is simple enough: using either the petrification effect or a combination of the stoneskin visual effect and freezed animations to turn a creature into a statue. There are a few script variations, but they usually work fine, actually, in the sense that a statue is created as intended. So the problem I have is not about creating a statue in this manner, but has to do with the way it looks.

Here is the problem: when a PC sees the creature, i.e., when the creature gets into the PC's range of vision and starts to appear, it begins by showing up with stretchted legs and open arms, forming a cross, similar to the Christ Redeemer statue in Rio (google an image of it and you'll see what I mean). Then the creature quickly assumes a more natural posture. This process happens fast and, usually, is quite irrelevant. However, it affects how the pretrified creature is shown in the screen (at least for me). For example, if a creature is petrified right on spawn and only later a PC gets near enough to see it, it is already petrified before starting to appear. Then, it gets freezed at the very first posture at which the creature starts appearing - the unnatural cross, Christ Redeemer-like posture. So the statue is generated as intended, but in a horrible, unnatural posture. Oddly, if the PC walks away just enough for the statue to get out of visual range and returns immediately, the creature finishes the process of getting to a natural position and then the statue looks good.

I think I understand what the problem is: the petrification effect should take place after the creature has assumed a natural posture. However, the brief transition from the very first, cross-looking posture to a natural one is treated as an animation and is suspended midway by the petrification effect, so the the creature does not have a chance to finish getting to a natural, good-looking posture. So the problem is related to how the creature starts appearing when it gets into the visual range of a PC.

I tried to avoid this problem by playing with the OnSpawn, OnPerception and OnHeartbeat events, but so far nothing I tried worked. I see a statue, but it may or may not be at the cross posture, depending on how the PC approaches it.

I'm using a hill giant, by the way, but I doubt the problem is related to the particular creature.

Any ideas of how to deal with this? I feel like I'm running out of options.

Thanks in advance.
               
               

               
            

Legacy__six

  • Hero Member
  • *****
  • Posts: 1436
  • Karma: +0/-0
Problem with petrified creatures
« Reply #1 on: January 29, 2012, 08:33:23 am »


               Depending on whether you want to require a custom hakpak for your module, it'd be relatively simple to make your own custom placeable statue with a stone texture (or get someone else to do it for you), which would also be more efficient and less liable to change pose unreliably if you walk away and come back (a la Doctor Who, or whatever that episode with the statues stole its ideas from in the first place)
               
               

               
            

Legacy_Xardex

  • Sr. Member
  • ****
  • Posts: 414
  • Karma: +0/-0
Problem with petrified creatures
« Reply #2 on: January 29, 2012, 08:33:56 am »


               Generally, AFAIK, that pose is nicknamed  "the davinci pose."

It's a default pose all models take when they are first loaded by the game, before they are assigned any actual animations. I suppose if you petrify them right as they spawn, they would freeze in this pose. You could apply the petrification with DelayCommand() so the creature would have time to assume a natural pose.

Also, if a PC enters an area where a creature is already petrified, the PC will see that pose, regardless of the animation the creature was petrified into.
               
               

               


                     Modifié par Xardex, 29 janvier 2012 - 08:34 .
                     
                  


            

Legacy_Ali Akabba

  • Newbie
  • *
  • Posts: 10
  • Karma: +0/-0
Problem with petrified creatures
« Reply #3 on: January 29, 2012, 07:43:36 pm »


               Thanks for the tip, _six, but I'm trying to avoid haks at all costs, so I would prefer any other sort of solution.


Xardex wrote...
(...) You could apply the petrification with DelayCommand() so the creature would have time to assume a natural pose.

Also, if a PC enters an area where a creature is already petrified, the PC will see that pose, regardless of the animation the creature was petrified into.


Exactly. I tried using the delay command, and it works for the first time the PC approaches the statue. However, If I go for a long walk with the PC, for example, and return, the issue comes back.

I was considering something like removing the petrification effect when there is no PC nearby, but I haven't succeeded in doing it. Better yet, I could remove the freezed animation and keep the stoneskin visual. How exactly should I do it? I tried lines like these, but they don't seem to work:


     RemoveEffect(OBJECT_SELF, EffectPetrify());

     RemoveEffect(OBJECT_SELF, EffectVisualEffect(VFX_DUR_FREEZE_ANIMATION));
               
               

               


                     Modifié par Ali Akabba, 29 janvier 2012 - 07:51 .
                     
                  


            

Legacy_FunkySwerve

  • Hero Member
  • *****
  • Posts: 2325
  • Karma: +0/-0
Problem with petrified creatures
« Reply #4 on: January 29, 2012, 08:54:44 pm »


               

Ali Akabba wrote...
Exactly. I tried using the delay command, and it works for the first time the PC approaches the statue. However, If I go for a long walk with the PC, for example, and return, the issue comes back.


This is likely related to a quirk of the engine - when you leave the visual range (25 meters? 30? forget) of a visual effect, and return, it is reapplied - despite the old one still being there. This is generally only an issue in large, regularly trafficked areas, but it CAN result in some mongo vfx. It sounds like your petrified critters are engaging in similar behavior, though I have no idea if it is directly related to the vfx you're using on them, or is just a parallel phenomenon relating to critter models. Either way, I'm not aware of any fix, but I'd be interested in one if someone knows of or makes one.

Funky
               
               

               
            

Legacy__six

  • Hero Member
  • *****
  • Posts: 1436
  • Karma: +0/-0
Problem with petrified creatures
« Reply #5 on: January 30, 2012, 05:20:12 am »


               If you'd like a slightly more technical definition of the animation problem...

NWN segues between animations with a given 'radius' of, basically, blending (by default I believe it's 0.25 seconds). This means that if a creature is given an animation that has a different start pose from their current pose, they can move relatively fluently into it rather than making a sudden snapping motion. All good so far. Also, NWN removes creatures from being rendered when they're outside a certain distance in order to save on rendering time, and puts them back how they were when you return. Again, nothing odd about that. Unfortunately, nobody thought it a good idea to turn off seguing the animation from inanimate to the first animation, so while the engine will typically remember what pose the creature is in, it will take it a short while to actually put them in that pose. Whereas, the reapplication of the effect which Funky mentioned is pretty much instant.

So you've got a conflict within the design of the rendering engine on the client side, which is liable to be impossible to work around without coding at a runtime loop level. In short, as far as nwscript goes it's just something you have to live with. Restricting statues to areas the player won't be able to un-see them would help.

As for removing visual effects, the effects created by script are seperate entities on the creature, that must be looped through and checked. You can't create an effect variable and remove that from a creature, because that's a brand new effect, not the effect applied (if that makes sense).

This might do a better job than my inane rambling:

http://social.biowar...-8758904-1.html 
               
               

               


                     Modifié par _six, 30 janvier 2012 - 05:23 .
                     
                  


            

Legacy_Ali Akabba

  • Newbie
  • *
  • Posts: 10
  • Karma: +0/-0
Problem with petrified creatures
« Reply #6 on: January 30, 2012, 09:57:09 pm »


               Thanks for all the helpful information. While I'm inclined to believe that the creature's return to the da Vinci pose is unavoidable, I'm not giving up, yet.

My current idea is to use NESS to spawn a creature with the stoneskin visual effect and then trigger the animation freezing by a OnPerception event, with some delay to let the PC get near enough so that a natural pose can be reached before the freezing. I would then despawn the creature when the PC goes away far enough that the creature is out of it's visual range (so that coming back would restart the creature's rendering process and find it already freezed and produce the undesired pose). If the PC returns, then, it would start it all over, with a new spawn.

This way, whenever a PC approaches the statue, it would see it moving for a little while, before assuming a petrified position. How long it would take it would depend on how exactly the PC is walking, but I think it would be possible to adjust the time so that it would be brief in most cases. It is not a perfect solution, but it seems to me that seeing a statue moving for a fraction of a second before freezing could be taken as "something the game has to do when creating the image of a statue", which is psicologically more acceptable, or less prone to break the immersion,  than seeing a certain statue in a beautiful pose, walk around for a bit and then encounter the same statue in a totally different (and unnatural) pose.

I'm not certain that it will work, but I'll give it a shot. I thought about using NESS for this simply because it seems to make controlling the spawns and despawns easier. I never used it before, so I guess it's a good excuse to learn it, heh.

If you have any reason to believe that this wouldn't work, or that it would not be a good solution, let me know.
               
               

               


                     Modifié par Ali Akabba, 30 janvier 2012 - 09:59 .
                     
                  


            

Legacy_wyldhunt1

  • Sr. Member
  • ****
  • Posts: 443
  • Karma: +0/-0
Problem with petrified creatures
« Reply #7 on: January 30, 2012, 10:51:53 pm »


               The main issue I see with it is the OnPerception part.
Keep in mind that the OnPerception fires when the NPC sees the PC.
You need to make sure that the NPC's perception range is set to see as far as possible.
Even with the longest NPC perception range, the PC can see the NPC long before the NPC sees the PC. This could create strange behavior where the PC sees the davinci pose until they get close. Then the NPC suddenly disappears, reappears as flesh, moves in to position, and turns to stone again.

You'll have to experiment to see how obvious it is though.
               
               

               
            

Legacy_wyldhunt1

  • Sr. Member
  • ****
  • Posts: 443
  • Karma: +0/-0
Problem with petrified creatures
« Reply #8 on: January 30, 2012, 10:55:34 pm »


               An easier way may be to use a large trigger around the area of the statue.
In the OnEnter of the trigger, spawn the NPC at a waypoint and statue it.
In the OnExit, despawn the statue.

Just make the trigger large enough that the statue will spawn just outside of the PC's normal visual range.
               
               

               


                     Modifié par wyldhunt1, 30 janvier 2012 - 11:01 .
                     
                  


            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Problem with petrified creatures
« Reply #9 on: January 30, 2012, 11:49:28 pm »


               Wyldhunt... with NESS whihc he proposes you don't need to set a trigger but can specify how close the PC is to the spawn point when a spawn or despawn event occurs.
               
               

               
            

Legacy_wyldhunt1

  • Sr. Member
  • ****
  • Posts: 443
  • Karma: +0/-0
Problem with petrified creatures
« Reply #10 on: January 31, 2012, 12:56:22 am »


               I've never used NESS, but that seems like it would require a HB of some kind constantly checking the distance. There's no event that would trigger to hook that to, other than a hb of some kind.
It seems like that would make it less than accurate.
Even with a virtual hb triggering once every second, a hasted & running PC could potentially get close enough to get a much better view of the NPC becoming a statue.
The trigger would ensure reliable spawning at the exact moment that the trigger events fired, and reduce the amount of background checks that you need to worry about.
If Ness has found some way of reliably controlling spawn distance other than a trigger or HB(Which isn't exactly reliable), I'd be very interested in knowing how they did it...

Besides, the OnEnter of the trigger would be some very basic code.
Off the top of my head, in between dodging my boss noticing me on the forums, I came up with the following (Probably better ways of doing it):

object oStatue = CreateObject(OBJECT_TYPE_CREATURE, “NPCResRef”, GetLocation(GetObjectByTag(“WayPointTag”)));
If GetIsObjectValid(oStatue)
{
   effect ePetrify = EffectPetrify();
   DelayCommand(0.1, ApplyEffectToObject(DURATION_TYPE_PERMANENT, ePetrify, oStatue));
}


               
               

               


                     Modifié par wyldhunt1, 31 janvier 2012 - 01:17 .