Flexman

Tools certainly do matter. And using C# for your editor seems like a good move. I had no idea about the DesignSurfaceExt, that's pretty neat. MaxIDE, or any IDE tool I've used is fine for very simple interfaces but as soon as you need to create anything really useful it becomes more convoluted than a Hideo Kojima storyline. Talk about messy. I've always avoided CEGUI just because of the editor and the difficulty of creating new themes. It's always been easier and faster to roll my own interface than try and make something with that one. I should think using the kind of designer you're working on would be familiar to everyone using it. So good luck to you it sounds like a great idea.

Spent the day working on the Helicopter entity and the sub-classes that handle all the pylons and stores. It's worth spending time automating these things as much as possible now to simply things later. I broke out UMLet, a nice fast Java based UML editor to look at my structure. What's missing is the store-jett which needs to be a function of [TStore], pass it the pylon number and it will be required to generate the physics object, parent the rail/pod/fuel cell, detach it from the pylon and let Newton take over, thus letting the pod/rail complete with ordnance fall to earth. And by moving the [selectedZone] property to the [Pylon] from the [Avionics] class, it allows for the ground-crew loading system to simply add rockets and let the [Pylon] advance the zone so all 3 zones are populated in three clicks. That way it's not dependent on a playing crewing the Helicopter (as [Avionics] are only instantiated when you board a vehicle and destroyed on exit). This is all part of the process of adding the WEP MFD page which needs access to stores data and it gets it from the [stores] class, which can be thought of as a black box into which each pylon (4 of them) send signals about what is loaded where. And how to re-load of course. I'm torn about creating the whole WEP page graphic as a vector, I'd rather do that as textures scaled up can look a bit blurry. Cockpit builders might want a stand alone OpenGL client that doesn't require the 3D engine for displays so going native OpenGL makes adding it a cut and paste job. Source

Lot of time deep in emails answering queries and looking at Mac platform development. Source

Question for Josh really. Is it possible to post the code that generates the composite view in the "Edit Terrain" form window in the Editor? Or just a quick outline of the different layers used in it and how they are blended together. It would make a nice background for a simple moving map display.

Not played with it yet but cheers.

I needed to add some on-the-fly lookups for data stored in XML databases without having them gobbling up memory. Most games of this type had a vehicle and weapon database, usually with a rotating 3D model or picture of the object. Using the TxmlTextReader function with a cache works fine. Only need to do the lookup once when examining an object. All weapons come with suitable entries by entering the ground crew mode from proximity to any Apache helicopter. We can re-use this for tutorial pop-ups, optionally adding a tag to the XML entry that points to an audio file thus triggering playback. If that makes any sense. I mention it here as it just occurred to me and don't want to forget it. Source

A friend of mine pointed me towards a discussions among gamers about how games can be spoiled by overuse of filters. Never a fan of photorealism in games myself I sympathise, abstraction always had more appeal (pictures on the radio are better). Someone posted a link to this comic strip which I thought I had to share here. http://www.vgcats.com/comics/?strip_id=224

It's been a blissfully quiet weekend. The Combat-Helo configuration files are now in an easier to use XML format and I added a lot of extra options too. Player profile name, host IP, graphics filters etc. Fullscreen and Windowed modes having their own settings. Also experimented with light scattering, we'll be adding per time-of-day lighting and retiring the old LB2 style skybox. That's not a priority item just something that's nice to toy as a little break. Arming system which should have been completed already (lots of interruptions this week) has had some GUI elements added to it to improve feedback, just have to write the descriptions for all the ammo. The Apache is receiving the arming messages fine but not visibly showing the loaded rounds. On the whole, not too happy with all the GUI as it is. I made something that was easy to fit to multiple resolutions but it could use a little polish. I ran another test with the Autopatcher and it's still a bust. The file it's wanting is created server-side but the client patcher can't reach it. So another email exchange with tech-support tomorrow. Source

Thanks for sharing. It's nice and simple and demonstrates camera picking, using pivots and a 3rd person camera, all in a few lines. I never thought to use a pivot as a waypoint entity either. Cheers.

Ross Kemp? "OI! SHART-IT", boy I had to sit through a lot of **** for research purposes. I don't take this subject lightly, I've had a few friends out there, one has just gone out for another tour. Guns are coming in their own time. I only just added the arming procedure, on reflection I should have added that to the video as it's a good demonstration of using game states, hand rolled cheap and cheerful menu system and entity messaging. But it involves a player (would also work multiplayer) running around the outside the vehicle selecting weapons that lay on the ground. I was keen on a console like left/right/up/down menu thingy with panning camera moving from pylon to pylon. As one of our advisors was a farmer Apache weaponeer he likes the idea of other players arming choppers on foot. So I added that as an extension of the on-foot mode. There's a picture of him here loading flechette rockets (web site currently a placeholder for testing the autopatcher software and gamehost server)...Combat-Helo UK Site

It does seem like a face full of billboards, it's using the settings saved to the map. My intention is to have them extend out with altitude, closer to the deck extend the LOD but reduce the view distance based on a user detail setting. Not going to play with that until we get an idea of performance with the new veg system. The video shows the viewpoint from the gunners seat up front who mostly is looking at instruments and the HUD indicators. Longbow 2 fudged it a little and moved it down in the 2D version of the pit. Bad Company 2 has the head position mashed up against the canopy glass. Sitting back or raising the seat position helps. With TrackIR, mouseview and the ability to turn off the pit and use pop-up repeaters it's not a big deal. Plus I would face the wrath of hardcore flight sim nutters if it went AWOL. It creates a sense of cockpit space. The rotors really do get on your nerves after a while, the rotor disc needs to pitch forwards another 4 degrees but cone upwards a bit more. I want to add a fake rotor, the early Apache I used had an alpha-blended "Iron Cross" shape which I might resurrect and offer as an end user option. (Make it the default and have the current 3D blades as a realism option, using FRAPS makes it worse, not so bad when the FPS is 30+). That should be easy to do apart from the coning effect. It's currently an animated mesh and the amount of cone is simply picking an animation frame. LUA handles that. Good to know I can rely on good constructive feedback, it is appreciated.

http://www.youtube.com/watch?v=hNvqRM0lT04 Some of the billboards look a bit broken, lot of polishing to do later. But the core game is coming together. Some of the cockpit shows the polygon jiggle with having it positioned at the viewpoint location. I plan to have the pit in it's own world located at the origin later and draw it to the main buffer. If that makes sense. It's the only way I can think of to get rid of those artefacts. Weapons should be ready in a few more weeks.

http://www.youtube.com/watch?v=hNvqRM0lT04 Source

hehe well the XPatcher2 software worked great for the upload, but the client program doesn't seem to want to work at all, requesting a file that wasn't supplied or exists. Might have to look at other some other software. Converting all config files to use XML format, this will make editing control inputs a bit easier later. They are rather messy atm and adding new options should be a lot easier. Source

Currently testing the autopatcher software. Broadband upstream speeds being what they are, don't make this a fast process. The project core files are currently around the 300mb mark spread over 1300+ files. This will come down when we package them. The benefits of having an autopatcher is the ability to push updates for CombatHelo on a regular basis without too much hassle and players having to negotiate versions when playing with friends. Just run the updater and everyone should be in sync. Source

You wouldn't be able to use a TTerrain object for that. Translate, Move or SetPosition doesn't work on it (so even if you could have multiple TTerrains, there's no way to position them for a treadmill system). And then the Vegetation system wouldn't work as that's tied to using a TTerrain object. As soon as you get more than a few thousand units from world origin anyway, polygons begin to wobble. You need to periodically reset the world origin to fix that. Please correct me if I'm wrong, I'd love to be able to do what you'd like to do. Sometimes you have to scale back our wants and work with what you can do. Sometimes less is more and it works out better. Regards,

After close checking of memory usage when boarding and exiting the Apache there's feedback saying that objects are getting freed and memory dumped, except it isn't. Only a small percentage. There are object references that are keeping the cockpit and avionic entities alive and preventing them from being released. Going to take a little time to track each one down. *edit* The large memory leak located, was the TADS camera world not being released. It's been removed for now. Source

I only just came upon this topic as I was working on the problem of trying to position the terrain entity, so apologies if this is not news or is a little late. For our helicopter combat sim (emphasis on combat rather than being a fully fledged flight simulator), 10m per tile with 4096 heightmap resolution. 40km2 seems about the right size for a combat zone, other games of this type used the same size (Janes Longbow 2 for example). But for a jet sim or any kind of large open world it's (probably) not going to be good enough. If you're embarking on creating a flight simulator or any kind of large world there's the inherent problem of dealing with floating point errors with 32 bit math. OpenGL and LE uses 32 bit math. It's the same with many other 3D engines. As soon as you move more than a few thousand meters away from the origin you'll begin to see polygons wiggling around when the camera or object moves due to imprecision. This is what we see in our helicopter project, it's pretty ugly and I'm still trying different ideas to make the problem go away. Flight simulators (such as Microsoft Flight Simulator X) get around this by periodically resetting the local origin. Their approach is documented in part 7 of this document... Microsoft ACES Game Studio Terrain System In Leadwerks Engine you can't translate or move the terrain entity, it locked to world origin. So you can't employ this trick of moving the world around the viewpoint and resetting the world origin to keep things from getting wobbly. myTerrain.Translate(Vec3(0, 0, 512), 1); This doesn't work at all. If you create you own terrain system there's the problem of moving the scene around you. Periodically looping through all the entities to move them relative to the camera is not efficient at first glance, here's a clunky example, imagine having 1000 entities...(and is pointless as it doesn't work with vegetation or the terrain) 'where xoff,yoff,zoff is inverse to viewpoint movement' For Local ent:TEntity = EachIn CurrentWorld().Entities If ent <> camera Then ent.Translate(Vec3(xoff, yoff, zoff), 1); End If Next It's possible to do break that down so you have a duplicate world and periodically translate them but it all starts to get hideously complex which isn't what LE is about. So it's not good for really large worlds like what you'd need for a flight sim. But you'll have this problem with Unity and Ogre3D except Ogre3D has a paging terrain module and lets you do things like this to make it work but requires *a lot* of work to get results. Maybe there's some other way to stop the camera from exhibiting these wiggly float-point math issues. I wonder how Just Cause 2 does it.

I've just moved on to doing research into co-ordinates and floating point accuracy. Going to make a few test projects to try different ideas. Dave has been posting updates on the greenzone development. Welcome to Afghanistan Source

Hmmm, That would allow Delaunay Triangulation to create irregular mesh terrains too. That would be neat.

Excellent work. I'd like to know more about the dirt roads and how you made them.

Aha, that's what I thought. But it's not the behaviour I was observing so I examined my code this morning. Turns out, that if you use CopyEntity() on a Model that's Hidden, only the visual appearance is copied. I was pre-loading the model then using HideEntity() right away. If I unhide the model then CopyEntity() it works as expected. Cheers

Using LoadModel("...") loads the PHY, GMF entities and runs the LUA script for an object. But I want to pre-cache some objects for instancing quickly using CopyEntity(). In my case a number of anti-tank missiles and rockets. I was looking for a CopyModel() equivalent of CopyEntity(). This isn't such a big deal as I can create the TModel and use CopyEntity() to instance the visual model easily enough. Unless I'm mistaken?

Not convinced this a a great way of arming the Apache. But what we will do I think is provide some quick defaults, option A and option B. Only the client sees the weapons appear on the ground ready for selection. The crewman loading the weapons clicks the weapon which is then sent to the highlighted pylon. Internally the helicopter entity receives a message to load pylon x with missile y. To do: Tooltips for the pods to say what they are and I think highlighting the selected pylon might be a good idea. I can optimise memory usage a little by pre-loading the Apache stores and instancing then missiles which I meant to do earlier. Pre-caching some of these objects will reduce that awful machine lag that occurs when it needs to show a model for the first time. TrippleHead2Go vision Source

Looking at the pieces we have and project roadmap. Our game, like football (soccer for American readers), is a game of two halves. Side A and Side B. One campaign is the thinking man's approach; counter insurgency. The other game is the more familiar tank spanker; survival in a high-tech hostile environment against well armed self-sufficient mechanised infantry with air-defence units. Compounds are anchor points of the campaigns, in groups they form the villages, strategic points you're tasked to provide security for. In the side-B campaign, the role is slightly different but as important. I'm still a little bothered by LOD and shadow ranges, you can go mad tweaking these to find something that works well for different modes. Maybe I'm stupid but it only occurred to me last night to make the LOD settings dynamic. Which is ironic, as the very very first multiplayer wargame I worked on back in the late 80s used an LOD system based on view height. In the real world, at ground level the horizon is around 11km away, it's a mathematical function based on your height and the curvature of the earth. 1.17 times the square root of your height of eye = Distance to the horizon in nautical miles So I'll be experimenting at some stage with adjusting the Leadwerks Engine LODs for shadows and vegetation based on player mode and viewer height. Just using a depth of field filter on the far horizon seems to greatly improve visual quality, making hills blend a better into the haze, masking the smaller details. First things first, we have to complete our Apache and it's operational systems. Arming is almost complete. With breaks for Easter, familiy time and re-writing internal systems for handling weapons THREE times (it got better each time). It's taken a week longer than I said originally. The menu system is in place and the visual manifestation of the ordnance is left to do. Rocket pods will require one click per zone (3 zones or 3 kinds of rockets per pod). Presently it permits arming in proximity to the Apache which is fine on the base. But we'll have to implement some object, like an ammo truck (hmm, seen that somewhere before), or some invisible object we can attach to any entity via some LUA code (much like player spawn locations). DOF blending the horizon. Source