Flexman

XML supports encryption and security certificates. If you're using a library that supports that, might be worth looking at. It's what I'm currently doing in my day job.

What about vehicle code? And what level of control is there over waypoint navigation? Are there ease-in/out parameters or some other method to handle abrupt changes in velocity?

Limited edition action figure like Captain Coolermaster? (this is real I kid you not) http://www.overclock.net/t/1208113/captain-coolermaster-1-of-100-made-for-coolermaster-20th-anniversary

On the subject of new toys, would a Nexus 7 be fit for purpose?

The last 20% of a project is always the longest and hardest. No matter how well prepared you are. Having the discipline to get over that wall is truly hard to find.

I'm forever buying software I don't use. I remember buying AGK, which was a right buggy POS that held promise of cross-mobile deployment, sadly let down (as usual) by poor attention to testing and real-world use before release. When you can't even get string management right you have to wonder. LE2 still manages to piss me off in all manner of irritating ways, mostly the tools lack of basic usability beyond doing really basic stuff. Having being spoiled by other editors in which I can rapidly tweak something to experiment, trying to do the same thing with LE2 is painful, often met with some exception error. I have high hopes that the tools in LE3 have addressed these issues. If not, well it will go the way of all the other SDKs that didn't quite make the grade. There's only so many times you want to get stung no matter how much you want to support the effort. Sadly most of these kits fall down when you try something beyond the trivial. One scene demos are easy enough. The litmus test is going to have tools that let you mash-up materials (without falling over), have more than one tool running at the same time, multi-scene loading with no creeping memory issues, dynamic resolution handling and all the basic code functions working as documented. And if that sounds overly ambitious, it's not. It's very basic working functionality that many failed to get right from day 1.

I do this using GROME just fine but I only use exported terrains as separate 3D meshes, not as a native terrain object. I'm not sure if the base map of the terrain entity takes a normal map, but could probably be fudged to do so. Like all the other shaders thay are packed into SHADERS.PAK, unzip and tweak. It's something I should look into. edit: Looks like the normalmap is taken in on texture channel 14 (in terrain.frag) but no idea how you load that in the editor.

I'm going to make a Hello World program. Possibly followed by "Classic TV Pong (HD)", something simple to get a handle on compiling for different platforms.

Terms such as those used to described patterns are just handy for communicating. That's all they are, descriptions, not implementations. It's a surprisingly common misconception among developers (where I work anyway).

Command pattern, for undo functionality. Needs a project to be designed that way from the outset. But if anyone's creating anything with multi-level undo, look up command patterns for inspiration.

Yes it's going to be a commercial combat sim. The helicopter flight model works in the same way, process the dynamics using a library called HTR (the same one available for Flight Simulator X) and updating the forces in the physics hook. The undercart has always been a problem. I've tried different things and nothing satisfactory yet. HTR doesn't model it as in FSX there's a flag that says "I'm on the ground now" and control is handed over to the native engine to deal with the ground dynamics. I wanted to do strut compression but the A frame shape of the undercart on the Apache is difficult to work out (for me anyway). We got something working but what happened was the wheels would sometimes get left behind. Joint stiffness doesn't work at all. Anyway, one of those problems to iron out later. Looking forward to reading/seeing more.

That's really good. NGD is Newton yes? Are you calculating all the forces and applying them in the physics callback? And you've implemented a credible look-up flight model. Does it have proper wheels for the undercart too or not implemented yet? (I'm having real problems with that as the Apache is a tail dragger with a jointed tail wheel, has never worked right).

Oh that's a good question. It's one of those things that you take for granted until you don't have them. (edit, answer just beat my reply). All I can say is, awesome. It's why some folks shell out loads'o'money for a pro version of a certain engine. It's not considered optional. LW3 is sounding like a must have for mobile if it can deliver on the visuals.

I concur with Josh. There are many ways to skin a cat and I achieved this in the following way. If you're wanting to jump from vehicle to vehicle, you'll want to code around that by adding 'hooks' to your different vehicle models that you parent your player to (hooking them on like coats of a coat rack). When you exit the vehicle you can un-parent and position your player at an entry/exit hook (and if your vehicle is on it's side, upside down or against a wall you'll need to compensate for that by checking for the first valid exit hook position). A hook can be some dummy entity, or pivot parented to a vehicle, a good idea is to use an entity assigned a common name e.g. "player_hook_1". That way when you run the action to 'mount' a vehicle you run a function to look for the nearest player hook entity and parent the player to it. In practice I hide the player TController in these circumstances because it's not needed (and I had collision issues between the TController and the different vehicle entities).

Well initially I thought it could be used for vegetation, powering through scrub, tree canopy etc. but you don't need soft body physics for that. Soft body physics makes me think of jelly cubes (that's jello for Americans).

I don't think there's a global physics update callback. the Entity callback is your best bet. This is called during UpdateWorld(). Assign it to every entity then branch off for specific types in a single function. But you probably did this already. ' INITIALISING ENTITYS IN A LOOP, SET THE PHYSICS CALLBACK ' ... SetEntityCallback(newEntity, UpdatePhysicsCallback, ENTITYCALLBACK_UPDATEPHYSICS) ; ... ... ' CALLED 60 FPS REGARDLESS OF FRAMERATE ' Function UpdatePhysicsCallback(entity:TEntity) if (entity <> Null) if (game.LocalPlayer.entity = entity) UpdateLocalPlayerPhysics(entity) ; Else UpdateRemoteEntityPhysics(entity); End If End If End Function If you have to do this for lots of entities, but have many of a specific type, it would make sense to use caching to your advantage by having specific callback functions for them.

Depends what kind of testing is being done. My day job is development/testing of medical software, we pretty much try to ensure every release goes out with zero defects. I can write you a test plan and some test specs for Leadwerks3D that you can expand on, then you'll have some consistent release testing. Gawwwd knows Leadwerks 2.x could have done with that. Wouldn't have time to test anything myself but Mac is a capable guy as are others but Mac

Not to derail the thread in any way, I am curious; Is that people who have been using AOL for 13 years? Or people born 13 years ago who are still using AOL? Or people who used AOL 13 years ago? Back on topic, the screens are so small on most devices I don't notice real shadows unless in close-up. That's more a comment about my 40 y/o eyes as well as screen dimensions. Certainly in publicity shots,(and Josh himself has made the same comments to me) you should throw in the kitchen sink.

I know you can't use things like "Load Scene" in a script. I tried making pre-fabs by having an entity script load a map with the entity as the parent. This is slightly different though. It would have been nice to have this feature, and also potentially annoying as some objects load children you really don't want to touch. In another game editor I won't name, this behavior is handled. If you break a pre-fab you're wasked (warned and asked) if you want to create a separate pre-fab? I don't know how to do what it is you want. But thought I'd chime in anyway.

This is neat. Full marks for out of the AABBox thinking.

It's more about the technique than the quality of art though. More tools for those that can make best use of 'em.

We also have the opposite problem. Models which have many similar child objects but not instanced. Cockpit interiors have 30+ toggle switches, 30+ rotary controls and cockpits can be duplicated.

Just not added or clear in the scene. But models do cast shadows. In addition you have the advantage of using baked light-maps and shadow maps if you need them. Baked normal maps can also be used for extra detail.

I'm sat here in my lunch hour reading this nodding, "yes, yes, yes. Totally ugly yes, spot on." I like your workaround so much I'm going to use it in my next bit of code and owe you a virtual pizza. I'll send you a real one when I get the chance. Too bad there isn't an easy way to instance the materials. One of the problems we have for squads of armor is how to deal with vehicle damage and animating tank tracks. Tank tracks we managed to do by having a material for the tracks that scrolls the UV offset of the track based on the object colour (Maclebee did the leg-work on that). Colour can be different for instanced entities. But since players can fly (up to 4) hero ships in different skins, duplicating materials is expensive. Since a hero ship has multiple 4096x4096 textures having duplicates should be avoided. One of the solutions I'm consider is a damage texture that is blended in splats according to RGB model colour. (Haven't the faintest idea how to do it yet.) This is consistent with how we already apply damage to other objects where intensity relates to damage%. (Destroyed vehicles are left with a dark smokey/burned appearance).

Just as a matter of idle interest is that exported as a regular triangle mesh or irregular mesh? That's pretty much how you do it for mobile apps. For a while there was no native terrain object for a popular iPhone engine. Exporting as an irregular triangle mesh worked really well, the downside was the very limited shader support. This is the same process but additionally makes use of the coverage maps (masks used for splats). I have a UDK material for using exported terrain meshes in a similar way, so you get the worst of both worlds There's a lot to be said for using the same tool to export terrain as a mesh, a split-mesh or height-map for multiple engines. I've tested the DAE export in Leadwerks before. Only issue one has is making sure patches fit into 64k buffers. It's more than a workable means to create terrain, it's reliably used in games for other engines already. Leadwerks is easier than UDK as it's not so constrained with regard to format (these terrain layer materials can be awkward to set-up). When it comes to 'uber mega streaming' (which I utterly like the sound of), creating massive terrains in the order of 250,000 sqr km just as easily as 5km sqr. with the tools we're now using. Exporting them as a single data files for continuous streaming or slicing them up into nice chunks (for paged streaming or non-streaming) is just a different mouse-click away. I would have included a chapter on Leadwerks in my upcoming book on this subject however there simply was not enough space