Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]
- Thread starter mtarini
- Start date
Users who are viewing this thread
Long time no see!
I tried to have a read at this thread to find out the biggest issues which arose in the long time since my last visit... found a couple of good suggestions too, by Lumos and Mr.Master.
So I made this small update. From page 1:
The first point means that now you should be able to Copy (ctrl+C) from one BRF file, switch to another running OpenBRF window, and paste the content there (even you closed the first one) (before, it had to be the same window). This was suggested by Lumos. It has been a nice exercise.
Remember you can select multiple stuff at once (by pressing Ctrl or Shift when you click on them).
Just for information, the "copy a thing and then paste its name into a text editor" (a thing = a texture, a material, a mesh...) also finds uses within OpenBRF. For example, you can copy a material, select a mesh, click on the "material name" box, and paste the name of the material there. This is not new, it was all there before.
Second point: by dropping .dds files into OpenBRF you will import the corresponding "texture" objects. Suggested by Mr.Master. It also works dragging in multiple files at once. You can also automatically build the corresponding materials if you so wish.
Thanks also to fedeita, Swyter, and GetAssista for reporting the stuff that recently broke!
Hopefully those are fixed now.
EDIT: a hotfix version, released maybe an hour later (0.0.52b), also fixes the game crashing on "discard rigging" from a mesh. Thanks to Highlander for reporting.
Let me know if i overlooked anything!
-------------------------------------------------------
PS: to fedeita, about skeleton editing.
Now you should be able to modify a skeleton by exporting, editing and re-importing a "skeleton modification mesh", but be warned that M&B is a little unintuitive as for modified skeletons.
- Uniformly scaling the entire skeleton is totally fine (as long as you enlarge the rigged meshes as well)
- Translating bones around, which means changing their lengths: you can almost get away with that
(deforming the rigged meshes too, naturally).
- Rotate bones (i.e. change their orientation) and you will get results which are totally unlike what you would expect.
- Add/remove bones and it will just not work, unless maybe you also change every animation in the game to include the new bones, plus all rigged meshes and a couple of other files too.
The reason is the way Skeletons and Animations work in M&B. You can somewhat get most of the results you might want (barring addition/removal of bones, which is in doubt), but it is anything but intuitive to do so.
I should write a tutorial sometime.
I tried to have a read at this thread to find out the biggest issues which arose in the long time since my last visit... found a couple of good suggestions too, by Lumos and Mr.Master.
So I made this small update. From page 1:
The first point means that now you should be able to Copy (ctrl+C) from one BRF file, switch to another running OpenBRF window, and paste the content there (even you closed the first one) (before, it had to be the same window). This was suggested by Lumos. It has been a nice exercise.
Remember you can select multiple stuff at once (by pressing Ctrl or Shift when you click on them).
Just for information, the "copy a thing and then paste its name into a text editor" (a thing = a texture, a material, a mesh...) also finds uses within OpenBRF. For example, you can copy a material, select a mesh, click on the "material name" box, and paste the name of the material there. This is not new, it was all there before.
Second point: by dropping .dds files into OpenBRF you will import the corresponding "texture" objects. Suggested by Mr.Master. It also works dragging in multiple files at once. You can also automatically build the corresponding materials if you so wish.
Thanks also to fedeita, Swyter, and GetAssista for reporting the stuff that recently broke!
Hopefully those are fixed now.
EDIT: a hotfix version, released maybe an hour later (0.0.52b), also fixes the game crashing on "discard rigging" from a mesh. Thanks to Highlander for reporting.
Let me know if i overlooked anything!
-------------------------------------------------------
PS: to fedeita, about skeleton editing.
Now you should be able to modify a skeleton by exporting, editing and re-importing a "skeleton modification mesh", but be warned that M&B is a little unintuitive as for modified skeletons.
- Uniformly scaling the entire skeleton is totally fine (as long as you enlarge the rigged meshes as well)
- Translating bones around, which means changing their lengths: you can almost get away with that
(deforming the rigged meshes too, naturally).
- Rotate bones (i.e. change their orientation) and you will get results which are totally unlike what you would expect.
- Add/remove bones and it will just not work, unless maybe you also change every animation in the game to include the new bones, plus all rigged meshes and a couple of other files too.
The reason is the way Skeletons and Animations work in M&B. You can somewhat get most of the results you might want (barring addition/removal of bones, which is in doubt), but it is anything but intuitive to do so.
I should write a tutorial sometime.
Highlander
Marquis
I have another suggestion. I often have to combine several rigged meshes. I do that by exporting to smd and merging the files in notepad. A combine function (also for static objects) would be handy.
Also, the discard rigging crashes the editor for me.
Also, the discard rigging crashes the editor for me.
Discard rigging: oops you're right, I had left something there which I needed once a long time ago.
Hotfix: ver 0.52 b. Fixed that, redownload if you want. Thanks for reporting it!
As for combining the meshes, the option is already there. Just select all the meshes, then right click, "combine". Works with animated static or rigged meshes alike. Naturally, they have to use the same texture sheet otherwise you'll see problems.
Hotfix: ver 0.52 b. Fixed that, redownload if you want. Thanks for reporting it!
As for combining the meshes, the option is already there. Just select all the meshes, then right click, "combine". Works with animated static or rigged meshes alike. Naturally, they have to use the same texture sheet otherwise you'll see problems.
Highlander
Marquis
Oh, thanks a lot.mtarini said:
dunde said:
Sorry to ask, I'm not familiar with "MS Editor builders". What are they?
Anyway, you are saying it would be useful that OpenBRF produced a .txt file with the lists of all names of meshes, animations, materials, collision objects, etc? Maybe alphabetically shorted?
Or should it export the names of the objects found scanning the txt files from the module? Or what?
These things would not be difficult at all to do, only I don't know what would be useful.
There are some pythonic Module system Editor built here like item editor, troop editor etc. I made one of them. Module_items.py, module_troops.py, module_meshes.py, module_map_icons.py and some other module_*.py have mesh name as string input. It will be very helpful for if the editor provide combobox listed all valid mesh names for them, so I want a text file that list all mesh name that loaded by module.ini.
The list will be very long and hardly useable. You can copy name of mesh from brf now, and you can run "check module for errors" later and openbrf will tell you about missing meshes in txt filesdunde said:
dunde said:
Oh sure, sorry, you meant these. Nice stuff. TLD dev is one of these context where we would prefer the python based ones to the txt based ones for the obvious reasons. Yours looks promising!
A complete list of mesh names, right? Would it be fed to text-editors in order to activate some auto-completion / auto-correction then? Wouldn't you also need a list of animation names, collision object names, maybe material names too, for similar reasons? (each in its own txt file, with one line per object, maybe?)
mtarini said:
First of all. Thanks for the update, Marco. Really appreciated.
I only wanted to note a few of things:
[+] I've sent you the latest Spanish translation some months ago. It would be great if you could update it in next revisions.
[+] Can you make the language dependencies external? (/Langs folder for example)
[+] Also, I'd love to finally compile OpenBRF on Linux.
Just saw it. Nice.[+] Command line switches. For dumping the contained info into xml, csv, ini, json or plaintext (the format doesn't really matter). Without using user interaction. A lifesaver way.
[+] That's it. Thank you in advance
Mtarini, you are awesome. Thanks for coding in my lazyass feature.
mtarini said:
Wow, complete resources name list. Separated txt files will be better for it will keep the file-size small. As far as I know the resources from BRF files that module system access by name are meshes and animations.
Something like openBRF-meshlist.txt :
[brffile1]
mesh11
mesh12
mesh13
[brffile2]
mesh21
mesh22
mesh23
sorry it slipped me. Will do!Swyter said:
Swyter said:
So you and dunde are proposing the same thing (only you also suggest to make it possible to build it from command line also).
Just details about what to produce: a single file, maybe, like...
filename:
Code:
[i]<your_module_name>[/i].resoureces.txt
Code:
[meshes]
name1
name2
...
[materials]
name1
name2
...
[animations]
name1
name2
...Or several files, like
Code:
[i]<your_module_name>[/i].meshes.txt
Code:
[i]<your_module_name>[/i].animations.txtShould objects from common res be included? Should entires be alphabetically sorted?
Should submesh be omitted (e.g. have just "castle", instead of "castle.1" and "castle.2")?
Thank you. There were some stuff missing. I thought about externalizing the qm files so we don't depend from the official compilations.mtarini said:
mtarini said:
I usually depend from the upper guy decisions, this is new for me.
Parsing text structures isn't really a problem after my header_operations -> sql converter (most chaotic header file ever seen).
What I'd do is something like:
ShellExec:
Code:
%path%\OpenBRF.exe [color=navy]%1[/color] --dumpto [color=navy]%2[/color]Where
Code:
%1
Code:
%2
Code:
%1Alternatively:
ShellExec:
Code:
%path%\OpenBRF.exe --export [color=navy]"My Module Name"[/color]Possible structures.
As I've previously stated I don't specially care about this. But as dunde does let's see.
Code:
[meshes]
name1
name1.1
name1.7.lod1
name2
...
[materials]
name1
name2
...
[animations]
name1
name2
...That's a pretty nice nice static table. The ideal thing for a detailed dump is a relational xml array. But as none of us need it, the suggested is handy.
We can batch this for any needed resource file. That's the best thing I think.
That's pretty much it.
mtarini said:
Yes, we need objects from common res too. I'm not sure about submesh for I never make any scene-prob before.
I prefer several files output so the 3rd party application that access the list will only need to load the file it needs
(module_animations.py editors can load <your_module_name>.animations.txt only and item editors will take advantage from <your_module_name>.mesh.txt).
dunde said:
In practice yes, but to be precise, module_skins.py also accesses skeletons plus a few materials, and module_scene_props.py also accesses collision bodies. Just to be safe, it will not hurt to just dump every name.
New version coming up, but not what you would expect...
