So not sure how I can test it? I saw the bitbucket. Is the dll made already?
So not sure how I can test it? I saw the bitbucket. Is the dll made already?
Pardon my lack of knowledge, but does the moon have new texture mode ?
TileFormat = 2
ELLIPSE <height> <lng> <lat> <major> <minor> <phi> <falloff>
or
RECT <height> <lng> <lat> <length> <width> <phi> <falloff>
What I proposed 2 days ago is not done yet (to my knowledge). But I'm close, I guess I can release a first cut tomorrow.
Pardon my lack of knowledge, but does the moon have new texture mode ?
i don't want to be any bottleneck here. I am about to leave with family for easter holidays and packing everything with 2 small daughters it's quite a challenge so I won't have much time available for about a week unfortunately.
No worries, I've thrown in a quick&dirty parser. If it turns out to be a good idea, you can always take a look over it and do a more stable parser for it, or perhaps also some in-simulation controls.
Do you think that Jarmo and Kuddel will add this to the D3D9 until martin do it for the Beta or will you/us be forced to update the system in D3D9 at each release? or shall we take this as a demonstration and that's it?
Rect -3000 -33.4375 +41.125 2500 2500 0 50
Rect -2400 -33.4375 +41.125 1000 1000 45 50
Code:ELLIPSE <height> <lng> <lat> <major> <minor> <phi> <falloff> or RECT <height> <lng> <lat> <length> <width> <phi> <falloff>
* <height> is in meter, supposedly w.r.t. mean sphere radius
* <lng> <lat> are longitude and latitude coordinates, as defined in e.g. base configuration file
* <major> <minor> are ellipse major and minor radius in meter, <minor> defaults to <major> if not defined - the meter definition might not be exact, as it uses a decimal degree guess at the latitude circle
* <length> <width> are rectangle length and width in meter, <width> defaults to <length> if not defined - meter definition same as above
* <phi> is rotation angle in degree from equator, with <major> and <length> being parallel to equator
* <falloff> is the percentage of the shape radius where transparent merging with original height is done
Lines with comment start and/or too less arguments are ignored.
just the first quick and dirty feedbacks:
- I tried on a random location and it work as expected, but then I tried to flatten the second runway of palmdale base and it didn't work. I haven't checked myself yet, but maybe palmdale use elev_mod and this is the root cause somehow?
- The falloff is an integer right? It seems to me from the code that it's an integer that is divided by 100 after parsed so 50% is 50 and not 0.5, correct?
- are multiple definitions per file allowed? so if I have a base I can put all the circles and rectangles there?
* From what I have seen, the filtering should also trump the elev_mod data. It does so in the case of the cape, at least.
RECT 766.1 -118.072702 34.629199 5000 5000 0 10
Then I don't know why the palmdale flattening is compeltely ignored.
basic test, a big square centered on te runway:
Code:RECT 766.1 -118.072702 34.629199 5000 5000 0 10
Height is integer, not floating point. It gets ignored because it is not parsed correctly.
// ELLIPSE <height> <lng> <lat> <major> [<minor>] [<phi>] [<falloff>]
ELLIPSE -2000 -33.4375 +41.125 2500
ELLIPSE -3000 -33.4375 +41.125 2000
Very good proof-of-concept! :thumbup:
One question (I haven't found time to check for myself):
Can the patches overlap? So a "ring" could be made with:
Code:// ELLIPSE <height> <lng> <lat> <major> <minor> <phi> <falloff> ELLIPSE -2000 -33.4375 +41.125 2500 2500 ELLIPSE -3000 -33.4375 +41.125 2000 2000