This MGE script outputs garbage values. Its the first one I've written so I don't really know what I've done wrong. This is attached to a ring and is only activated when worn. Its supposed to output the orientation of the player camera. Any takers?

CODE
;prints the camera orientation


begin cbn_sc_printEyeVect

short inMenu
short OnPCEquip
short doOnce

long trgRef

float vectX
float vectY
float vectZ
float elevAngleRad
float elevAngleDeg

long valCount

if ( MenuMode == 1 )
set inMenu to 1
else
set inMenu to 0
endif
ifx (inMenu)
;MessageBox"In menu mode"
else

ifx ( OnPCEquip )
xFileWriteShort, "|MGEpipe", 20580 ;0x5064 special functions: GetEyeVec
setx valCount,vectX,vectY,vectZ to xFileReadFloat, "|MGEpipe", 3

MessageBox"vectX: %.2f", vectX
MessageBox"vectY: %.2f", vectY
MessageBox"vectZ: %.2f", vectZ
endif ;OnPCEquip
endif; inMenu


end cbn_sc_printEyeVect
When using mge like that, you need to read the answer to the value you wrote the frame after you wrote it

EDIT:
Also, you need to remember that the return values are normalized
QUOTE(Yacoby @ Feb 9 2008, 07:53 AM) *
When using mge like that, you need to read the answer to the value you wrote the frame after you wrote it

EDIT:
Also, you need to remember that the return values are normalized


Thanks. I'll try it now. I was just about to go to sleep too...
Ok its half outputting reasonable numbers and a single huuuuuge value every couple of frames. No values remains constant though. I really have no idea. Here's the new code:

CODE
;prints the camera orientation


begin cbn_sc_printEyeVect

short inMenu
short OnPCEquip
short doOnce
short toggleMGE

float vectX
float vectY
float vectZ
float elevAngleRad
float elevAngleDeg

long valCount

if ( MenuMode == 1 )
set inMenu to 1
else
set inMenu to 0
endif
ifx (inMenu)
;MessageBox"In menu mode"
else

ifx ( OnPCEquip )
ifx ( toggleMGE )
setx valCount,vectX,vectY,vectZ to xFileReadFloat, "|MGEpipe", 3
MessageBox"vectX: %.2f", vectX
MessageBox"vectY: %.2f", vectY
MessageBox"vectZ: %.2f", vectZ
set toggleMGE to 0
StopScript, cbn_sc_printEyeVect
endif

set toggleMGE to 1
xFileWriteShort, "|MGEpipe", 20580 ;0x5064 special functions: GetEyeVec

endif ;OnPCEquip
endif; inMenu


end cbn_sc_printEyeVect


Edit:can't spell, apparently.
QUOTE(clownbaton @ Feb 9 2008, 01:23 PM) *
Ok its half outputting reasonable numbers and a single huuuuuge value every couple of frames. No values remains constant though. I really have no idea. Here's the new code:

CODE
;prints the camera orientation
begin cbn_sc_printEyeVect

short inMenu
short OnPCEquip
short doOnce
short toggleMGE

float vectX
float vectY
float vectZ
float elevAngleRad
float elevAngleDeg

long valCount

if ( MenuMode == 1 )
set inMenu to 1
else
set inMenu to 0
endif
ifx (inMenu)
;MessageBox"In menu mode"
else

ifx ( OnPCEquip )
ifx ( toggleMGE )
setx valCount,vectX,vectY,vectZ to xFileReadFloat, "|MGEpipe", 3
MessageBox"vectX: %.2f", vectX
MessageBox"vectY: %.2f", vectY
MessageBox"vectZ: %.2f", vectZ
set toggleMGE to 0
StopScript, cbn_sc_printEyeVect
endif

set toggleMGE to 1
xFileWriteShort, "|MGEpipe", 20580 ;0x5064 special functions: GetEyeVec

endif ;OnPCEquip
endif; inMenu
end cbn_sc_printEyeVect


Edit:can't spell, apparently.


I dug up an old PM from Timeslip in which he said:
QUOTE
I've tested it, but while it mostly works, every few frames MGE returns some complete garbage. I haven't got a clue what's going on, but it may well be a bug at my end. Try only requesting the data once every few frames instead of every frame.
QUOTE(Yacoby @ Feb 9 2008, 09:21 AM) *
I dug up an old PM from Timeslip in which he said:


Thanks, mate. It's now usable 99% of the time. This makes me really happy, actually. There are now many more things I can implement. I had a solution using MWSE but it would have annoyed the player too much because a messagebox was on screen all the time.
Ah, that explains the problem I was having. So using this we can properly determine if the player is looking up or down, right? Now maybe I can figure out how to finish that 3rd-person crosshair thing I was trying to figure out.
QUOTE(Fliggerty @ Feb 9 2008, 11:02 PM) *
Ah, that explains the problem I was having. So using this we can properly determine if the player is looking up or down, right?


Yep. I have a script that outputs a delicious float from -90->90 degrees and it works well. Though I just filter the garbage values and still check every second frame.
You wouldn't mind sharing that script, would you? Save me a bit of time...?
QUOTE(Fliggerty @ Feb 9 2008, 11:55 PM) *
You wouldn't mind sharing that script, would you? Save me a bit of time...?


Yep, no worries. Its a bit rough but I'm sure you know what do smile.gif

CODE
;prints the camera orientation


begin cbn_sc_printEyeVect

short inMenu
short OnPCEquip
short doOnce
short toggleMGE
short FrameCounter
short rejectGarbage

long trgRef

float vectX
float vectY
float vectZ
float elevAngleRad
float elevAngleDeg

long valCount

if ( MenuMode == 1 )
set inMenu to 1
else
set inMenu to 0
endif
ifx (inMenu)
;MessageBox"In menu mode"
else

ifx ( OnPCEquip )

;ifx ( FrameCounter )
;set FrameCounter to ( FrameCounter + 1 )
;if ( FrameCounter >= 1 )
;set FrameCounter to 0
;endif
;else
;set FrameCounter to 1
ifx ( toggleMGE )
setx valCount,vectX,vectY,vectZ to xFileReadFloat, "|MGEpipe", 3

;filter out garbage values
if ( vectX > 1 )
set rejectGarbage to 1
return
endif
if ( vectX < -1 )
set rejectGarbage to 1
return
endif
if ( vectY > 1 )
set rejectGarbage to 1
return
endif
if ( vectY < -1 )
set rejectGarbage to 1
return
endif
if ( vectZ > 1 )
set rejectGarbage to 1
return
endif
if ( vectZ < -1 )
set rejectGarbage to 1
return
endif
MessageBox"vectX: %.2f", vectX
MessageBox"vectY: %.2f", vectY
MessageBox"vectZ: %.2f", vectZ
set toggleMGE to 0

;calc angle
setx elevAngleRad to xArcSin vectZ

;now convert to degrees
set elevAngleDeg to ( elevAngleRad * 180 / 3.141593 )
MessageBox"Elevation Angle: %.2f", elevAngleDeg
StopScript, cbn_sc_printEyeVect
endif

set toggleMGE to 1
xFileWriteShort, "|MGEpipe", 20580 ;0x5064 special functions: GetEyeVec

;endif ;FrameCounter
endif ;OnPCEquip
endif; inMenu


end cbn_sc_printEyeVect
Great! I'm going to have some fun with this tonight. Thank you so much for sharing this with me.
I am at present trying to write a short ranged teleport spell, and I have remembered how much I hate trig
I have some script segments that might help you out with that Yac. I'll post it later when I get home.

BTW, I did that same thing, but I used PlaceAtPC to get the coordinates I needed. The advantage is that (besides from simpler script) it won't place anything in the void or where another object already sits.
I used this script:
CODE
begin YAC_SRT_Test

    float eyex
    float eyey
    float eyez

    float timer

    if ( menumode )
        return
    endif

    if ( timer < 1 )
        set timer to ( timer + getsecondspassed )
        return
    endif
    set timer to 0

    setx eyex, eyey, eyez to MGEGetEyeVec

    if ( eyex> 1 )
        return
    endif
    if ( eyex< -1 )
        return
    endif
    if ( eyey > 1 )
        return
    endif
    if ( eyey < -1 )
        return
    endif
    if ( eyez > 1 )
        return
    endif
    if ( eyez < -1 )
        return
    endif

    setx eyez to xArcSin, eyez

    set eyez to ( eyez * ( 180 / 3.141592 ) )

    messagebox, "%.2f", eyez


end


And it didn't return a constant value (even with disablePlayerLooking enabled), and it only gave the right result about 1 in 4 times

EDIT:
clownbaton script worked better, exactly 1/2 chance of a correct answer, which I may be a problem with the script rather than MGE. Looks like I am back to using pipes sad.gif


QUOTE
BTW, I did that same thing, but I used PlaceAtPC to get the coordinates I needed. The advantage is that (besides from simpler script) it won't place anything in the void or where another object already sits.

Did you only move a set distance forward then, as I can't see how you can test for colision along a line using only placeAtPC.
QUOTE(Yacoby @ Feb 13 2008, 07:01 AM) *
I used this script:
[code]begin YAC_SRT_Test
clownbaton script worked better, exactly 1/2 chance of a correct answer


This is because you gotta wait for one frame before you can read the value while the message boxes output to the screen every frame.

I always liked the wizard's short range teleport from Gauntlet Legends - Seven Sorrows. When I test for collision I always compute the predicted future position and compare it to the current position before updating. Works well.
Submit a Thread