Data export was possible previously using Custom Properties, but this was kind of annoying and also limited in use. Now there is a command set and I hope to expand to be able to add lua scripts as needed on an object, which will generate a .script file for the game object when exported.
This will make adding properties for scripts from game objects quite easy. Im also adding a feature to the object export that collapses children meshes into one gameobject with mutlitple mesh buffers. This is a good perf optimisation. However it will be per object (parent), so that if you need objects coming across as gameobjects, that is still available by default.
Will update the defender dev blog once this is all complete (prob couple of days).
More fun tonight. While updating the exporter last night (its prob been 4 months since last main update) I noticed that embedded_components has changed as part of the mult-materials (which was prob last year but I didnt notice).
To support some of the builtin material changes on export I needed to update this, which meant updating other things… and well… usual programming dependency chain
Ive now got essentially a new version of defender. Will update on defender blog and if people need V1 still I will add an option in the panel for it (Ive added versions in the code).
Now I can add in the data changes properly. Hopefully mostly done by tonight. Then start exporting missions again
Is it just me… or is software development always via the long route.
Oh more woes. Since Defolds go and mesh structure have changed, I needed to rewrite a tun of Defender, which will essentially make a new version when its finally working (three days and still much breakage).
The other big problem is that some of the gltf and glb exports no longer import into Defold either. Some of the lightmap and such specifically dont work (I think its related to the multi-texturing). This is all obviously slowing things to a halt again. Uggh.
To get around this Im looking at building everything manually in meshbuffers, but this is slow. Will see. Its not overly important for f18, but many of the test sample scenes I previously tested with are all failing which I want to use to get defender back and properly compatible with Defold.
While its subtle this change is also elsewhere as well. And when generating was causing various problem, but more importantly I wasnt sure what it was supposed to be
I ended up making some dummy files and setting them on Defold side to see what they should be.
The import crashes (gltf and glb) are more complex and Im not certain what is really the cause there. I used to import quite large scenes (the blender demo for instance) and now these have multiple exceptions popping up and all sorts. I need to first get defender updated to match the expected formats, and then I can start measuring a bit better.
Side note, and I’ll pop over to the exporter dev blog and note this, the current release will not work well at all for many exports. For more simple single texture exports it will probably be ok. But features like the lightmaps will not work.
Major change in direction. Will update here later. I dont expect future work to be done on this anytime soon now sadly. Sorry for the delays if you were keen on this.
Ok. Little teaser. Im preparing my current build of f18 for release onto Steam. There is alot to do, but I want to get this all completed and release over the coming months. With November being the latest (fingers crossed).
The release will be going to Early Access and will contain 1 theater with multiple missions as well as a campaign. If there is enough interest, I will probably add a couple more theaters with missions to suit.
And if there is interest in modding, Ive been working on a world builder for it that should be able to allow people to make their own mods to the game.
Lots to come, will post some updates here when I can (have a dozen other things happening atm) and hopefully some screenshots and vids as they come along.
I should be able to swing that (all things going well of course). I’m looking forward to get a more completed release (rather than just a demo/early access) with complete single campaign. So I could see a demo with a training mission and maybe a couple of others.
The map is much bigger now too. So you can just fly across the US or to Hawaii… or up to Canada .. there will be lots of little interesting unlocks too (ie find a building or geographic feature). Im very hopeful there will be enough interest to further develop more campaigns/theaters.
I’m a little bit of a Steam expert, if I may say so myself…
If you have questions or want advice please feel free to DM me - or just post here!
It depends a bit on what you mean by “hopeful there will be enough interest”! It’s a tad hard to pull off a “just build it and they will come” on Steam.
Hi Alex, yes, I will definitely dm you about the Steam side of things.
The “hopeful there will be enough interest”.. is more about futures. The Early Access will measure that, and when one the full main campaign is done with all its missions etc, and after a run of say 2-3 months in early access (to complete to release of the full campaign) I should have enough data about whether there is value in building further campaigns, multiplayer and so on.
As with mobile I have worked on and console, better to find out early whether its worth investing more time/effort .. The current build is not even intended to make money (it wont ). Its my own little passion project, but the aim is to determine if there is enough to expand it after initial release.
More updates.. so heres some screenies. All of it is in flux and its mostly placeholder.
New title screen and text. And there will be a new 3D menu.. but not really 3D..
Thanks to the new Defold build, for some reason my html builds have started working again. Woohoo!
That means I will be able to put up Eastern Pacific Theater and training mission once its stable enough.
@britzl or @Mathias_Westerdahl I have a little oddity, which I think I know whats causing it, but Id like to confirm with some of the Defold engine builders themselves.
I have a world which is reasonably large (real world) and I was working in 100m units (ie position 1,1,1 is 100m xaxis by 100m altitude by 100m zaxis).
This makes sure the numbers dont get too extreme And this solved many long range movements. However, I have a mission starting point out in the pacific ocean near hawaii, which is 34575 x and 16484 z away from my origin in SanFrancisco. The rendering results show above.
The problems seems to be specific to the use of quaternions (rotating camera or object has high impact) when applied to the rotation of the f18 model.
I think this is the camera / world / projection matrices all having problems because they are working in 32bit float (ie accumulated error with large numbers). If this is correct, then my backup plan is to have “floating origins” for the world, which is a complicated mess but should resolve it. Before I embark on a few weeks of hell code… could you confirm that this could be a possible issue?
I will make a little test project over the weekend to make the problem very specific and clear. If there are any tricks (like forcing doubles in matrices or something like that) .. Im very interested
Actually while writing this, I had a thought. I could probably build the matrix in lua (Im doing all my modelling and entity management there anyway) and do the appropriate mults (thus kinda run my own camera) and then just set the cameras view, projection and world transforms matrices directly. The output vert results should be quite localized and thus shouldnt wobble crazy like this.
I’ll make that test so I can try some of these ideas too. Maybe even passing in my own transform matrices to shaders.
Oh, another thought. Could the shader precision be a prob too? Uggh. Life was so much easier when you could just write pixels yourself.
Yeah. I’ll give that a try and see what happens - they are mediump atm. I suspect that wont translate to html5 tho (I vaguely remember there being limits on web shaders).
