So we can do actual GUIs right now but could it be possible to fake simple GUIs?
Say what we want is to display a simple picture: a map, a drawing, whatever.. Just a simple plane with a texture.
Could it be possible to detect the position and the direction of the camera and to move a plane right in front of it? That would mean moving and rotating it according to the camera..
(Ideall that should work with both 1st and 3rd person cameras)
That would be a dirty trick but that should work.. (that is, if it is possible at all)
fake simple GUIs?
Re: fake simple GUIs?
As a proof of concept, why not try a plain ol' camera region?
Avatar enters the (very small) region, view switches to a camera looking at a page. Moving back returns to normal camera view.
Then we ca make it clickable.
Avatar enters the (very small) region, view switches to a camera looking at a page. Moving back returns to normal camera view.
Then we ca make it clickable.
Chacal
"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
Re: fake simple GUIs?
That could probably work. But that means your camera would move, and it would probably go through the avatar..
Re: fake simple GUIs?
You'd have to put the camera and the page outside the playable area, and I'm pretty sure there is a setting for instantaneous camera switch instead of smooth.
Let's look at how Cyan did it in prpExplorer.
Let's look at how Cyan did it in prpExplorer.
Chacal
"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
-
- Councilor of Technical Direction
- Posts: 2180
- Joined: Fri Nov 16, 2007 9:45 pm
- MOULa KI#: 23335
- Location: South Georgia
- Contact:
Re: fake simple GUIs?
I've just spent the past 30 minutes or so investigating whether or not this would work. I am glad to say that it would... It would just be a long, drawn out process, and, yes, a dirty hack.
For those of you who really want to know, I'll walk you through the theoretical (and very untested) process of building one.
First, you will need the object that you want to "zoom in" on. In Blender, you will need to make a fixed camera that will show the object correctly (I can't be of any assistance there... You'll have to figure that out). You will want to make that object clickable and add a plActivatorConditionalObject modifier to it which is a toggle (the activator can be added in PRPExplorer). The ActivatorConditionalObject must reference a plLogicModifier, which is a big junction point. It needs to reference a plPythonFileMod and the original ActivatorConditionalObject.
Now, you'll want to get out a hex editor and somehow write a plResponderModifier that will activate the camera. I'm not too certain what that would look like, and it's been awhile since I've written a RespMod, so no help there (until I get around to trying this mess myself).
Back to our plPythonFileMod, the arguments should look something like this:
Name: xCameraGUIHack
1: Our ActivatorConditionalObject
2: Our ResponderModifier that does the magic
Now for the python file:
Now that I'm done... Errr, I noticed that this won't handle a user wanting to actually *leave* the GUI. Ooops
I suppose you could make a few changes in the script and maybe a ptCamera().restore(theCorrentCameraKey)...
For those of you who really want to know, I'll walk you through the theoretical (and very untested) process of building one.
First, you will need the object that you want to "zoom in" on. In Blender, you will need to make a fixed camera that will show the object correctly (I can't be of any assistance there... You'll have to figure that out). You will want to make that object clickable and add a plActivatorConditionalObject modifier to it which is a toggle (the activator can be added in PRPExplorer). The ActivatorConditionalObject must reference a plLogicModifier, which is a big junction point. It needs to reference a plPythonFileMod and the original ActivatorConditionalObject.
Now, you'll want to get out a hex editor and somehow write a plResponderModifier that will activate the camera. I'm not too certain what that would look like, and it's been awhile since I've written a RespMod, so no help there (until I get around to trying this mess myself).
Back to our plPythonFileMod, the arguments should look something like this:
Name: xCameraGUIHack
1: Our ActivatorConditionalObject
2: Our ResponderModifier that does the magic
Now for the python file:
Code: Select all
from Plasma import *
from PlasmaTypes import *
actClickable = ptAttribActivator(1, "Clickable object", netForce=0)
respCamera = ptAttribResponder(2, "Camera Responder", netForce=0)
class xCameraGUIHack(ptModifier,):
def __init__(self):
self.id = 66606660666 #A big number that no one else would use
self.version = 1
def OnNotify(self, state, id, events):
if PtWasLocallyNotified(self.key):
if (id == actClickable.id):
PtDebugPrint("xCameraGUIHack.OnNotify():\tReceived local activator notify... Running Responder")
cam = ptCamera()
cam.undoFirstPerson()
cam.disableFirstPersonOverride()
respCamera.run(self.key)
else:
PtDebugPrint("xCameraGUIHack.OnNotify():\tReceived remote notify... Ignoring.")
Now that I'm done... Errr, I noticed that this won't handle a user wanting to actually *leave* the GUI. Ooops

