Posts by ussiowa

    Ed,

    I just today created a new area adjacent to an earlier scenery area of mine in an effort to expand the original. Unfortunately along the northern border I'm seeing a few tiles of low res default scenery that should be the high res scenery I just added. For some reason (and it's probably my fault but I don't know why) separate created scenery projects don't want to play nice with each other.

    There is probably a good explanation for this and I need to go over the steps to add new areas so they properly work with older created areas, but I really was under the impression that separate areas created with Geoconvert would just work seamlessly with each other. Obviously they don't, but I will reexamine the tutorials and posts to see what I'm missing.

    I have added a 1m high res area that is completely within the borders of a 2m res area ( a city within a larger area) and it works perfectly. To repeat, the issue I'm seeing is getting areas that overlap to some degree to work seamlessly together without having low res default scenery show up.

    So, you're not alone...

    Exact same issue here. Of the whole area, Hidef tiles appear when I fly over sometimes, and sometimes disappear also, and in the overlap it's a switch between hires tiles.

    Thanks ussiowa. Well i guess there are a lot of different ways to fly. Maybe i should just switch to one that doesn't need functionality that FS2 currently lacks.

    That said I'd be very happy with full cockpit control with "hands" like leap motion, all buttons functional, radar, maps, and nav stuff enabled, etc.. then EMCON would have to be pilot choice. Also a map available on a tablet, or some kind of notebook. I thought you guys had found a solution with OpenVR or similar.



    Am I (and JvanE) the only one who flies this way and experiences this problem?

    Nope, I only fly stick and rudder (and mostly military so not much info really). No flight plan, no VOR, no whatever.

    Maybe notes (or a map with names and features) would add some, but without them I manage anyway.

    It's a great lesson in geography and let me tell you my knowledge of the country has improved much, and I knew the southwest pretty well already.

    Finding LV at night taking off from LA was tough at first, you just guess the heading and fly, then by feel. During the day, just keep your markers (freeways, towns, dry lakes, etc.. in check), super easy really.

    Nowadays I "cheat" I use the HUD button, which gives me airports codes and names, and mileage. Still not much of an aid, you still need to memorize what is where, but it gives you a much better placement.

    There are many places in the southwest where I can be dropped blind in the desert and I pretty much know where I am.

    Now NY, not so much, I still get lost a lot because I don't know where towns are on the map. So I fly, try to find something, find it or not, then when I exit I check with google maps and refine the experience. After a while you just can fly from pretty much anywhere to anywhere, you recognize mountains, valleys, towns, roads, rivers, lakes, etc...

    And that's the super fun scenery of FS2, so much to see and discover.

    Like today's flight: take off from Sedona (super special air force base, the Sedona Airport Vortex brings me happiness^^), 2 hour flight below 200 ft in canyons and what not (to avoid radar detection, complete EM silence too, but for that I have no choice, it comes that way (no radar, no weapons)), corner speed (for maneuverability and stealth) all the way south for a simulated bombing run somewhere around Gila Bend (I won't name the target here, pick anything, use your imagination). Pop up for simulated bombing run (thus I presume interceptors sent after me), so quick diversion, drop back on the deck, evasive run and back to Lake Havasu for landing (again all below 200 some feet AGL including landing approach (you fly the airport, don't know the runway direction, find out visually, initiate a turn, drop everything and put it down, heavy wind, turbulence, thermals, lots of clouds, all there). Yeehaa! It's a hell of a run 500 kt 200 ft and below between terrain features and fun fun fun.

    No map, nothing, just a good idea of headings, and geo feature to use for the run, and at less than 200 ft it's hard to get your bearings as your horizon is pretty close, on purpose. It's tough but it's what makes it fun.

    I wish I had fuel implemented as well as some adversary AI, or online, or collaborative possibilities (wingman, RIO), but hey it is what it is, so imagination makes the play.

    Here I'll give you a fun waypoint on the way: https://www.google.com/maps/dir/34.58…m/data=!3m1!1e3

    When using the prop change function on the f4U it drops the gears at the same time, and no I didn't assign the same button for both, on other airplane it feathers the prop and leaves the gears alone

    Yes , wow, it looks like this scenproc is a real game changer, at least for us the user/tinkerers. Really sad we have to duplicate so much work.

    I mean this is being incrementally better every day. First Lisboa, looked good, at night looked unbelievable. Now Munchen with different light colors and Saanen with custom textures.

    And if a city like Munchen takes 150MB, then we can have a huge rural area fully populated for the same thing.

    That would be pretty awesome! Maybe we can even animate the pilot body and link it up to VR hand controllers so that you can look over to the copilot seat and wave or something. That could be fun! And then every one in the cockpit could interact with it, change switches maybe even grab onto the throttles and move them...

    Yes yes yes is my vote, can't wait for a RIO even though there are no weapons.

    Thx Andre, I would have to know how each one of these variable is defined. Clearly the name is not "all inclusive" as we have 2 different one named accel or velocity, and they are not identical obviously.

    Once we know which is which then we can calculate, there seem to be more than ample data to do so. But Jan and Admin also seem to have the proper info and may chime in with the answer.

    It may require a transformation matrix, but I suspect it's done already in some of the data, so it may be simpler, like I posted.

    if there is an acceleration output already present then just take that and divide by 9.81 [m / s^2] and you get "g"

    If not you can still add a sender manually in the tmd files and make it send the accelerometer output.

    Otherwise, if you have access to the body's speed and rotation speed then you can use normal code to calculate the acceleration...

    I'm not sure what you have available with the dll :)

    Well wait a minute, that just depends. G are usually for normal (to the horizontal median plane of the plane) acceleration, and furthermore the acceleration given in the file may be a combination of multiple accelerations (i.e. "total" and absolute acceleration vector)

    So if the output is general acceleration (including engine thrust for example) or any variation thereof, it may not be quite the result needed.

    G is normal acceleration minus (gravity as a projected vector) unless I'm mistaken which is entirely possible.

    horizontal flight ->0G

    upside down flight in a 2G radius loop, at top ->1G

    same on either vertical side -> 2G

    Alternatively it could be absolute G, which would mean in my examples, 1G for horizontal flight and 2G on a 2G loop verticals positions, and 1G at top.

    I don't know about G meters in commercial planes (even if there are any), and I only surmise about G meters in military planes.

    EDIT: OK I saw that you guys caught part of this issue already, after I made this reply, so ignore appropriately.

    Admin is correct.

    Jan, I assume he means "world up" as in normal to earth plane, (which is different than universe up which may be normal at pole and tangential at equator (and it could even get more complicated than this with celestial mechanics), I don't think it is used that way, too complicated and not necessary. So for all intents and purposes, "world up" is most likely normal to earth plane, and it's assumed the world is Euclidian (flat from a mechanical standpoint), and thankfully so. This however is still not normal to "plane's median horizontal" plane, which is what is needed.

    The Euclidian assumption is a fair assumption for airplane mechanics, Coriolis effect and other gyroscopic effects are not fundamentally important for this use. (they may have a role in real world, but probably not that important that we need to simulate it, especially with no waepons)

    And then there is "all accelerations included" which could be what the x,y,z is, so one may have to extract some from it.

    If you already have the x,y,z aircraft mechanical parameters, then all you need is z accel (or get there from speed and vector orientation calculation) and then minus projected gravity, as I illustrated above.

    So formula would be G= (Accelzaircraft - 9.81 *sin (angle between x aircraft and -z world))/9.81

    Whatever component you don't have should be inferred from the one available.

    Therefore maybe the answer for IPACS could be, if it's not too hard, to have any or all of the following sliders:

    - Exposure (brightness)

    - Gamma (contrast and artificial dynamic range compensation)

    - Color Temperature (white balance)

    Technically one can adjust their display to do all that, and hopefully the FS2 scenery is "compromised" to the mid range, but like they say, they rely on imported data, so a lot has to do with the capture equipment and conditions.

    One thing for sure, to aim for a perfect "out of the box" image for everyone is impossible. Mere displays technology, evolution and settings will ensure that.