Flexman

I wonder how well it scales for flight simulation. The weather and sea effects lend themselves to Search and Rescue bad weather training.

Cheers, I'll give it a go on a trash model. It's sometimes handy to fix a typo instead of having to go through the whole export process. When I need to export a single object from UU3D this will be very handy, thank you.

/handup I have a question. Does this work for child objects?

lol I love you guys, I really do. I recall the weather was totally **** and we had to process the wind and rain noises out of the engine recordings. The irony is that I'm now mixing IN rain noises. MY blog is supposed to get imported on a regular basis but hasn't done it in a while. Just as well as I tend to blog during coffee breaks when my brain is free-wheeling.

Fingers crossed the weather is not too bad tomorrow at Gilze-Rijen air force base. Our man in the Netherlands is prepared for a day of audio recording for the Apache and Chinook. Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat' Source

I have to say wow, I dropped this into my map to have a look and it's really great. Looking forward to seeing what you do with clouds.

Just give me an airlock to play with

I want to run some non LE code in another thread while rendering a scene in another. Has anyone done this using blitz?

Glad to hear it, and it looks really great too. Nice glow.

Casting is how I get to the loaded map layers for generating an overhead map, and this is how Josh does it in the editor too. So it's prety safe. Local cmap:TBuffer = TTerrain(game.scene.terrain).colormapbuffer; TTerrain(game.scene.terrain).normaltexture.Bind(1) ; SetShader(map_shader) ; ... ... DrawImage(cmap.colorbuffer[0], 0, TSD_MAPSIZE, TSD_MAPSIZE, -TSD_MAPSIZE) ; You can get the heightmap and mapsize goodies too. So it's very handy.

Try casting, like this? If GetEntityKey(ent,"class") = "Terrain" Then terrain=TTerrain(ent)

Short of making your own shader that's about as much as you can do I think. The book ShaderX5 covers something like this in the (small) section named "A Simple Area Light Model for GPUs by Aick in der Au". He implements a Blinn and Phong lighting equation for rectangular area lights. Probably too much for what you want but I mention it in case you're really serious.

In the process of sweeping changes to how the game loads vehicles and other data. A lot of data the describes how the virtual cockpit works, where you sit, angles of views etc. was not available early on and since my long term plan is a system in which we can serve you new vehicles down the wire, even adding the Chinook was going to need a bit of fiddling around. Some data was in the object LUA, some in an external file, some embedded. It wasn't the original intention to build vehicles this way, but it was expedient at the time. Now it's time to put things right and make a nice neat all-in-one package that's flexible (after all that is my middle name). Another thing I wanted to do was allow the ability to tie entities to simulation variables, so a cockpit altimeter needle can be assigned to the vehicle.baroaltitude parameter. Hey does any of this sound familiar? If it does then you've done aircraft/gauge development for Microsoft FSX. While this isn't anywhere as deep, it's enough for us to be able to bundle new helicopters and even ground vehicles later on. I'll publish a list of available parameters later when I know the scope myself. MPDs and HUDs can be copied to specified entities using the name of the glass instrument output and the name of the surface you want it displayed on. * edit* This is pretty neat, I've now added a bit more flexibility to what we can do with the cockpit inputs. Each individual switch position may now have a delay (hold at this position n seconds before firing) and fire an additional command at that position. * end edit* The FFD (dynamics) data could be added too to describe how it flies/drives, that's to be look at later. There's still a quantity of code required to determine message priority, client/server authority. but at some future time if we want to add "user roles" as a message filter to any control, this is flexible enough for us to drop that in and not rely so much on coded game logic. Filtration and authority of incoming messages are important for multi-crew vehicles in multiplayer, you need to be as lean as possible (I bake state flags into bit fields as much as practical). Not all switches need to be recorded or sent, some are vital (crew helmet positions need fast updates for the HUD and sensors), some (wipers/lights) can be delayed. The "command" string in the cockpit switch data is sent to the messaging system, if it's a network level command it's forwarded to any needed clients via Raknet. As our vehicles are 'portals' there isn't much physics going on for attached crews. As a gunner, your helo position comes from the pilot and interpolated, your sensor position is based this, and that in turn is relayed back to the pilot. So there is room for some weirdness but not too much I hope. The way the Apache works actually works in our favour. Since each weapon system has a designated 'crew in command', the game logic knows who's the shooter and the positional data from the client in authority is used. And if you're not targeting a visible entity (e.g tank) then you're aiming at an invisible one (a pivot). This reduces oddities caused by differences of position reported by actual and interpolated crew positions. Source

"There are no people here, no PEOPLE" Just a constant flow of TV presenters and documentary makers. Everytime I see your work I'm always wishing that the engine could stream in all that data instead of having to one-shot everything. It seriously curtails what you can do with it. But stunning work, all the details you put in shows off the best of what the engine can do with a bit of hard work.

Yes, first thing I did was to toss the mouse. Those iMacs are expensive, this summer my kids went to do an animation workshop ran by the local city council. Their media room was like a modern class room, desks around the walls, each of which had a 27" iMac. My jaw fell when I thought how much all that stuff cost. I remembered, one of my former clients used to be in charge of local education spending. He's now an Apple dealer, the swine. Our tax dollars at work. Great machines though. Got to love a keyboard you can use for etching bathroom tiles. As hunks of metal go, it's almost as good as the long forgotten Memotech MTX 512. Almost solid alu chassis. I'm quite eager to get to work on a Mac port of some games, I have Unity licenses for that and the iPhone but I'd much rather use LE tbh as I'm much more comfortable using it. If you want someone to help playing with Mac builds to iron things out then count me in. I'm happy to do some testing and trials for the sake of getting in some early familiarisation. Can't stand iTunes though. How not to design a music library, it's a spreadsheet gone mad.

Awesome, yup that works.

I just tried using an Orthographic camera (CameraProjMode(mapcam, 2) ; this produces an exception error in Renderworld(); Setting cam mode to 1 (normal) and no problem. Is orthographic not working atm?

Completed changes to the HUD section of the config file. <HUD col="1.0, 0.8, 0.2" glow="0" shadow="1" breakoutfpi="1" /> I'm using the TinyXML lib for config functions, it's been fast efficient and easy to use. I added a new option today that was born out of looking at videos of games projected onto huge screens giving almost 1:1 scale. Before my tripplehead PC went pop I had a problem with virtual symbology relative to HUD size. The larger the screen, the smaller the HUD relatively. At it's worst, the effect was looking through a keyhole. So I removed the keyhole, the "breakout" option in the HUD config will plot some indicators outside the HMD area and in a relative scale to the screen size. This makes it more useful at the expense of not being totally accurate, hence the option. In the screenshot below you'll note the user colour option for the HUD symbology in effect alongside the flightpath indicator outside the HUD buffer (right of the altitude bar in the hilly bits). This is easier to use on a laptop too where screens are not as bright and it's easier to pick up. There's been an intermittent windows exception error when launching the game (release build). I tracked this down to the old controller config loading which uses IO streams to pull in a data-file. Something is going on there. I need to re-do the controller settings anyway using XML to store response curves and other tweaks you can't do right now. Just a pain as laptop drives are a touch on the slow side. Source

yes it's all flying and working, nothing posed in these shots.

Thanks for the link, that was brilliantly LOL funny. Yes life WAS terrible in Thatchers Britain Love the description of it being a cross between Nascar and Saving Private Ryan. Too funny.

Spent a lot of time today house cleaning. No not code, literally the house. It's amazing what teenagers can do to your treasured Monty Python DVD collection, it's not funny. Stop that, it's silly. I over-complicated the map drawing and stripped it down. Added functionality to the TSD page for controlling the map scale. I'm happy that it will work with 3rd party maps too. Oh I just noticed in the screen shots the scale index is off by one. The green colour is from the low elevation range but I blend some of the terrain colour too which I should perhaps leave out since it gives a false impression. I'll add a button on the page to cycle map modes rather than have to go through a sub page perhaps. Otherwise it might get (more?) confusing. Hey, Longbow 2 had one button to cycle through NAV/ATK and BOTH....and no map unless you flew the Kiowa (I think). So tonight I'll add the aircraft datum (the helo symbol on the map focal or point of rotation) and begin adding the glyphs for the waypoints and other symbols that we want to appear on the map. Should finish adding the waypoint data while I'm at it (ETA etc). I can't work out endurance time yet as the fuel data isn't yet present. It varies with payload and altitude, there's a table in the A model dash-10. Would like to have an elegant algorithm to approximate it. Source

The FPS font will use whatever the last font selected was. If you want the default font back see this thread...Default Font

I don't think Newton physics will give you the results you want. You can get a basic approximation but what I found with Newton is that composite bodies don't work well together. Fixed joints lag behind the main body at high speed, ugh, bit of a mess. An early experiment I tried had a rotor disc as a static body on which I calculated lift and thrust, what would happen was it would react with the hull and cause all manner of unstable movements at various velocities. I would suggest keeping it simple or add your own physics, you can patch that into your model using an update callback which is what I ended up doing with a very sophisticated mini-physics engine dedicated to the purpose, and it's still not working properly. If someone can fix or find a workaround for composites with Newton then your proposed method might be workable. The concept is sound but actually implementing it never worked for me.

Working on the tactical situation display elements, the vector font output was never quite as crisp as I'd hoped for but that's now fixed by keeping the 1:1 scale and changing the ortho projection matrix. Bigger works better than smaller when it comes to float accuracy with consumer level drivers that focus on games and performance I guess. Still have the map scale to do, that's forming part of the mission terminal code. But the rest of the TSD is coming together. I need to put an upper limit on symbols otherwise some numpty crews might get a bit happy adding symbols to spell rude words or add smiley faces to the map. Added a basic HSI rose function and added that to the TSD NAV mode. Everything seems to mask OK. Only issue so far is the pop-up repeaters, they are currently too dim/dark, see second image below. You can see the vector fonts are much better defined in the above image even though it's a bit feint (and oversized for the window res I use on my laptop). So far, the Apache avionics suite includes a basic navigation system, 5 radios, two almost complete HMD modes and a tactical system in progress. It's actually getting pretty fun to fly around now, some bugs notwithstanding. View system could use some love as well as the stabiliator to stop the nose-down pitching. Source

Another little progress update but first a diversion. Yesterday I took some time-off to brush up on gaming skills and really enjoyed Disney Interactive's "Split Second", one of the few car games I keep going back to since I typically find racing games tedious (lack of skill and patience on my part). However this game is almost pure adrenaline and I find my self coming back to try and shave off 2 seconds while avoiding exploding aircraft and collapsing control towers. Split Second is actually the perfect arcade car game IMO and probably much overlooked in a busy genre. It screams for a post race replay option though. Enough digression. Not much to show yet as I've only spent an hour or two on it this morning, I hadn't put in the VR cockpit data for the TSD buttons so went and put that data in. Had some color issues down to a mix of LE and OpenGL and sorted out the MPD scale for rendering the currently loaded nav map image. TSD stands for Tactical Situation Display It is the most complicated system in the helicopter. Which I will strip down to the bone for the first release otherwise I'll be at it for months. The TSD presents a 'Gods eye' view of your helicopter and your environment. Downloaded target information, friendly unit sightings, route navigation and more is presented here. It is a moving map system that can be frozen, panned and scaled. I need to slim it down into something manageable. Also there are many functions that are desirable to use in the command HQ tent planner and also other helos in future. Our TSD will feature Fire zones (aka PFZs, old school but everyone will want them) Route editing Threat, target and hazard objects Nav and Attack mode (PHASE) Freeze, panning, zoom Crewman cursor acquisition, click on map and point will be made virtual in the helmet display. So there's a few things to do but also shared with the ground planning system on the HQ tent computer. For the base map, it's using the TTerrain() object on the loaded terrain entity (I needed to cast it to get access to the height and normal map data otherwise it's considered a TEntity). A shader converts the normal map into an intensity multiplier ( float intensity = dot( normal , lightdir ) ) for the colourmap, multiply the diffuse and intensity and voila you get a shaded relief map just like the one in the Leadwerks editor (except I don't need the realtime light position and colour that the editor uses). To this I'll add a colour lookup table from the heightmap and possible some contour lines. I've not used an "lut" function (look up table) in a shader yet so it will be a fun little exercise. Contour lines could be done by setting output colour if the heightmap value is a multiple of 10 (meters) or whatever value I pass to the shader. This just colours the pixel if the value is in that multiple, steep terrain might bypass that value so results will be a bit patchy depending on the source data. I'll look into a proper contour function. Keep in mind the heightmap in terrain doesn't have a flipped y axis. Source