Jump to content

question: script function,changing tranluscent factor and pass-through at the same time on touch


MishkaKatyusha
 Share

You are about to reply to a thread that has been inactive for 2577 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

well im finaly making some headway in constructing a house as it were.

i had this idea for a door that would look more like a force field

 

but for this application the door would need to go from solid to passthrough on touch

and while this isnt entirely needed,but would be appreciated,id also like to know if it's possible to have the translucent factor or glow amount change at the same time

 

the primary reason why im trying for a forcefield style door is,due to the odd shape of the house,a normal door would be virtually impossible

Link to comment
Share on other sites

You ougfht to be able to manage all of those changes at once with the appropriate parameters in llSetLinkPrimitiveParams .  Create a simple toggle in the touch_start event to flip the parameters from solid to phantom (and glow/non glow, etc.) and back again.

Link to comment
Share on other sites

OK, well Rollig way is best, but if you learning script you may be better to use two states, as in defalt state makes it solid, next state not. You read that on the wiki in regards to multi  states

default state

touch

set prim parameters to not phantom and other stuff

goto next state

end this state

--------------------------------------

next state

touch

set parameters phantom and other stuff

go back to default state.

ADDED later you can put it in one state by toggling true or false, but at the moment you can just get each state right.

like this example

default {    state_entry() {		// run this code when entering the default state		// displays red "OFF" as floating text above the prim		llSetText("OFF", <1,0,0>, 1.0);	}    touch_start(integer num_detected) {		// when touched, switch to state named 'on'		state on;	}} state on {	state_entry() {		// run this code when entering state 'on'		// displays green "ON" as floating text above the prim		llSetText("ON", <0,1,0>, 1.0);	}	touch_start(integer num_detected) {		// when touched, switch to the default state		state default;	}}

 

  • Like 1
Link to comment
Share on other sites

Script states are trickier than they appear to folks first learning to script. Relevant to this thread in particular, touch_start is an event that interacts unexpectedly with state changes. Notably, in this example, if the "on" state didn't contain any touch-related event handlers and instead got back to "default" from some other trigger, the next touch would not be seen by the touch_start handler in that state. That is, the object would need to be clicked twice to register a touch_start. So, as a general rule, I use touch_end instead of touch_start when scripting with states.

(I may encounter this more than most, though, because the main reason I ever use states instead of global flags is to move into a no-touch state and hide the "touch me paw" mouse cursor when it's not appropriate.)

Link to comment
Share on other sites

:S my scripting expertise in lsl only goes about as far as gingerly reprogramming some algebraic coordinates for rotation and changing what animation was used by the script in a bed.

 

this is why i asked on here about this sort of on touch forcefield

the thing i had in mind was very similar to how the glowing door functions on some of the "wizard" themed linden homes

 

though onstenibly with some differences.my idea was,poke for passthrough,shutoff of glow,

then once your inside the structure that the door is blocking the entrance too,you could poke the general door location again to turn it into solid,glow on

the translucensy factor would be 100% in both cases due to wanting a sort of energy field like appearence (relying mainly on the glow function for appearence)

and above all the primary reason for this is that the structure im trying to make the door for has an extremely..how do i say this in english "non-newtonian" shape.basically very little in recognizeable geometry,so the entrance look abit like an onion if you cut a chunk out of it with a serrated knife,so no door nor door function that exists for other homes (except maybe spaceship hangar bays) would work by my estimation.

it would be easy for me to make the mesh for the door shape but the programming is something i only jsut recently got into

(interesintg luck i have,being experienced in most other aspects of developement except for programming)

Link to comment
Share on other sites

I would suggest that you make the door frame and the force-field two different objects (which you then link).

The reason for this is that you'll need to switch the force-field's PRIM_PHYSICS_SHAPE_TYPE property between PRIM_PHYSICS_SHAPE_CONVEX and PRIM_PHYSICS_SHAPE_NONE to toggle between solid and phantom.   You have to set this property for the whole child prim (mesh) -- it can't be set for particular faces of the prim or mesh.

For what it's worth, I don't think I'd bother using states for a simple script like this (simple in the sense that you're doing only one thing -- toggling between two sets of prim parameters for the door when you touch it -- I realise it probably doesn't feel simple to do!).  

Nothing wrong with using states but it seems to be complicating life unnecessarily in this instance.

 

Link to comment
Share on other sites

I used the switch state example so the OP could see what was happening in each state, if i was writing the code for my self i would use one state and switch with a TRUE or FALSE. You mention the touch statrt event, i have not had that issue  in over four years, but saying that it may still happen.

"trickier than they appear to folks first learning to script" i tend to disagree on this example, i certanly undertood it better than useing one state with logic switches, but maybe that was just me as i had never writen any code before. My self it encouraged me to attempt after it was working to learn to write the code into one state. Success and understanding what is hapening i found a far better way to keep going. Getting a script to work was a joy, they may have looked like moron had wrote it but later on i went back rewrote bits using say a loop instead of 50 lines of move 0.2, sleep move 0.2, sleep. Walk first, run later was my ethos.

Link to comment
Share on other sites

I was just thinking, i think i would be more inclined to use a phantom transparent cube that is collision triggered rather than touch. Walk to ward door, thru the collision prim then door opens, exit the colision prin  door closes. Just a thought. Any how a futer idea, not really relevent now as it would complicate things.



Link to comment
Share on other sites

Steph gave a good script example to start with.

Just use llSetPrimitiveParams to switch between PRIM_PHYSICS_SHAPE_CONVEX and PRIM_PHYSICS_SHAPE_NONE and set transparency and glow in the call.

Phantom is something from the past and will switch the whole linkset so will prevent the doors beeing linked. Ignore it.

If you switch the state always use touch_end instead of touch_start. The state change will kill all listens and you need to think how your timers are supposed to work. But for this simple script this is not important.

 

Link to comment
Share on other sites

Yes, that's true.  Setting Physics Shape Type to NONE has the same effect as setting the object to phantom, in that it tells the physics engine to ignore any collisions with the object.  It's not exactly the same thing as phantom because the physics download weight is calculated differently, but for this particular application, it works the same way.

Link to comment
Share on other sites


steph Arnott wrote:

moved past the original OP.. The OP had an answer on page one.

OK.  In that case, then, I'm unclear what process we're trying to model.  

If we want to detect collisions in an object you can walk through, we need -- as you know -- to use llVolumeDetect.   That has to apply to the whole linkset, unlike PRIM_PHYSICS_SHAPE_NONE, which can be applied to individual linked prims.   This may or may not be a problem.

Be that as it may, someone walks into the llVolumeDetect prim -- what do you want to happen next?

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2577 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...