(Project) The Ultimate Maze
|
|
Rock Vacirca
riches to rags
Join date: 18 Oct 2006
Posts: 1,093
|
09-17-2008 03:02
Hi,
I am planning a new sim, called The Temple of Knossos, which will be a huge (half sim) maze, a quarter sim Elysian Fields (full of heavenly delights) for the successful, and a quarter sim Purgatory for the not so successful.
The layout will be like two chess boards side by side (taking up half of the sim), i.e. (8 squares by 8 squares, a total of 64 cells) x 2, a total of 128 cells, each of 16m x 16m. Each cell will have a floor, a ceiling, and four walls, so it would be like being in a box.
The features (and hence the problems) I would like to adopt are these:
1. Walls that are phantom in one direction only.
Could this be achieved with a collision event? Would I need a separate wall (phantom and full alpha) in front of the actual wall to trigger the collision first? Any other approaches to achieve phantom in one direction only?
2. I want to negate the panning of the camera around the maze, and to this end I am employing randomly changing textures on the walls of the maze to confuse. Are there any other techniques to thwart camera panning?
3. I also want to prevent anyone from moving around the maze by any means other walking, such as:
a) Creating a prim on the other side of a wall and then sitting on it. Simply inhibit the creation of prims?
b) Making themselves non-phys, by using devices such as MystiTool. Any ideas on how this could be defeated?
c) Teleporting via the map Designate the entrance to the maze as the only teleport hub?
d) Any other methods I have missed?
4. I am planning 8 routes through the maze. However, 7 will lead to Purgatory (more on that in a minute), and only 1 to The Elysian Fields. All other routes will lead to entrapment, ie.you can get in, but due to walls being non-phantom in the reverse direction, it is possible to enter regions from which there are many paths, but no exit.
5. I want to construct 8 special groups of cells, so that when the agent enters a group a timer starts, and if the timer times out without the agent having traversed that group of cells he is sent to Purgatory.
a) Any suggestions on how a timer can be made to start once a cell is entered? (Prim on the floor to trigger a collision event perhaps?).
b) I want the agent to be teleported/pushed/etc to Purgatory following the timeout. Any suggestions on how this might be achieved?
Thoughts/suggestions on any of the above 5 problem areas most welcome.
Rock
|
|
Pedro McMillan
SLOODLE Developer
Join date: 28 Jul 2007
Posts: 231
|
09-17-2008 04:08
Yikes, that sound ambitious! 1. One way phantom walls are not directly possible. You can kind of 'fake' it using 2 objects: one llVolumeDetect which determines the avatar's velocity, and a second which will be normally phantom, but turned to solid if an avatar goes the wrong way. Unfortunately, it will also block avatars going the correct way if they attempt to pass at the same as somebody going the wrong way. 2. You could require users to 'sit on' a kind of invisible vehicle, which takes their camera controls. If they aren't using the 'vechicle', or if they refuse to give control of their camera, then you could deny them entry to the maze. 3. (a) You can't really prevent sitting, because somebody just as easily sit on an existing prim in your maze, although point 2 might solve this problem (if the avatar ever unsits from the vehicle, then teleport them home or something) (b) Again, point 2 is probably the only way to solve this problem. (c) It is possible to setup a telehub and use teleport routing on given parcels to block direct-to-point teleports, although I'm not sure if that only blocks people on their first entry to the sim or not (d) People will always find a bug or glitch to exploit!  5. (a) A llVolumeDetect prim at each entrance, reporting back to a 'hub' for the entire cell, could probably serve your purposes. (b) That's much harder. If you're using the vehicle from part 2 though, then it might be possible to make seize control, lift them up and out of the maze, then across to purgatory (that way you avoid going through any walls which might let them see alternative routes.
|
|
Buckaroo Mu
Alpha Geek
Join date: 17 Oct 2006
Posts: 106
|
09-17-2008 07:38
For the one-way walls, you could use a llVolumeDetect wall, then check the colliding avatar's vector with llDetectedVel, to determine which way they're moving - then, if they're moving the "wrong" way, apply a little push to them to move them back. Kludgy, but it should do the job.
|
|
Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
|
09-17-2008 08:33
If it has to be oneway, and you're planning to insert timers anyway, then you could take a shortcut by turning the floors in some "rooms" into Steppingstones: When someone steps into a room, make the exit sides turn phantom for about 5 seconds. So if someone is on the other side of the wall, he won't be standing on the right piece of floor, and the wall will remain solid.
|
|
Arcturus Ember
Registered User
Join date: 9 Mar 2008
Posts: 2
|
One way wall
09-20-2008 13:35
This should work for the walls. Collision activates the sensor which is set to scan only a hemisphere in the positive x direction. Then moving the wall 1 meter places it on the other side of the avatar. I thought: make phantom, move, unphantom would be req'd but apparently the scripted move doesn't bump the avatar. The wall resets to it's original position, after no avatars are in the sensor range. Tested on only one wall, one avatar. // One Way wall script // Arcturus Ember 9/20/2008 vector startpos; default { state_entry() { startpos = llGetPos(); } collision_start(integer num) { llSensor("","",AGENT,2.0,PI/2); } sensor(integer Num_Detected) { llSetPos(startpos + <1.0,0.0,0.0>  ; state Opened; } } state Opened { state_entry() { llSensorRepeat("","",AGENT,2.0,PI,2.0); } sensor(integer Num_Detected) { } no_sensor() { llSetPos(startpos); state default; } }
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
09-20-2008 15:30
You might want to keep track of which cell the avatar was last in, and if it moves into a cell that is not allowed from that one, or winds up in the success area after the maze if it wasn't from the exit cell, teleport them home or ban from all but the failure parcel and then eject. From the failure zone you could have a teleporter that coordinates for them to be unbanned or passed before doing the actual teleport.
Hmm. Actually...maybe you could do the whole thing using parcels and pass/ban lists. Heh. Just make ALL the walls phantom and unban/pass each avatar from the next parcels and ban/unpass them from the previous ones....
|
|
Ruthven Willenov
Darkness in your light
Join date: 16 Jan 2008
Posts: 965
|
09-20-2008 19:52
From: Arcturus Ember This should work for the walls.
Collision activates the sensor which is set to scan only a hemisphere in the positive x direction.
i haven't tested it yet, is the positive x direction global or local?
|
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
09-20-2008 20:21
yes
but generally local, unless you convert it to global, which if thats your need, its not all that hard
|
|
Ruthven Willenov
Darkness in your light
Join date: 16 Jan 2008
Posts: 965
|
09-20-2008 20:38
From: Osgeld Barmy yes
but generally local, unless you convert it to global, which if thats your need, its not all that hard no i prefer local, makes it easier to set up which way i want to face the sensor. and afte ri asked that i looked at the lslwiki for it. i would probably prefer using PI/4 to centralize the sensor more in front of the door 
|
|
Arcturus Ember
Registered User
Join date: 9 Mar 2008
Posts: 2
|
One way wall
09-21-2008 00:59
I did some more testing after posting...
The sensor operates in the LOCAL X direction. The llSetPos statement however is a WORLD coordinate
Change the llSetPos call to:
llSetPos(startpos + (<1.0,0.0,0.0> * llGetRot()));
and the wall worked for all the rotations I checked. When the wall was not perpendicular to the floor, it moved up, or down some too. which may not be what is desired. The 1 meter move is open for testing. The minimum will depend on the wall thickness.
On rezzing a wall with the script, It moved to an odd location, on the first collision. I added a reset to force the starting position to the new wall location.
on_rez(integer start_param) { llResetScript(); }
There's probably a better way that would eliminate the global startpos.
I was wondering if the llSensorRepeat should be shut off with a llSensorRemove. Before leaving the state. Works without it but is it waste.
The maze sounds interesting.
|
|
Ruthven Willenov
Darkness in your light
Join date: 16 Jan 2008
Posts: 965
|
09-21-2008 19:18
well it goes to the default state when there's no sensor, does the sensor still continue to run in state changes? i think i read somewhere about needing to remove listens in state changes as well
|