Q&A!

Is it really necessary to need a UV map for the entire model? There are certain portions of my model that I would be happy if they were just the base object with a colour and specular level.

It is always necessary to generate UV coordinates (not complicated; select faces, auto-unwrap, done), but you can have untextured materials. However, instead of using multiple materials just to have some "untextured" parts it is more effective to use areas of flat colour in one texture.

In real time rendering it is a good practice to pack as much variety as you can in one texture instead of multiple smaller ones.

It's maybe for Blender and Max only?

I guarantee latest Blender is supported, Max has been confirmed by Fish to work, don't know about other programs and their best practices yet. If it can export Collada it should work.

The loader can handle a few different file formats now.

going by this http://assimp.source...es_formats.html as long as you export it to a .DAE it should be fine

In theory, everything from that list.

In practice, not all formats and exporters are equal, .obj for example does not store a node structure so it cannot do everything. Please do experiment, but I recommend: stick to Collada (.dae) for everything.

seriously. why don't support a mesh format like .x fully and i don't have to mess with materials and textures a second time?

There's more to the in game materials than just name + texture. Different programs, model formats and exporters have different capabilities, so to see how the model is actually rendered by the game engine you would have to tweak, export and reload multiple times. So, it's easier to just require it always defined in a unified way, and tweaking the material does not require re-exporting the model. It's more resistant to modeler/exporter version changes as well.

im wondering is there a way to 'ping-pong' or 'loop' animations yet or is this something still to come?

Yeah, at first the modelviewer had play/pause/rewind buttons and you could specify a "loop" flag for the animation, but I took it out for this first release to concentrate on getting this show on the road. We'll have to decide which animations the game will support but a looping 'idle' animation may be one of them (radar dish on a space station or similar).

something else, collada exists in different versions, which is supported?

1.4.1 at least, this is what blender and max export, we'll have to collect experiences with others

onFire animation that's called when shooting.

planned, feel free to already animate a gun model so I have a test case

onHyperDrive animation thats called when the player starts a hyper jump.

should be doable

colored lights like navlight_green navlight_red and so on.(perhaps they could be navlight_1 and then the color for navlight_1 could be defined in the .model file using something like light1 = RGB or hex or something )

yeah, planned. We'll just need a nice universal way to determine the light animation. At minimum named groups that animate according to some standard (navlight_red, navlight_green...). In max and blender one can attach comments or other metadata to objects, and a custom exporter can take advantage for this, but with Pioneer we have to support a wider variety of software and object names are likely to be the only grouping method.

Actually my first plan was to allow defining attachment points, thrusters etc. also in the .model file as simple lists, but right now I'm waiting to see if requiring .dae or similar is enough for everyone.

colored thrusters similar to the navlights.

Thruster colour would be likely determined by the ship config

• on entering / leaving atmosphere, to allow atmospheric wings to fold in / out
• on landeding / taking off, to allow doors to open / close

Fish, if you place an empty object and call it navlight_xxx it places a navlight, although it is always red as far as I can figure out, I presume this function is not fully implemented yet. I assume the system will automatically assign a colour depending on the side of the model the navlight is placed on?

Folding wings, or a B5 style spinning midsection is already possible as far as the model system is concerned, but we'll have to figure out the collisions and make the game aware of these animations. For now you can wing animations to the landing gear action if you want to experiment. I'll consider an animation triggered by surface landing (and playing reverse on takeoff) so you can have some door activity 🙂

Fish, could the same not be achieved using the 'tex_glow' emission texture map?

btw, maybe not related but I have not planned material animations

1.4.1 at least, this is what blender and max export, we'll have to collect experiences with others

Worth noting that Max/Maya vary what they export depending on the version, MAX has notoriously bad DAE support by default.

You might want to get an alternative DAE exporter plugin, or just do the modelling using MAX then export to DAE using Blender.

feel free to already animate a gun model so I have a test case

ok here is a realy simple weapon animated over 12 frames (half a second) its only the firing part of the animation but if needed i can fix that to include it resetting to its start position

the scale may be a bit of again let me know and i can change it

the texture is not great (hell even the unwrap is poor) but the basic idea is there

im not sure about the timings for animated weapons (will the anim be sped up for faster guns or will i need a faster anim?)

as time goes buy i will replace it with a better model

test weapon

Quick question on scale...

I have been working to the scale of, 1 blender unit = 1 meter (I had seen that in documentation somewhere but cant find it now).

I have 2 models that I am experimenting with and both of their bounding boxes are around 40x40x8 meters, but when I drop them into the game they appear quite small (not much bigger than the standard eagle).

Am I doing something wrong or are the other models not following that convention and I need to scale my models up?

i found the best way to get the scale is to import something like the "wave hypersonic bomber"  in to your modeling software then scale your model around that. i had same problem from the other direction my models were to big

The scale of the old models is all over the place, so please do not use them as a guideline, especially the oversized buildings and the eagle  🙂 Do all new models in 1 unit = 1 meter scale, and try to keep the sizes realistic, whatever that might mean (a space shuttle is around 40 meters long if I rembember).

37.24m apparently 🙂

Thats grand then, I intended my models to be around shuttle size so I will just let everything else scale in round them over time   

can i just check that this scale looks right

size in max is 40x20x10 (max units)

using automatic unit scale on export (that happens to be inches) showing a scale factor of 1

if i set it to meters on export the scale factor is  0.0254 and thats way to small in game (isnt it?)

From memory that looks to be about the length that my models sit on the landing pad although your buildings look smaller?

I use a LUA script to load my model (so you see the model change) from the default start and my model is not much bigger than the eagle.

Very roughly 1 inch = 25mm so that scale is probably correct converting from inches to meters

Putting a "person sized" (~1.8 units tall) box next to your model should also help with getting the scale right.

if i set it to meters on export the scale factor is  0.0254 and thats way to small in game (isnt it?)

In max, I recommend you use the "generic units" setting and treat 1 unit as 1 meter. If you want to use the actual "metric" unit you also have to set the scaling from the Customize->Units setup->System unit setup... dialog.

If the exporter has a scaling factor you should probably leave it at 1.0.

thanks i was more concerned that 40 units in max was like 30 or 60 meters in pioneer but if u say 1 unit in max is one meter in game thats cool i will put a note on the wiki

i will add that bit about adding a person sized object too

hmm, well probably not known well, there should be a "dummy pilot" .obj along with my pilot sub-model, you can easy take this female to mesure size.

ok she sits and didn't stands up but is exactly m1.80 (the female is slightly smaller), i made the pilot first standing upright, then i "bended" her to let her sit down.

it's also very, no... exremely handy to create a cockpit i the right size.

but well well, scale, another difficulty of collada, yet another leak of it for games and a must for portability.

but more about this weird behave later on.

first i will counter to "you probably have to learn this first" or similar 😉

i guess most will know "coolhands" viper, it's a fine model i feel and certainly i look at steve as a luminary, he's a sort of idol for me, well one should have idols to look up to, no doubt.

ok, i said that before i already expected the viper will fail in pioneer and what did you think has resulted?

it fails in pioneer.

it works, "everybody" knows this, fine in FFED3D.

it works proper in the MS MeshViewer.

but it fails in pioneer!

here's the evidence

it's obvious, anyone can see this get's handled wrong,

the pistons didn't rake out far enough and the "ski's" flicker, get positioned wrong for a fraction of a second.

first, would you dare to tell "coolhand" the same as to me?

no matter, it leaks and their IS something wrong with pioneer and NOT with his model.

i know already what could be the reason, but it's not a fault of the modeler from my pov.

somehow, i don't know the exact reason, pioneer reads untransformed meshes even from a .x mesh, that SHOULDN'T be, a objects frame is there to keep a object in proper size and alignment to the whole model, exactly what collada leaks of, no "top level" matrix, neither a matrix for objects or children of them (more about impossibility of proper parenting in collada later on).

but let's stay with this directX model.

i took this as a real evidence to show that there is something wrong, well you can still ignore it and call me a idiot, the fact will stay.

---

to collada, the mean thing is like i said above, no object frames, no proper parenting, no good way to animate a model, especially when you need a little more as just a simple translation or rotation.

also some disadvantage of blender2.65 play a role to this (well i said before "ancient" for 2.49 isn't the right word and new is unequal to better)

the problem with collada is really the disrespect of child objects under certain conditions.

it's simple, there is no object frame with a matrix4x4 which controls the child as well as the parent.

so animations would have to be made in a "handmade" stupid way, i.e. i didn't use parenting and position all by hand, then i have no problems.

but i like to use parenting and constrains, they are made to help making good animations in a easy way.

ok i can use "visual keying", but it seems this leaks in blender, at least if i use it in blender2.65 the animation gets "destroyed" (obects get displaced) by setting of the first "visual key". somehow it starts to take account of the constrains from the "visual key" on new with the "old" value and i.e. a "limit distance" constrain will end up completely wrong as well as a "clamp to" constrain. both are not only handy to make animations like a "steamwheel", means a rotation transposed to translation or vice versa, e.g. like a "conrod", they are needed to make this proper.

but ok as long as you are satisfied with either only rotation or translation i see no problems with collada...

(but it's not enough for me, and if it starts to act weird on things little me was able to script them, then...

i mean take my LMR conversion of "coolhands" viper, the animation works as the original, well yes I AM proud of that piece of work and i'm allowed to be proud of it i guess.

yes no.2, it's impossible as soon as it comes to not linear rotations, that's the reason why my new cobra1 in LMR leaks of the pistons, due to the angle of them the rotation i would have to script (a constrain) which would need to be not linear and even rotate back from a certain point on. BUT collada leaks exactly in the same, and it seems it's impossible to export such in collada, again because of missing object frames matrix.

further pioneer leaks also to recognize such proper either with .x or .dae, take "coolhands" viper as example)

now, ok, the worst thing is that i can't use a "vertex parenting" for collada, it only takes respect of a "common" object parenting.

if you use a "vertex parenting" collada mixes all up and the parent becomes child of the former object which was ment as child, yes that didn't only sounds confusing, it IS confusing.

this is imo all bound to portability of this format, like i said before it's very good to port projects from one software/machine/os to the other and to publish a project in the web, exactly that's what it is ment for from my pov.

not for a game where i expect a proper result under ALL conditions.

if a animation works proper in a standart 3d viewer (no matter which) i expect it has to act the same in the game, if such isn't given it can't be useful for a game, or there is something wrong with the implementation to the game.

well both has been denied and it's certainly easier to call me a "idiot" instead to hunt for this error.

conclusion, certain things ARE wrong with the SGM in pioneer, no doubt for me you can denie this as often as you like.

further blender2.65 has heavy leaks in the directX export script.

i mean the old script was maybe "homebrew" (he, he, like the LMR), but works proper and NEVER exports a animation wrong.

"stupid" made somehow, because the old script simply plays back the animation and uses a kind of "visual keying" for each key you have set, if there is a value stored in blender or not, it will take the "real" translate, scale or rotate values, keeping logically due to that account of all constrains and parenting.

the new .x export script leaks not only in this, sometimes it even mixes translate with scale and this is certainly wrong.

so much to the comment "blender2.49 is ancient" well probably, but also more trustworthy, more stable one could say.

back to collada, things i can easy do for a dirtectX mesh are impossible with collada, partwisely i have to learn new things, partwisely due to the system it won't be possible at all.

something you really have to be aware for collada:

apply all translation, scaling and rotational values to the object before you start to animate it, this helps at least to get rid of displaced objects.

(well such isn't needed for a directx mesh due to the object frames matrix and the top level frame matrix, i won't matter how a object is scaled, translated or rotated, only the object frames matrix, the top level frames matrix and the animation matrix are taken into account. or should be, i guess pioneer does something wrong there, else "coolhands viper" wouldn't show this error. well directX meshes are made for games, collada is made to be portable, two different pairs of shoes.

and we should think about what we do here,

do we make a game?

or do we like to publish the models in the web?

i guess you know the answer.

one thing i'm pretty sure of, i can't use collada in a "cool" way to make a NOT SO complicated animation as for the "conny" or the "cobra mk1", because collada has problems to take account of translation and rotation if used together, it has problems with parenting and what else more i will have to find out first...

all is bound ONLY to the missing object frames, which (is the only way to) control children and constrains in a proper way.

this brings me now to the next "leak" of collada.

due to the fact that it's portable and ment to publish and exchange projects, all and i do mean all, transitioning, scaling, or rotating values get stored in a collada model if they aren't applied to the object, that will result sometimes in a "wrong" scale of the model as example, but more "worse shit" is bound to this.

the meanest thing is, again to missing object frames matrix, you can't change this afterwards and already in the editor software you have to keep in mind to apply the values before you start to animate, else everything comes out wrong (in pioneer, it might get proper recognized else in any 3d viewer).

but by looking already at this few leaks, it's certainly not useful for models in a game and "nubes" will stumble certainly over all this "special cases" i have to take in account for collada. well almost as complicated as to script in lua, i mean if i have to take this and that special case in account, it really get's complicated, sorry.

i don't know why, but it looks like our devs have fallen in love with .dae, not so me, i really think it's not the right choice for a game.

well, ok, now you can call me again,

"idiot",

"asshole",

"loudmouth",

i'm used to 😉 and can only laugh about it.

---

ahh, yes befor one gets the idea i should apply the modifiers,

a constrain is no modifier.

modifiers control "destructive" actions like "edge split" (which is reversible and i see no good reason not to apply them when you work on it, vice versa it helps to skin and select a certain range of polys) or shape modifiers like "apply curve" or "subdivision levels".

constrains are animation helpers and couldn't be "applied" the have to taken in account either by keying or by the export script.

but i guess i don't have to tell that.

---

sorry for the long text, but i thought you liked some "help" or experiences, well here they are.

again back to "coolhands" viper.

you can see well that the pistons move in the wrong direction, why?

easy answer, there is a "fault" (not really a fault) coolhand has made.

due to the fact that FFED3D uses double sided material, steve "inverted" some parts to let them get lit from the "wrong side".

that looks sometimes for inside parts better.

so done for the pistons of the cargo door, they are inverted if you look close.

now usually that should play no role, because the object frames matrix together with the parents matrix and both objects animation matrix's,

ONLY should control the animation, but it seems pioneer takes the "inverted" part and "assumes" the wrong movement, though the piston moves in the wrong direction, because "up" is inverted and points "down".

further there is a part which has vanished completely, it's to see (or better, not to see) on the bottom of the ship.

there should be a identical engine part to see as on top, but i assume because steve positioned it later, pioneer takes the original position and so it's hidden somewhere in the model, i assume centered.

strange at all to take the original trasformation of a directX mesh instead only to use the frames matrix.

what you think they made this for, to get disrespected?

and if you still believe that nothing is wrong there, then i don't know...

---

FINALLY A HINT

for all who like to make models using collada.

i found, no i stumbled over, a easy way to position the ships on their proper resting position.

YEAH!

you simply have to export the model to collada by position the animation at the frame which reflects the lowest pposition of the landing gear.

means if your animation is "lowers the gear", set it to the last key when exporting.

if your animation "lifts the gear", set it to the first key when exporting.

i really stumbled over this when i made the "Cobra MK III - sparksova", because it uses only simple rotations it was predestinated to use a collada model for the animation.

then i recognized, "strange, sometimes it's positioned proper, sometimes on half of the height, sometimes it's "grounded", what's the reason?"

then i recognized as my model was ppositioned in proper height, "hey you exported it when it's at the last key (lowest point), could that be the reason?"

i made a counter test and exported it from position of first key (gear up) and what you think the model was "grounded".

ok, bug or issue or not, but it seems to help to position a model proper.

if the same works for directX meshes as well i would have to make proof first.

again the clip of the "Cobra MK III - sparksova" 😉

---

before one thinks i'm a fan of MS, i'm not.

certainly not someone who used as e-mail "hates@gates.com" for hacked softs.

but you know already "good is a good and bad is a bad"

and "a hammer is for riveting, a scissor for cutting".

I stopped reading after the 5th line. far too long a post. I think that is the problem. you rant for too long without getting to the point.

Chances are I would not have understood the rest anyway 😉

I am not reading all of that.

"I am not reading all of that."

Do not close your mind, you may need it.  

@walterar/Vuzz

It's not that I don't want to know what Gernot thinks, I'm just not going to spend an hour read a vast sprawling, multi-part epic story/rant that is harder to read than x86 assembler 🙁

It's a diatribe against Collada, or SGModel rather than being a useful bug report. It does look like we get flicker on the ski's of Coolhands Viper, that might be a bug. However, it's buried in hundreds of lines of rambling text, I just spent 10 minutes reading it now to try and work it out. What I got along with figuring all of that out was annoyed, frustrated, tired, irritated and fed up.

I'm only human, relentless negativity doesn't put a big happy smile on my face and make me want to help.

Here is my super quick test using pure .x (directx) format to test thrusters.

You can use individual named bones for thusters.  They scale if you scale the bone.

You can also convert the .x to .dae and it works, but you need to flip the model in the z direction.

what a "evil" cat i am...

no, please, i do my best you will see...

but in advance no matter how many models i converted to SGM in the mean time, i still dislike it and.. ah you will see what is 1000 times more fun to me,

costs one sunday and well, you will see...

@Gernot,

Cool, glad you're still around 🙂

I still think that LMR can make an interesting and powerful modelling tool, and we still have the soure code around. Maybe it'd be useful to the Blender community as a plugin?

Then you could still have your modelling using LMR and export it to whatever you like for SGModel?

Andy

wouldn't make much sense i guess,

yes it's different and of course it could be interszing to keep it alive, let's say "unbound" from pioneer.

prob. just as a sort of trainer,

or ok, at least you could create a bezier surface and use the generated lods for a model.

(i have read, some have problems to do them, well yaeh, it looks like a lot of shitty work to create several lod's.

but, two or three are already ok, i guess even this needs to be documented, because it's not as hard or much work as it seems from far.)

but on the other hand, what use if i can perform something with which i never will see in the game.

there are limits to both systems, naturally.

i knew always that the LMR is a problem, tomm knews it as well i'm sure, because i remember very well when he asked me

if i feel comfortable with it and that he was happy that at least one dared to mess with it.

it's just i worked so long with it and really started to like it, the limitations as well as the freedom.

if the situation would be vice versa and i would be new to the game, i wouldn't understand one like me, neither i would mind a shit about, believe me.

i know it's hard only to assemble a model with a script, but well as example "placing decals 10cm over the suface to avoid z-fighting",

uh, sends me back 5years, i did that to until tomm explained me the use of the "zbias". well know it's something i wouldn't like to miss

and it's far more sophisticated as placing something 10cm above a surface which looks shitty from closeup even when this are only 5mm (you can see 1mm).

believe i know it i did it and was dissatisfied, long ago. (i thought you spoke once about a projection, yeah that would be great, but placing it 1 - 10 cm above the surface...).

but that's only one of the many dislikes i have, one of the many things i see nothing as a script can deserve me with, doesn't have to be the LMR, but something scritpted that gives me the right tools. i can't influence something like a zbias without to determine it in a script i guess, except the file format would support such.

but more on, i have problems to see how all that should be proper solved except to preassume a lot and this will tie my hands.

"hardcoded" use of submodels or prob. only fixed ones in the style someone else dictates?

argh...

like i said if i wouldn't have worked so long with this freedom i wouldn't mind, you usually know only what freedom is when you lose it.

if the situation would be: "this are the possibilities, this is the stuff you can use..." well it would be quite different.

but unfortunately i make my odd models for pioneer since a long time and any change to this freedom i had, is like a offense to me, sorry,

but i hope you understand this at least partially.

see, yours talking about to remove the LMR "tomorrow", while i see a completely unfinished system which leaks on every corner.

not to tell about what i think why my models was handled neglected and have been "mistreated" so long,

as well as the steady arguing that they are to complicated.

if you ask me, excactly what a assumed, to make them look shitty, to let me look shitty.

imo that was all what stands behind.

to find a way that ONE can decide which type of gun i can attach...

(which actually looks like a torch, sorry personal flavour, yours might think mine look like WWI, but excatly this i always liked,

YOU DECIDED not someone else).

and if i didn't like it i can go to hell...

to loose this is really hard. i never preassumed a style, i wouldn't like, i neither have a uniform style myself.

to me all this goes in the wrong direction, for pioneer, for something else i won't speak.

but i really can't imagine how you like to deserve me right (while ok, it's only stupid me), with "hardcoded" use of sub-models.

with style guidelines that not everybody must feel comfortable with...

one gathers what the other spills, that's all i can say.

sorry lot of text again, but i would have to tell so many things i could fill a book

and since quite a while i understand why web based work doesn't works well, i can't explain my mind so well as when i'm talking.

there is no, "erm, wait i have this idea..." or "i see this from this point".

you write something, but you don't know how the reception is, you can't see in the others eye to get a reaction.

something i usually like much, i never wrote so much in my life as since i'm sitting in front of my machine and creating this stuff.

i never liked to write (and he fills endless lines...) neither i like to talk on the phone, i like to see in the eye of my companion / client.

---

and metamartian, i didn't remembe that i called specifically your models "flying boxes", besides some of mine are little more as this.

it's just what i wrote above, i dislike if someone preassumes a style for me.

certainly i have a very own one.

but certainly i never would dictate style, exactly because of the above reason.

yes i have a "blown up" character, yes if it was about me i would like to dictate the world.

but only if you are able to see this on yourself you can fight it.

promise,

next post will contain the my new SGM projects, well even if it's just to show off my dislikes 😉

them are so many i can't remember all of them at once.

nah, probably to get even some help with the conrod problem i have with collada and blender2.65.

maybe someone is able to show me what i'm doing wrong, i can't see actually.

but like i said prob. bound to the "wrong orientation" we build our models...

at least i encountered some weird behave with "visual keying" (that's usually the way to get constrained objects keyed properly).

while, like i said last month, old blender2.49 .x exporter does it well, and i really wonder why others wasn't clever enough to write a matrix animation out

like he did by simply playing it back and get the proper "visual keying" if you set it proper or not, as long as there is a key of any sort and as long as the animation plays back well in blender, it will work exactly as it has worked in blender.

ok, for collada it's quite different, it seems it didn't stores a matrix animation, it's rather something like the project itself uses.

collada stores every shit, UNTRANSFORMED scale, rotation and translation, then you have the values how they are transformed (instead of the matrix).

that's problematic from my pov.

if i have as a simple example a wrong scale, i have to redisign the whole collada shit, the whole animation must be scaled as well else it won't work.

something you do for matrix framed mesh with the change of 1,0,0,0 0,1,0,0, 0,0,1,0 to 1.5,0,0,0 0,1.5,0,0, 0,0,1.5,0 and all is scaled properly including the animation.

probably, but i have to make this proof first we really have to build "orderly" lefthanded and find a way to get it imported proper to our righthanded coordinate system,

by putting something similar like a frame around it.

at least this would allow a easy rescaling or reorientation of a model, i guess it's worth to think about that.

guess i know also why we have only one animation channel, collada didn't supports more am i right?

lame? (well i guess naturally it can't, since it's a "project" and not a "model" if you understamd what i like to say with that.

portability is most important for collada, you can open any project one started with "any" software.

but, and i said that before, it's prob. not what we need for a game.

only the fact that the same animation gets once played back well and under other conditions not, shows to me that it's not really useful.

like always you can't have both, "black covers white"

portability stands vs. safety

named export script for .x meshes is safe, but you can't open the model anymore, even max fails to import the animation proper, but it works SAFE, under ALL conditions

the same model i can use in any game/viewer which supports .x meshes, it's displayed, played back, always proper.

no matter OS, no matter engine.

not that i think .x meshes would replace it better, there is nothing that can replace the script to assemble the model, the file format doesn't matters for this.

decide yourself.

i really can't tell all what comes to my mind now, would be 10 times more text as above...

oh i really started to think i lost all my friends...

(because of my bad behave, that's very common to me, i know myself, but it's also hard to fight yourself)

thanks for the many "thumbs up" tourist.

and sorry fluffyfreak, it harms me much if you are dissatisfied, i took you as a friend from the start, that's why it hurts.

i hope it gets better, but i didn't think so, or not as long as.... ah, you know what.

i hope i can put a smile on your face once again.

at least that would be the goal.

what about some sexy pinups on the ships, would that help?

Like I say Gernot, I'm glad you're still around 🙂 don't worry about me I'm sticking this out 😀

Look, I know you'll miss LMR for many reasons, and that you've accepted SGModel is here to stay - which is a good thing. It really is a good thing. It's just hard to see when you've put so much effort into learning one thing, and then that goes away. It's familiarity, you know all of LMR's quirks and interesting features.

The things you've mentioned, like with z-bias, some we will have to find a way to replicate that feature but others there will just be better ways of doing them.

Take animations as an example: The LMR way was quite simple and you could control what happened and when. With SGModel it looks harder at first because you have to learn how to do the same thing in Blender/Max/maya/Silo/etc and you seem to have lost some of the control. That's only because it's being used for simple animations which probably were easier in LMR, but the new animation system is MUCH more powerful than LMR. Things that would have taken months to do in LMR are now possible in just a few minutes once you've learnt how to do it and the reason that things seem more limited is because not everything is in place yet but they are getting there.

You know as much as anyone that this is a labour of love for us all, and that it's done in our spare time so things do take a little while but already there are new people who feel more able to contribute and are getting good results.

... Also yeah, sexy pinups always helps 😀

Andy