Flexman

Have you got a shadow shader in there? shadowshader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse_alphatest.frag"

Source

I like the idea of having a GunCam view. However it means increasing the texture detail on cannon as it really wasn't meant for up close viewing. Heh, I have you in my sights. Trying alternative offsets for the cam to get a good viewpoint. You can see the spotlight on but we don't yet have it deploying from the hull. Source

Yup, perhaps the most nauseating camera view is back. One that a still screen-shot and an fps hungry FRAPs recording IMPROVES. RotorCam is like having your brain ripped out by your eye-stalks and soaked in vinegar. A virtual camera is strapped to the underside of blade number 1 and everything else is a blur. Only use I can think of is a debug aid when we get to blade flapping etc. I'd like to thank Macklebee for helping me sort out the LUA object passing to get this working. RotorCam for all your video game torture needs. Source

OK, I think I follow. I'm using one buffer to render a non framework camera to, and another camera which does a framework render. The other buffers use OpenGL commands. If it's something that's in Framework then maybe it can be 'retro fixed' since the BMX (always makes me think of bikes) is provided. I'll have a go and see what happens anyway.

What's this about buffers and screenshots? I have around 6 512x512 buffers for instruments and about to move to 2.40. This is not something I want to hear.

AD's SimHQ Dev Diary - Road works Interesting post on improving the look of the new roads which are meshes exported from 3DMAX using a number of different post processing techniques to level them to our height-map. He touches upon adjusting the height-map to sink roads into the terrain, thus ageing them. Note that the heightmap images in this post are flipped vertically. If you plan to use them as a map at a later date and get confused then this is why. Source

I was replying to say a big thank you as we can finally think about moving to 2.40. As regards billboards viewed from above, I'm planning to add a dynamic view range based on alt. Little things like that will 'go away' in the polish phase. But thanks for pointing it out. These new commands make it easier to deal with this (not so much for vegetation but other things). So hooray.

Just got back home and Dave left a nasty sight in my MSN window. No, not another scene of drunken debauchery, actually I have to complain, there's been a distinct lack of that. We got to discussing visual representation of damage. Different ways we can do this. I write it here so I can remember what we discussed. We looked at some complex set-up of assets for iL2, the results of which are impressive but it hardly makes for an easy pipeline, especially if we want to quickly add more aircraft in future. After some thinking we boiled it down to two simple options. The first is application of a damage texture on parts (child objects) of the helo model that match the aircraft's damaged state. And Dave left me the following image, a simple test to check it out... Another technique is decals. Now I've looked at LE decals before and I don't think they will work everywhere on our map due to floating point and surface fighting in the outer regions. These are patches that positioned to be almost co-planer with the surface of a model (like the decals you stick on a model). If they work, they have the advantage in that they should work for everything. A more complex alternative is a new method of decals using a glyph shader. What we'd do is have a single texture upon which, in a grid patter is lots of damage and battlescar images. We pass this glyph texture into the mesh frag shader along with a damage map of the aircraft. The shader will splat areas from damage map with psudo-random glyphs of damage. This might look OK to pretty bad depending on textures. I'm quite keen to try this as I want to add such a system to give players some custom paint jobs reflecting game achievements/rank (such as earned 'shart teeth' and other hokey things). A similar shader is already present in LE version 2.40 for adding plaster-work to brick walls. Now 2.40 has some new commands for adjusting LOD ranges, we're almost goo to go to move the project to the new version of the engine. For now, keeping it simple works and I think the damage texture looks alright. Source

I wouldn't go so far as to say ignored. Getting to the point where you need these kinds of objects is a pretty big step. My ideal way of working with NPCs would be to drag some form of "Crowd" box into the editor and adding characters, specify number, variation, movement pattern in the box. Not just people but animals too. Chicken runs, birds, cows. That would be a pretty high-level operation, but wouldn't it be a fantastic way of populating such scenes? That would be awesome. Even those people that use Leadwerks for architectural visualisation, putting people in the scene that move about would be pretty handy.

Almost 12 months now, started from scratch last Sept after a few experiments with Leadwerks engine. But I've been working on lots of stuff in other areas before. I think the Minnesota air national guard was using some of my old mission planning software at some point for some cheap desktop training (or just plain fun, who the heck knows). I keep seeing it about on torrent sites which is handy, if I ever need a reg key I can download a keygen, saves me hours of looking through old hard-drives for my original generator. I'm much more familiar with this kind of stuff. Had a rough plan from the start, that's the key to getting something finished. Knowing limits, where to compromise and hardest of all, not get distracted. I might not be very good but at least I'm persistent. Having said that, I attempted to write this game in 2002 but didn't have the time. The research has proved useful though.

Well yes I thought bad things would happen too. Turns out the Apache stops the pilot from doing stupid things like that and freezes out controls and switches so it never happens. I've added game logic to to do just. You can no longer advance the power levers past IDLE until the rotor brake switch is set to the OFF position. The switch event will fire but won't move, so I can add some warning or message to the player as to what to do next. To bad I didn't script all this but I didn't know we might need it.

I'm putting together specifications on the mission side of the game. To me, the bit that you 'play' is every bit as important as the simulation side, and while it's taken a back seat for now, things are getting to the point where it's time to get on and make it all work. Going through some of my older material on this, it needs to play like Longbow 2, have the crew management elements from Gunship 2000 and strategy elements from tactical board games on guerilla warfare and a bit of a story element that wouldn't be out of place in a Chris Roberts game. So where do we start? Units, missions, events and triggers. Units perform missions, missions contain waypoints, events and triggers. So lets start at the top and work our way down. Missioneering Not many will remember the last iteration of my mission planning tool and generator, Missioneer Delta pictured below, circa 2000, seems like almost 10 years ago :/ The plan is to put in something similar onto the command tent terminal you can operate to change waypoints and assign untasked airCREW to helos to carry out listed missions. In some ways this is not unlike Enemy Engaged. Missions are not necessarily assigned to aircraft (they can be), but we'll assign them to the player, AI pilot or crew. Like the arming system, it will be possible for a player to take the role of a commander and assign missions to aircraft that pilots execute. You can walk around and choose an aircraft that's not already assigned (see it's info plate when on foot for status). In future we hope to have a selection of helicopters/vehicles (CH-47) but we're focused on the Apache. When the player boards the aircraft, this is like loading a data cartridge with your mission detailed into the aircraft's avionics. The TSD will be updated with waypoints, times and mission page populated accordingly. First man in sets the mission. The mission ID# key is set in the vehicle entity. This is reset on one of two conditions, the player has exited the aircraft for 5 minutes or the master zeroise guarded switch in the cockpit is operated. In the case of the latter, a new mission profile can not be loaded until all crewmembers have exited the aircraft. Mission ID# is just a key reference to the hosts list of active missions which can be viewed on the command tent terminal (connected to the projector). But we're getting ahead of ourselves. Missions and units need a detailed specification which is the point of this blog entry and my current task. Running under the surface of the simulation will be the all important campaign engine which iterates through units. We'll take the term UNIT to mean a collection of vehicles, a "group entity". Lets look at an old user editable unit form, take from Missioneer. Nothing really remarkable about it, just happens to be handy. So we can see some of the basic parameters of a unit. There's a list of entities than make up the unit, a 'formation' which is a list of relative positions that each member of the group will attempt to follow (we'll have some behavioural exceptions to this). An orientation, direction to face when at rest. A name, something fancy and military. Skill level, agression and some factional information. There are also some timers, our game runs in a real-time 24 hour clock cycle (with time advancement). So unit timers might be relative to an absolute time (world time) or mission time (from dust-off). Timers have an enabled/active status too in case they need to be activated by triggers. For example, if we want a group of insurgents for player assigned patrol mission to spawn when a player has taken off, the mission engine will assign a MT (mission time) of "00:00:00mt Active", but we might want them 5 minutes into the mission, or not spawn at all except by some trigger, such as a player entering the engagement area. Or we can set the unit destruction time (just means the de-spawn time). For example, a rescue against the clock, get to them before they are discovered by encroaching insurgent forces. Once depawned, that would trigger a unit removal message which another event trigger can listen for, signalling a mission fail. So timers are simple unit level events that require no special handling by an event system. But for our game to handle recognition of a "win" or a "fail" situation we'll need to add a basic "cause and effect", a "cause" being destruction of unit "x" with the "effect" being "mission complete". Mission Events SpawnUnit (unitID) DestroyUnit (unitID) SetUnitWaypoint (unitID, waypointID) SetUnitFlag (unitID, active|weapons_free|godlike|formation|state, param) SetUnitFaction SetMissionResult SetWorldFaction( factionID, delta) SpawnObject (objectID, parameters) CreateWaypoint (unitID, waypointID, location, speed, altitude) Play Audioscript (script or audio filename) Mission Triggers (in any active combination) MissionRating (percent, win|loose|draw) MissionTime (+ - secs, MT|LT) UnitDistanceFrom (unitID, targetUnitID, distance_meters) UnitDamage (unitID, damage_percent) UnitWaypoint (unitID,at|before|after, waypointID) UnitStatus (not_in_combat|combat|flee|panic|landing|takeoff) UnitInZone (unitID, zoneID) FactionDelta (factionID1, factionID2, + -value) DiceRoll (percent) These are enough for the campaign and mission system to generate pretty much most situations. Now the tricky part is to build the logic to generate seemingly intelligent behavior and entertain missions using this small command set. And here is where we can have a lot of fun. We could extend the complexity of the logic further by adding a LUA Get/Set interface for the event system. Then user made missions can apply some complex logic. Even creating whole missions from a LUA script. This is not something we want to do at this time. But for the future, it could be done. Source

That's a really interesting read MG. A subject that I've only just considered, ambient mobs or mobiles. Reading what you wrote sparked a few ideas on zones and assigning such spawned entities to different movement behaviours within them.

Well, just to throw this into the mix. The material can use a shader with the "invisible.frag" which won't render, but the shadow shader can use your standard "mesh_shadow.frag" which will render (should render) the shadow. So you have two materials, one to render the material you can see for 3rd person, paint it with the invisible material for first person. This is how I intend to do it for our pilot character.

Actually the rotor brake system. I'm not really clear what would happen if the rotor brake is off when you move the power levers from the Idle to Fly position. Procedures say DONT, return the switch back to on until the engines are at flight speed (approx 100%). Once the engines are happily settled at flight speed flip the brake off and the rotors begin to turn. Watch the rotor RPM gauge on the MFD until it's in the yellow close to 100% then you're good to go. Conversely, I'm not too clear what damage might occur when then rotors are at 100% and the rotor brake switch is is turned on. A lot of heat and grinding metal noise? A nasty letter from the Boeing company? Currently I just have it decay the RPM to zero under a constant until I get a better answer. I added more realism options to the config.xml for control over individual items like startup, targetting, flight model. OOOH, I just remembered why I was really happy today. AD fixed the road physics problem by using displacement mapping in 3DS MAX. So no hacky hacks may be required for road driving afterall. Well done sir. I knew I was feeling buoyant for a reason. If you want to know what the hacky hack means, the road surface was aligned to the terrain with a vertex shader which moves each point on the model level with the ground (relatively) but physics engines don't know what vertex shaders do to geometry, as far as they are concerned the model is unchanged. So there's a disconnect between what the physics engine updates and what the 3D card renders on screen. Using displacement mapping with our heightmap as source, the road meshes are baked at the right elevations to fit, the physics model and visual model are now united and traffic may now use the roads without any problems. So, way to go AD. Another cracking solution. Source

It's a "feature"

A geometry shader could be used for wires, overhead cables that need to sag and have some form of elasticity. I think the 5th edition superbible had a rubber mattress example that looked neat.

Inline ads eh? Source

Brilliant, I just lost 15 mins to space invaders

@omid: The movement inside the helo? made me laugh I supposed technically that's mocap. @pancakes: I'm really pleased that the impression of the older game comes through, very pleased. The music was just my usual hodge-podge pick of 90s Amiga demo scene and that last bit was something I composed in Reason. Anything free to use. I don't think it really goes with the theme of the game but makes for a fun little journey in a demo of what is basically a boring 14 min "sim-a-thon". I licensed some music for the game and used that in an earlier preview movie "welcome to afghanistan" which is a little bombastic and overly epic which I felt would appeal to the US audience more and in keeping with the older sim style. @Aggor: Next step is the Mk2 flight model which uses a lot of really snazzy math used in the development of real helicopters. I have a simple OpenGL test shell of a program with the flight model, I'm going to use the UpdateEntity callback to update the velocities from the flight dynamics engine. Our physics engine still has a few little bugs in it as a result of my conversion from C#. The roads are not perfect as I'm using the shader that moves verts to terrain height but the physics are not aware so there's a cheesy fix to add. AI mobs and the mission system is the next milestone, it's based loosely on an earlier game I worked with. Players get assigned (or select) a mission ID and when they sit in an aircraft, the aircraft entity will pass the mission ID to the avionics class which will build all the waypoints and other bits needed for the displays. It's like taking a data cartridge with you and plugging it into the aircraft.

Finally a video showing the free flight mode we really wanted to show at Summer Sim 2010. Thanks AD for doing an amazing job of making it all look good. http://www.youtube.com/watch?v=Y6ILqIQDaio Sorry about the lack of blade-cam, LUA object reference problem. Will get it sorted.

Never felt the need to keep fish until now. It's a crashed helicopter for use in your pond or aquarium. Thanks Phil (and Rob for sending it on). This wonder compares to the bizarre "Titantic with inflatable iceberge" bath toy I once found in an English Heritage gift shop. Source

Revolver, I like that The flights have callsigns named after guns (Winchester etc) so it might be confusing to have the FOBs named after them too. But that's an inspired idea

AD has been working on a new FOB which will be the "other" main camp you'll be deployed at during the course of the campaign. It's a triangle arrangement used by some forward operational bases. Here the CH47s are ready to be deployed. And finally.. Don't have a name for the camp yet. Source