@Mav-jp:
Meaball is not a problem, it does not even require code change (works like a vertical PAPI)
the problem is the visibility of meatball according to the size of the object …. in order to see it from correct distance we would be obliged to increase the size a LOT.
this is the same problem than the navlights that are 1 pixel at far distance and hence not reflecting at all the reality of it…
we would need smart scaling for those lights…
How does the meatball script work?
If we look at \src\graphics\bsplib\scripts.cpp, … the code looks like this:
// Approach angle for Carrier MeatBall - 13 switches (0-12) for vertical Glide Slope
static void MeatBall(void)
{
float angle = (float)atan2(-TheStateStack.ObjSpaceEye.z, TheStateStack.ObjSpaceEye.x);
static const float GS = 3;
static const float angles[] =
{
GS + 2.3f, GS + 2, GS + 1.7f, GS + 1.3f, GS + 1, GS + 0.7F, GS + 0.3f,
GS,
GS - 0.3f, GS - 0.7f, GS - 1, GS - 1.3f, GS - 1.7f
};
static const int NANGLES = sizeof(angles) / sizeof(angles[0]);
ShiAssert(TheStateStack.CurrentInstance->ParentObject->nSwitches >= NANGLES - 2);
if (TheStateStack.CurrentInstance->ParentObject->nSwitches <= NANGLES - 2) return;
angle /= Degrees;
for (int i = 0; i < NANGLES - 1; i++)
{
if (angle < angles[i] and angle > angles[i])
TheStateStack.CurrentInstance->SetSwitch(i, 1);
else
TheStateStack.CurrentInstance->SetSwitch(i, 0);
}
}
So I did a simple model with 13 switches (0-12) and every switch has one "Switchstate- 0",
and I've set nSwitch to 13 in the LOD Parent Data. (highest switch is #12, so 12+1=13)
In the root node I've set "Meatball" under scripts, and I can activate/ deactivate
the switches in the Viewer just fine. (in the picture is switch #8 deactivated for example)
In LE the model looks like this:
[url][img]http://i45.photobucket.com/albums/f82/lazystone/testa/1_state.jpg[/img][/url]
To avoid to do a carrier approach for testing every time, I replaced
PAPI(near) CT#1006 with my Model and created a simple TE where I'm on the RW,
to check my work using the 0- view, then changing the angle which looks insim like that:
(note the datum lights on the right side of pic, the source lights don't work)
[url][img]http://i45.photobucket.com/albums/f82/lazystone/testa/2014-11-26_234928.jpg[/img][/url]
When I change the view angle then the remaining PAPI(far) works fine, but the meatballs sourcelight don't work here.
Looking at the sourcecode again it says something like...
If angle X then switch X and it's Switchstate=1,
else
switch X and it's Switchstate=0, (I'm no coder here, LOL)
So I've used the same nodes from Switchstate #0 to create an additiionally Switchstate #1,
which looks in LE like this:
[url][img]http://i45.photobucket.com/albums/f82/lazystone/testa/2_states.jpg[/img][/url]
But even with two switchstates the Meatball don't work here. :(
I've tried other combinations as well, like using just one switch #0 with 13 switchstates,
which works fine using the "cycle 10" script, but the Meatball script will not work.
Now I'm out of ideas and I hope someone can help me out, please.
If anyone want to take a look at the LODs you can DL the two LODs and one TE here
[url]http://www.mediafire.com/download/s083wda977dd93n/Meatball_don't_work.rar[/url]
BACKUP your files before replacing PAPI(near) with my simple model.
I really hope there is a solution, because doing a meatball with just geometry (no switches) sucks, IMHO,
because we'll always see more than just one sourcelight if we use 0,3 degrees steps for glide slope.
Thank's in advance!
Cheers,[url][img]http://i45.photobucket.com/albums/f82/lazystone/Smileys/Santa/santa029.gif[/img][/url]
LS[/i][/i]
