[Long rant] Making the game non-coder contributors friendly

You think of something which could be added to TA3D post here! /
Vous pensez à quelque chose que l'on pourrait ajouter à TA3D, postez ici!
Post Reply
D.Durand
Posts: 87
Joined: Sun Feb 07, 2010 11:21 am

[Long rant] Making the game non-coder contributors friendly

Post by D.Durand » Fri Feb 12, 2010 12:27 am

Hello,

Maybe some of you remember me. I proposed some units models months ago. But, like in a lot of others games a tried to contribute, i stopped it.
Because i can't AND because i won't include them in the game. Well, it's not totally exact but.. well, read before.

What pushed me to write this is another post in the "Battle for Wesnoth" game. The post was a long article that said, basically, most "free" games projects are very artist unfriendly (who said "Spring" ?).

It's something i hear often when talking with others peoples who want, something after being asked, to contribute to this or this free game project : Coders, as known by all Technical Writers around the world, have the communication skills of a pee-wee... and don't care for it.


My english is not very good, then i can't write a long explanation. Then let's go directly technical, will you ?

First, read this. My post is based on it, and the guy explain pretty well the "why" :
http://forums.wesnoth.org/viewtopic.php ... 6&start=15
There is a first version of his text at the start of the thread, and a new in this page.


1°) I don't care for the name of your last subroutine ! I want to know what this tag do, what values it can take !
One of the bigger problem i run into, in all theses "projects", is the total void of commands / tags / variables list. You always have to search (if somebody want to kill the guy who invented the wikis, i'm willing to pay for the ammos), and you rarely find it.

Say, for example : Where is the complete list of tags you can use for create/change a fbi file ?
What are the ones that are optionals, and what are the ones that make the game crash if you forgot them ?
Do you need to write them in some order ?
What are the values they can take ?
Do some have default values ?
Can some be included multiple times ?
Do some of theses take automatically their default value if you don't include the tag at all ?
Do some have effect on others ? What are theses effects ?
Do some values have to be unique for the entire game ?
Do some words/values are reserved ?

My suggestion : Give the damn list ! I can write it clearly if you want, but give ! Or die alone in the dark !


Death for the HPI ! Death for the COB !
Another think that stop me in my run : Why do i have to "zip" the data ? Okay, it's cool to create your own "zip format", but what is the use ?

I need to search for the software that can run that damn "hpi/cob" (and that's two different softwares, grr).
I need to lean how to use that software, and it's really rarely well thinked.
I need to lose my time by using it.

Not only it's take time for nothing, but that's really not fun.
What the use ? What stop TA3D to use a simple folder tree by unit, with files in clear ? You still have your old hard disk from 11 years ago ? Why can't i change the Hit Point from my unit without having to "unzip" and "rezip" ?

My suggestion : Use files in their normal state. No more HPI, no more COB !

3DM is an OBJ for geek.
Another thing that bother me it's that "3DM" format and, of course, its reserved editor.

What you can do in your special editor your can't put in an OBJ file and it's MLT companion ?
What 3DMeditor can do you can't do with Maya, 3Dmax, Wings or Delgine (this last one it's totally free since a few weeks) ?

I don't know how to use 3dmeditor, and i don't want to learn. I want to make units and seeing them as fast as possible in the game. Using my personnal 3D editor is fun. Needing to put my model in a second totally different 3D editor after that slow me and is NOT fun.

The only problem with OBJ is some editors save it with linefeed for end lines, when others use carriage return, but that's nothing simply reading the file can't overcome.

In an OBJ, i have :

- The three coordinate of each vertex.
- Each normal (line between two points), if you need it.
- Each poly.
- The name of the material used for each poly, if existing.
- The name of each group and sub-group of polys.

In the MTL, i have the list of the materials, and for each :
- The color, the transparency, the texture name, etc...

For textures, the editor just put them in the same folder than the OBJ and MTL files.

The same MTL can be used by more than one OBJ, do i have to explain the advantages of this ?

You can even use your standard 3D editor for put the "team" color : Since TA3D don't use polys without texture (if i understand well), i just have to give some color value to the poly used for team color. Say, red : 0 mean no team color, 1 to max mean a team color more and more pronounced.

No Scriptor anymor !

In fact, i don't even need some "scriptor" thing for making animations :
The joins between the poly groups are where the animations are, no ?

Then, in my standard 3D editor, i add boxes. Perfectly boxed boxes.
Two by "join".

Example :

I have a kbot.
I give the "central" poly group the name of "Mother". If ta3d see that, it understand it's the "Mother" group.
This kbot had a torso, and the torso act like a turret (standard kbot, as you see). I give it the name "Torso" and, of course, sub-group it to Mother.

At the point on the Mother where the Torso attach, i draw a box. The centre of the box is the exact point on the Mother where i want the Torso to be attached.
I give it the name "join_mother_torso".
I draw another box. I give it the name "join_torso_mother". Its center is the exact point on the Torso where i want the Mother to be attached (theorically, the two boxes have the same center).
I subgroup the first box in Mother, and the second in Torso.
Technically, Ta3D know now how to attach the Torso to the Mother.

Now, for each box, i rename one of their face "up", and another "face" : The engine know now how is oriented each join box, and what are their rotating axis (up-down, face-back, right-left).

For making some animation, i give a box some "rotating around your center in this axis", and him, the group from wich he is sub-group, and all the other sub-groups of it (even boxes), rotate.

Of course, the "boxes" are not rendered by the engine : Just used for their center (center the engine can calculate at the loading of the game. Save 7*3 datas for each boxe).

There can be other boxes type :

flare_gun1 => Position of the flare from the weapon "gun1".
shoot_gun1 => Position where the "bullet" from the weapon "gun1" appear.
point_x => where "x" is the characters you want. Boxe who is not a join, but can be used for other things (smoke start, loading position, etc.).
...


Using tags for animations !

Using "luas" and other languages for making animations is maybe fun for coders, but you have here one of the biggest reasons why you have so few new units : Most "artists" are not good with computer languages, and absolutely don't care for learning that.
If you look at how new units are done for other 3D games, like Spring, you will see nearly no finished unit is made by lone modellers. Mean if you want artists taking fun at making units, and that mean effectively making units, you need to offer them (us) something simplier than a language, letting the coders using the "evolved" language if they like, maybe for more advanced animations.

And that mean tags.

Modellers can understand tags. They use them all the time. In fact, tags is why HTML kicked XHTML and XML in the balls : It's simple to understand, and you don't need to be a coder to use them.

Hey, i have a defense turret !

[Targeting]=gun1
// If the turret want to target something with it's weapon "Gun1".
Rotate_up_Speed(join_torso_mother) = *some speed unit*
// Rotate the "join_torso_mother" box (and all polys grouped with it) around it's center at "some speed" for reducing the distance between the center of his "face" poly and the target, using the axis "Up-Down"
Rotate_up_Max = 30
// don't rotate more than 30 degrees from normal position by using the axis Up-Down.
Return_up=yes
If the target is lost (out of range, destroyed...), rotate the "face" in it's normal position by using the axis Up-Down.
[Targeting_end]

See ? Even pure artists can find that fun, because if you have the tag list and the value each can use, you don't need to learn language grammmar.


Here some a little list of possible tags.

[Z]=x Bloc of tags for differents situations.
[Z_end] End of the tags used for the last bloc.

[Targeting]=x Following tags are used if the unit want to target with it's weapon "x". Value is the weapon number in the unit file.
[Firing]=x Following tags are used if the unit want to fire it's weapon "x". Value is the weapon number in the unit file.
[Moving]=x The unit move (by itself). The value can represent differents moves if the unit had more than one (jumping kbots like in C&C, walking ships like in SupCom). Some possibilities : Walk, Walk_undersea, Walk-onsea, floating, Hovering, Run, Jump, Taking_off, Landing, Docking, Loadin, Unloading, Climbing, etc ad vitam nauseam.
[On]=y(x) Following tags are used if the unit had is in "on" state. Paused if a bloc "y" with "x" value is activated (example : AA turret rotating peacefully, then facing a targeted ennemy).
[Off]=y(x) Following tags are used if the unit had is in "off" state. Paused if a bloc "y" with "x" value is activated (example : AA turret rotating peacefully, then facing a targeted ennemy).
etc.

In the tags bellow, "y" is the name of the box.

Rotate_up_Speed(y)=x
Rotate_face_Speed(y)=x
Rotate_right_Speed(y)=x
Rotate the box around it's center at speed x, using the axis Up-Down | Face-Back | Left-Right, and with it all it's group and groups attached.

Rotate_up_Max(y) = x
Rotate_face_Max(y) = x
Rotate_right_Max(y) = x
Can't rotate farther than x degrees from it's normal state, using the mentioned axis.

Return_up(y)= x
Return_face(y)= x
Return_right(y)= x
If the target is lost (out of range, destroyed...), rotate the "face" in it's normal position by using the axis mentioned
X can be "yes" (return), "no" (remain in the last position), "forced" (return and ignore all rotate orders until move is finished).


Rotate_up(y) = +x
Rotate_face(y) = +x
Rotate_right(y) = +x
Rotate the box around it's center using the axis mentioned. x is the number of degrees. + is clockwise (default), - is counter-clockwise.
0 => immobile (default)
361 => don't stop to turn.
target => Turn in direction of the target and try to follow it (only work in a "targeting" bloc, probably).


Step
Wait until all the tag before in the same bloc have finished their actions.


Wait=x
Wait x time units before continue to the next tags in the same bloc.

Show(y)=x
yes => Show the group of polies called "y" if invisible.
sub => Same, but show also all the subgroups.


Hide(y)=x
yes => Hide the group of polies called "x" if visible.
sub => Same, but hide also all the subgroups.


Explode(z)=x
Ungroup the group called "z" and all its subgroup and send them flying in all directions. x=yes or no.

Show_weapon(y)=x
Make the weapon called "x" appear at the box called "y".

Fire_weapon(y)=x
no => After a "show_weapon", make the weapon model placed on box "y" immobile and grouped with the box where it appeared.
yes => Cancel "immobile_weapon" on all weapon grouped with box "y" and "fire" them.


sfx(y1,y2,y3)=x1,x2,x3...
Show a sfx animation randomly choosen in the "x" list, starting randomly on one one the boxes mentioned (for smoke, fire, etc...)

alternate =x1,x2,x3,x4...
x1 and co are polies, groups or boxes (named, of course)
Used for alternate the use of polies. Like the three guns of a Gaat tower.
The second time the same unit use the same bloc with the same value, the engine replace all occurences, in the bloc, of the first listed by the second. And so on. The next after the last one is the first.



The target is to make modelling fun. Actually, it's not because there is a lot of things that not only slow the process, but have nothing to do with "fun".


On the ressources

- Don't make ressource hardcoded. Use "ressource[x]" and not "Metal" for naming, please. A lot of modders want to create their own ressources, and often more than two.

DOT
Posts: 151
Joined: Sat Sep 19, 2009 11:56 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by DOT » Fri Feb 12, 2010 12:28 pm

[ ] You know that TA3D doesn't got many Developers?


and for Own resource you need Units that "extracts" the Resource and a New Gui etc..

also COB is very easy to learn i don't see the sense why you are "Bitching/Ranting" about it
and you can copy the Other COB script into your own unit and rewrite

Come on , on other Games it is more complicated for it

also 3DM gives more lots of more Advance like good looking textures , lightning etc..

and if you want to model quick you just use 3DO you need just select the face and the texture voila!

xpoy
Posts: 669
Joined: Mon Sep 22, 2008 3:55 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by xpoy » Fri Feb 12, 2010 2:24 pm

after read half, I agree tags. Yeah, that's great, really pure need tags.

And there are choose, you aren't must used TA3D's tools, isn't? /:^] You can treat them as a simple debuger and a formatter.
For tags, I think coder didn't know what's the best design for tags, so maybe some more idea in tags? It will make it out in less time.

D.Durand
Posts: 87
Joined: Sun Feb 07, 2010 11:21 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by D.Durand » Fri Feb 12, 2010 7:47 pm

Dot, the text i linked answer perfectly your first line.

For the ressources :
=> I don' say "the basic TA game have to have more ressources". I say "TA3D need to allow modders to have as many ressources they want.
After, it's their to make "units for extract" the nex ressource, of course.
For the new gui, again, it's up to the modder.

But for that, it need to be possible to add new ressources.

Without the possibility, impossible to do things like ammos. Hell, impossible to do even a warcraft 1 mod (three ressources in this game : Wood, gold, mens slots).

Good looking textures are not dependant of the file format used.
Lighting... What lighting ? Lights you mean ? You can easilly add boxes called "lights". And OBJ can describe the "ambiant" light going from a texture.

And no, not "voila". That add a step, a long step, when i have the model finished. And it's not fun. Maybe YOU think coding is fun, goind from an editor to another editor is fun, but not me.
What I find fun is creating my unit in my standard editor and looking at it runing in the game 30 seconds later.

If i can't, then believe me a great, great majority of artists and other modellers say the same thing : I just don't do it, because you morph a fun game in *work*.

User avatar
Balthazar
Moderator
Posts: 2055
Joined: Wed Nov 01, 2006 4:31 pm
Location: Russian Federation
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by Balthazar » Fri Feb 12, 2010 10:04 pm

D.Durand - i have to day, but you are right.

It`s very hard to create models or make mods for TA3D, since it has no it`s own editors (except only 3DMEditor). So you have to create models in one editor, texture them in another, make animation in another and so on.

Well, I`m dumb as hell, and if i can do a 3D model in Lightwave 3D and texture it with UV mapping - that`s all that I can do, and there is absolutely no way I can create a working unit :(

But the modding is not an easy process, there are a huge amount of different things you need to know before creating a unit.

Dunno what to say....

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Fri Feb 12, 2010 10:05 pm

I mostly agree with you except for scripting ... TA3D animates units using scripts because it must follow some design patterns from OTA in order to ensure compatibility with it, also scripts are responsible for much more than just animation. Also using Lua scripts is a good way to have an interface to develop more things easily : you could add a tag based animation system using a Lua script and without having to change anything in the engine code, Lua is extremely powerful for that kind of things, that's why we have chosen it. Regarding FBI files, tags and other stuffs, these are documented here : http://downloads.ta3d.org/misc/tadesign%20guide/.

HPI files are used by TA3D but are not required (OTA doesn't require files to be packed either). You can extract all the game files in a folder TA3D will use them as if they were packed (except it won't use caching so you can edit the files and get an immediate result in game). Packing files is only a cleaner way to distribute things but even our mod repository system doesn't need mod files to be HPI files (you only need an archive to avoid requesting 1000 files on a server). COB files can be replaced with Lua files which are compiled to byte code on-the-fly.

3DM has been designed to add more surface effects to models and 3DMEditor to edit those surface properties (it features some basic model editing functions mainly because I needed it for testing). Beware that 3DMEditor is still in early development stage (sadly we're lacking man power for everything :( ). The main reason why there is no support for OBJ and 3DS formats is because mesh code has been rewritten and our loaders were broken so it was easier at the moment to remove broken code but now that we have a clean code to handle models support for more 3D format can be added.

Regarding animation and 3DMEditor, I was planning to add an animation module (not the code editor which is already present, it's meant to be a real animation tool) which would automatically produce script code from basic commands (using all the power of Qt GUI, key frames, control pattern generators - very powerful tool used in robotics in real world :) which produces realistic smooth animations with incredibly realistic transitions, ...) unfortunately I didn't have time to work on it as we have other priorities now : having a working (on Linux, OS X, windows, with as many video cards as possible) 0.6 branch.

Engine core stuffs should be mostly cleaned now so when 0.6 branch is stable (soon I hope now that I have finished my exams :) ) I'll start focusing more on tools (which are useless with a broken engine ...). Anyway it's not bad to have a reminder of things to do from time to time :)

PS: Balthazar : modding should not be difficult and I like standards, they're good for interoperability (which is a problem here :( because of lack of various formats support). I don't use 3DMEditor for modeling units myself, I use wings3d which is much better for this and when we'll start replacing OTA's resources with our own we'd better have good tools to do the work.
=>;-D Penguin Powered

DOT
Posts: 151
Joined: Sat Sep 19, 2009 11:56 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by DOT » Fri Feb 12, 2010 10:08 pm

i thought by Resource you mean things that you need to collect first to be able to build some units like Metal and Energy
also if you want to make new resource the player needs to know how much he has from it somehow


yes Lights i mean my bad English isnt my Native language and sometimes i am thinking on Croatia Words..


Well Upspring (not sure on 3dobuilder[+] ) and Wings3D is the fastest way you can to make a models be ready
and on Cob you just "Steal" from other scripts rewritte abit to make it compitable

thats the fastest way that you can make a unit and also Quality takes time

and i cannot imagine on any Game that you get a Fully textured mid-low good looking units + script to be ready in 30 Seconds o_o
thats like a bit like over the humanity capableity

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Sun Feb 21, 2010 12:17 am

You may be interested in knowing current SVN revision is able to load textured 3DS meshes and probably OBJ meshes as well (I only tested 3DS loader yet).

Now the 3D formats loaders are completely separated from the common mesh code which makes it easier to add support for more formats : just create a new class for the new format, write the loader and you're done, you don't even have to edit anything elsewhere :), if a file can be read by a plug-in TA3D will load it :). I've added a small 3DS model to test that :
Image
=>;-D Penguin Powered

DOT
Posts: 151
Joined: Sat Sep 19, 2009 11:56 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by DOT » Fri Mar 05, 2010 7:40 pm

Um but you cant use 3DS models for regular units? like Turret or is there some special script added for 3DS? like cob but one for 3DS?

because it needs several scripts like Turning , piece etc..

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Fri Mar 05, 2010 10:14 pm

Animation scripts are independent from models format, just give your objects the names you use in your scripts and it'll work :) ... with currently two problems regarding units:
  • units don't wear their team color (support for team material is not implemented yet)
  • 3DS/OBJ models are not packed into a tree structure like 3DO, 3DM and S3O models and current loaders don't look for any kind of relation between objects ... so no animation tree yet (I like the proposed box idea with the "join_" prefix, I'll implement it soon)
=>;-D Penguin Powered

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Sat Mar 06, 2010 3:58 pm

I've added support for all missing features in 3DS and OBJ loaders: selection primitive (its generated from the bounding box), team color (just use a material named "team", its color will be modulated by the player color), and links between objects.

You can create a link between A and B by adding an object named A_B where you want the link to be and B will be a submesh of A (that way you don't have to specify a root/mother object and you can have several).

For instance if you have a mesh with the following objects:
  • torso
  • head
  • ruparm
  • luparm
  • rthigh
  • lthigh
  • rleg
  • lleg
  • torso_rthigh
  • torso_lthigh
  • rthigh_rleg
  • lthigh_lleg
  • torso_ruparm
  • torso_luparm
you'll have this structure:

Code: Select all

head
torso -> ruparm
         luparm
         rthigh -> rleg
         lthigh -> lleg
This is the structure I used for a test model I animated using the ARMCOM script :). It works nicely :mrgreen:
=>;-D Penguin Powered

xpoy
Posts: 669
Joined: Mon Sep 22, 2008 3:55 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by xpoy » Mon Mar 08, 2010 9:52 am

greeting!
And, maybe we can make a choose in Animation, just make 2D/ 3D be choose able? :P

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Mon Mar 08, 2010 12:19 pm

Sorry I don't understand what you mean by "2D" animation in this context :?
=>;-D Penguin Powered

xpoy
Posts: 669
Joined: Mon Sep 22, 2008 3:55 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by xpoy » Tue Mar 09, 2010 8:54 am

old TA's animation

That current set.
Like bomb, wave, etc, it's OTA' 2d animation, but sure modder will like 3d animation .

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Tue Mar 09, 2010 10:05 am

Of course animated sprites/effects are still supported : they are GAF files and GAF-like directories, but allowing to chose between 2D/3D animation implies we have both 2D and 3D animation data ... currently we have none in our free data set :cry:
=>;-D Penguin Powered

D.Durand
Posts: 87
Joined: Sun Feb 07, 2010 11:21 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by D.Durand » Tue Mar 09, 2010 8:14 pm

zuzuf wrote:I've added support for all missing features in 3DS and OBJ loaders: selection primitive (its generated from the bounding box), team color (just use a material named "team", its color will be modulated by the player color), and links between objects.

You can create a link between A and B by adding an object named A_B where you want the link to be and B will be a submesh of A (that way you don't have to specify a root/mother object and you can have several).

For instance if you have a mesh with the following objects:
  • torso
  • head
  • ruparm
  • luparm
  • rthigh
  • lthigh
  • rleg
  • lleg
  • torso_rthigh
  • torso_lthigh
  • rthigh_rleg
  • lthigh_lleg
  • torso_ruparm
  • torso_luparm
you'll have this structure:

Code: Select all

head
torso -> ruparm
         luparm
         rthigh -> rleg
         lthigh -> lleg
This is the structure I used for a test model I animated using the ARMCOM script :). It works nicely :mrgreen:

I'm pretty happy to see my long rant started a constructive thread. And adding support of "standards" formats in the game is really a great start for attract artists. Thank you.

But i don't understand what you mean by adding an object named A_B as "link". How do that work (don't hurt me) ?

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Wed Mar 10, 2010 1:19 pm

This link thing is almost exactly what you suggested except the name of the linking object is A_B instead of join_A_B because of some restrictions on name sizes (I couldn't export several join_Alpha_Beta from Blender without having them shortened to something like join_Alpha_Be which is not recognized).

PS: don't hesitate to ask any question, I am writing some documentation so it'd be very helpful :)
=>;-D Penguin Powered

D.Durand
Posts: 87
Joined: Sun Feb 07, 2010 11:21 am

Re: [Long rant] Making the game non-coder contributors friendly

Post by D.Durand » Wed Mar 10, 2010 2:07 pm

Blender shorten the names of meshes ?! :shock:
Well, that's another reason for me to not use it, as if i really needed one (have you tried Delgine ? It's free, now).

Well, for answer your question, here :
You can create a link between A and B by adding an object named A_B where you want the link to be and B will be a submesh of A (that way you don't have to specify a root/mother object and you can have several).
What i understand :

A is a mother poly (I mean mesh. Sorry for the old habits), B is a child.
By creating a mesh named A_B, your also create a link between A_B.

What i need to know :

- Do the mesh need to have a certain form or size ?
- What is the part of the A_B mesh is the position of the link ? The center ?
- Do you need a B_A or do you need only A_B ?
- I see in the ARMCOM script something like that : "turn torso to y-axis". Do Y is vertical, the same than the Y from his mother mesh, or another thing ?

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors friendly

Post by zuzuf » Wed Mar 10, 2010 3:25 pm

D.Durand wrote:Blender shorten the names of meshes ?! :shock:
Well, that's another reason for me to not use it, as if i really needed one (have you tried Delgine ? It's free, now).
It did that for me only with 3DS export, don't know why but it may be because of me since I only used Blender a couple of times.
D.Durand wrote: - Do the mesh need to have a certain form or size ?
No, it doesn't matter
D.Durand wrote: - What is the part of the A_B mesh is the position of the link ? The center ?
It's "center" (the mean coordinates of the vertices)
D.Durand wrote: - Do you need a B_A or do you need only A_B ?
Only A_B, having both would not make sense.
D.Durand wrote: - I see in the ARMCOM script something like that : "turn torso to y-axis". Do Y is vertical, the same than the Y from his mother mesh, or another thing ?
Ha yes this needs a little explanation:
  • Without transformation, Y is vertical (positive is up), X is left-right (with TA3D's default camera), Z is naturally deduced from X and Y :P
  • All transformations applied to an object are made in its local space coordinates so if B is child of A and you rotate A to 90° around X, the Y of B will correspond to the Z of A
It may be a bit difficult to think things that way but just think that objects are transformed relatively to their parent and that a mesh is in the unit local coordinates (you don't control the unit's absolute position/orientation, but you can control an object of the mesh which is a parent of all other objects in the mesh
=>;-D Penguin Powered

Sarwajagat
Posts: 5
Joined: Fri Feb 25, 2011 3:29 pm

Re: [Long rant] Making the game non-coder contributors frien

Post by Sarwajagat » Fri Feb 25, 2011 3:41 pm

More tags are indeed needed,will post some in a few!

Can TA3D have a mission/map editor like Starcraft? :P

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors frien

Post by zuzuf » Fri Feb 25, 2011 4:29 pm

Making a map/mission editor with OTA map format for TA3D is a huge piece of work (because OTA's TNT format isn't designed to be OpenGL friendly). However it would be easier with a map format designed for TA3D and less time consuming too but it requires much more work on TA3D itself :P. This is not a priority for me now (I am busy trying to fix things to get a stable 0.6 branch) but if someone else wants to do it that can be done without looking too much at TA3D's code and would be a good experience to help design a new map format.
=>;-D Penguin Powered

DOT
Posts: 151
Joined: Sat Sep 19, 2009 11:56 am

Re: [Long rant] Making the game non-coder contributors frien

Post by DOT » Sun Mar 06, 2011 7:30 am

alternative isn't it possible to add a folder with .inis (or any other txt format) that is like armcom.ini and reads out the model pieces and defines which pieces is it which connected?
i think it would solve the name limit size

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: [Long rant] Making the game non-coder contributors frien

Post by zuzuf » Sun Mar 06, 2011 4:36 pm

Where would you store the position of the links between model pieces ? In an extra object that would be removed at runtime ?
=>;-D Penguin Powered

Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests