Jump to content

activator loses activatability & collision after SetPos - WHY...??


stevie70

Recommended Posts

i have there an activator pair of two identical activators (curtains).

 

at first, they're both enabled, and on activation of any of them, it runs a questscript moving one of them using SetPos and then disabling it and stopping the controler quest, while the second one always stays in place and enabled.

 

if you now activate the remaining second activator, the controler quest starts again. re-enables the first activator and moves it back to original position, using SetPos again.

 

this all works perfectly. the strange thing is, though, once the first activator is moved back, it doesn't show any "activate ..." text anymore and you can walk right through it.

(before moving it, it can be activated without problem and not walked through), so all in all, collision detection seems to be obviously failing on it.

if i leave out the SetPos-parts and just do the disabling/enabling-stuff, this does _not_ happen.

 

the second activator, that wasn't moved, is still activatable and reacting to collision like it should, and they're both references of one and the same object!

ah yes, and the activation script the two activators are both running does nothing but start the controller quest and has no own variables or anything.

 

so now, does anybody maybe have the slightest idea why this might be happening? anything i didn't get about the SetPos command maybe or anything...?

worked around this for now by never moving any of the actual activators, but disabling/enabling them in place and moving a separate static copy, but it's not the last activator i'll be wanting to be moving and i fear it won't in always work like this

Link to comment
Share on other sites

Try disabling the object before SetPos, and then enabling it again after.

 

(There's a wiki Note on the MoveTo command to get around weirdness there with activators)

uhm...

thx for the hint - i'm sure gonna try that for research purposes.

but as a solution in my case, this wouldn't have done, the whole drawing-a-curtain-open-effect would be SO down the drain if i just disabled it and made it reappear elsewhere :-)

and it moves in steps of 2 units, so disabling/enabling it between every two moving steps would definitely be what i'd call inefficient scripting... :-)=)

hm...

maybe doing all the movement first and when it ends just disable/enable it once would have the same effect... gonna try that too.

 

in my current case though, my workaround with keeping the actual activators in place and moving only a separate copy works just like it should, so if the best alternative i can get anyway is just another workaround, i think i'll rather just leave it as it is :-)

Link to comment
Share on other sites

If I remember correctly, the problem isn't that the activator loses collision data - its collision data simply won't update without this workaround. That means that, until you force it to be updated, the player could still activate it by looking at where it was before it was moved.

 

When it comes to questions of efficiency, disabling and re-enabling a single reference each frame shouldn't affect performance. In any case, while it's a good idea to think about efficiency you should always write a script primarily to do what's required, and be efficient secondarily.

 

Keep in mind that, if you'll be calling Disable and Enable every frame, you'll want to call Enable with its optional parameter set to 0, i.e. "reference.Enable 0" so the reference "pops" in instead of fading.

 

I don't remember, and am currently unable to test, if calling Disable and Enable in the same frame will fix this issue, so I'd be grateful if you'd post the results of any experimentation you do.

 

Cipscis

Link to comment
Share on other sites

If I remember correctly, the problem isn't that the activator loses collision data - its collision data simply won't update without this workaround.

aaaah something that makes sense finally :-))

 

When it comes to questions of efficiency, disabling and re-enabling a single reference each frame shouldn't affect performance.

not? thought making something disappear/reappear every single moment would be pretty heavy, but maybe that's just too much stage magician thinking :-)

 

I don't remember, and am currently unable to test, if calling Disable and Enable in the same frame will fix this issue, so I'd be grateful if you'd post the results of any experimentation you do.

nope. just tried it out, doesn't work. disabling in one cycle and enabling in the next perfectly works just like you both said though.

 

Cipscis

uhm, say, you happen to be the guy with the scripting tutorials on his website? if so, thanks MILLION for those, i'd have gone nuts countless times without them - kudos just on suspicion :-)

Link to comment
Share on other sites

nope. just tried it out, doesn't work. disabling in one cycle and enabling in the next perfectly works just like you both said though.

If having it disabled for one frame and enabled for the other works, you may be able to get it to appear to move seamlessly by having a slave activator (i.e. an activator that defers its activation to its master) that appears identical and moves alongside its master, and setting up some enable parenting such that one and only one of them is always enabled.

 

uhm, say, you happen to be the guy with the scripting tutorials on his website? if so, thanks MILLION for those, i'd have gone nuts countless times without them - kudos just on suspicion :-)

That's me alright - cipscis.com is my site. I'm glad you've found my stuff there useful!

 

Cipscis

Link to comment
Share on other sites

If having it disabled for one frame and enabled for the other works, you may be able to get it to appear to move seamlessly by having a slave activator (i.e. an activator that defers its activation to its master) that appears identical and moves alongside its master, and setting up some enable parenting such that one and only one of them is always enabled.

i have now the 2 curtain end positions as activators that never actually move, but get disabled/enabled as needed; and a third, scriptless one, that's the only one that's really getting moved, and when moving it gets first enabled then disabled every frame, so it also keeps collision while doing that.

this works fine and was about the simplest way i could come up with, the whole setup is in an exterior, so i wanted to keep it as low as ever possible performancewise.

 

That's me alright - cipscis.com is my site. I'm glad you've found my stuff there useful!

it in many ways begins where the geck-wiki ends. they got quite a weird way of "explaining" things there sometimes, esp. if you're still learning :-)

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...