Lord_Cheap
Squire
mtarini said:
So the Warband format is fixed? I remember reading before that it was bugged, but perhaps the new version has fixed it. Great tool by the way
Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]
- Thread starter mtarini
- Start date
Users who are viewing this thread
Squire
So the Warband format is fixed? I remember reading before that it was bugged, but perhaps the new version has fixed it. Great tool by the way
HELP
I save the changes but see no new props when editting...
For example. I copy some props, rename them and give them a different game. Then I save it but they don't appear on the props list on the scene edittor. Is there somth I'm missing?
I save the changes but see no new props when editting...
For example. I copy some props, rename them and give them a different game. Then I save it but they don't appear on the props list on the scene edittor. Is there somth I'm missing?
Adding them in module_scene_props.py and compilingRevan Shan said:
GetAssista said:
Thanks.
Another silly request: please make the background RGB value 100, 100, 100, instead of 128,128,128. Would help a lot when taking quick screenies- 128,128,128 is the gray value Photoshop uses for lasso, etc., and you literally can't see what you're selecting on a background of that color
Back to XP, redownloaded Open BRF and it still doesn't show any texture, do I need aditional programs to make it work ?
Yes, you need M&BSwadian Man at Arms said:
since OpenBRF picks texture references from module.ini, scanning for every material inside the module. If you open some standalone brf, Ob might not be able to find materials/textures
That's not the problem, I just opened some .brf files from CommonRes, one year ago it worked, but now...
I'm sure there's something wrong with my operating system or I missed a program but I have no clue what to do.
I'm sure there's something wrong with my operating system or I missed a program but I have no clue what to do.
I had the same problem: every texture was checkerboard-ed.
Solution: Buy a new PC (worked for me, but I can't guarantee this for you...
)
Solution: Buy a new PC (worked for me, but I can't guarantee this for you...
)
The Shadow
Recruit
You need to put your textures in the Native textures folder as well, if you want to see them. Works for me anyway.
If you read "why isn't my texture showing up" or whatever it's called, it will explain.
If you read "why isn't my texture showing up" or whatever it's called, it will explain.
dejawolf
Knight
can anyone tell me why this happends?
and before you go "nuuuh, u dinnt skin corectle oLololooLol!!!!!!1111one"
yes i did. as you would obviously be able to discern from the helpful image from 3ds max i posted.
another oddity is that anything i export from BRFedit, then import into max, and re-export, always looks correct.
*edit
looks like i found a viable workaround. its probably got to do with vertex order or some ****, but when i attach a mesh to a mesh from mount and blade, and delete the original mesh, it seems like the skinning is exported correctly. but when exporting anything originally from max, i get anything from crashes to these weird skinning errors.
Chances are, it's a coordinate-system issue, or the bones aren't connected to the skeleton using the exact hierarchy. I've always exported the reference BRF as SMD, then deleted the mesh, to make sure that everything is totally right, before importing a mesh that I'm going to rig.
But, even better yet, I've found, is to use OpenBRF's auto-rig, then export from OpenBRF to your editing suite to finish tweaking the rig. Try it that way- it also saves a bunch of time, if the model you copy the rigging from is reasonably close. And it seems to reduce rigging problems to a minimum.
But, even better yet, I've found, is to use OpenBRF's auto-rig, then export from OpenBRF to your editing suite to finish tweaking the rig. Try it that way- it also saves a bunch of time, if the model you copy the rigging from is reasonably close. And it seems to reduce rigging problems to a minimum.
New Update!
Not by me, this time.
[Foxyman] completed the support for the translation, making basically everything translatable, then contributed a Chinese translation!
And he sent me his updated code + translation! Way to go!
So all the kudos to him...
From the 1st page...
From now on, you can contribute a translation too!
To do so, it is easy, if long. From the 1st page:
Not by me, this time.
[Foxyman] completed the support for the translation, making basically everything translatable, then contributed a Chinese translation!
And he sent me his updated code + translation!
Way to go!So all the kudos to him...
From the 1st page...
From now on, you can contribute a translation too!
To do so, it is easy, if long. From the 1st page:
Just posting a shameless plug for my Fawzia Mod Verifier - now updated to check for missing and unused meshes and other things:
http://forums.taleworlds.com/index.php/topic,118055.0.html
And thanks for your help with the BRF format, and for making OpenBRF so useful.
Cheers,
MV
http://forums.taleworlds.com/index.php/topic,118055.0.html
And thanks for your help with the BRF format, and for making OpenBRF so useful.
Cheers,
MV
New update!
From 1st page:
Random notes:
MadVader: good! and don't worry about the plugging, our modding tools need more visibility, as they can save a lot of time to modders and help them making great mods! never used tour Verifier so far, but I think I will. Very useful.
From 1st page:
Random notes:
- The first point (non-ascii paths) is a long due fix. It required me to change the code in some 50 places, so in case anything broke let me know.
- The "Add to Clipboard" command might require some explanation: it is like Copy (ctrl+c), but it cumulates: you can copy something, then add something else, and so on, before pasting it all. Useful for example when you want to take objects (meshes, textures, etc) from several tabs or several brf files and merge them easily into one brf file. Remeber that if you close OpenBRF the content of the "clipboard" ((that's where cut and copied things go)) is erased!
- (BTW, did you know that when you [ctrl+C] to copy an object (a mesh, a texture, a material...), you can then [ctrl+V] to paste its name in any text editor (or in any text box inside openBrf itself)? Useful for editing the .py files in the module system!)
- I added the Copy Timings command because many export/imports of vertex animations and skeletal animation "forget" about timings.
You copy an animation (ctrl+C), then paste its timing (with that option) over one (or many) target animation(s).
The idea is that you can, for example, export an animation, edit it, import it as a different animation, and paste over it the timings you copy from the original animation.
- The "option to test new translation files (*.qm)" is a tool I provide to those who kindly offer to add a new translation, or to update an existing one (PM me the updated/new .ts file if you do!).
You prepare your qm translation file (with QTLinguist, by Nokia) strating from a .ts file found in the first page, then, to see how it will look, you can load it with that command.
MadVader: good! and don't worry about the plugging, our modding tools need more visibility, as they can save a lot of time to modders and help them making great mods! never used tour Verifier so far, but I think I will. Very useful.
Oh, wait... it worked the second time the application ran
Also, it'd be nice to know what the breaking angle is, when setting vertex normals. I've found that the results are hard to see in the rendering system, vs. having a shader on in-game- the specular shader shows things that are pretty hard to see in Phong lighting.
But it seems very hard to get hard edges for things atm via "recompute normals" without having anomalous results with other facets. May have to just live with it, but it's annoying, since Wings tends to do 'orrible things to OBJ in terms of vertex count when hard edges are set, resulting in massive vertex-count bloat. I have middleware I can use to address this, but it's not free and most end-users can't do that. I'll go post on the Wings forum about this issue, since it's really their problem
Broken search: sorry, I left a bug there. Fixed now. About to commit next version (it has features too!).
--------
Re-compute normals: I know, it cannot be perfect all the times, it is just supposed to be good enough, most times.
So it is just a tool intended to save a lot of time in certain common situations (you can also do in in bulks).
But surely it cannot magically substitute careful, manual edge-by-edge selection of "smooth/hard" status.
That is supposedly done with whatever application you use to edit your meshes.
If the mesh you import has normal information, that's gonna be preserved.
What it does: first, it trashes the normal you currently have, and compute them for each face anew. Then, if makes edges "hard" or "soft" according to the angle of the two faces around that edge: almost flat solid angles are made soft, steep angles are made hard. In reality it is more complex than than, (there's vertex replication and vertex joining involved, it takes in account texture seams... and so on), but that's basically the idea.
--------
Re-compute normals: I know, it cannot be perfect all the times, it is just supposed to be good enough, most times.
So it is just a tool intended to save a lot of time in certain common situations (you can also do in in bulks).
But surely it cannot magically substitute careful, manual edge-by-edge selection of "smooth/hard" status.
That is supposedly done with whatever application you use to edit your meshes.
If the mesh you import has normal information, that's gonna be preserved.
What it does: first, it trashes the normal you currently have, and compute them for each face anew. Then, if makes edges "hard" or "soft" according to the angle of the two faces around that edge: almost flat solid angles are made soft, steep angles are made hard. In reality it is more complex than than, (there's vertex replication and vertex joining involved, it takes in account texture seams... and so on), but that's basically the idea.
So... update (third time in three days... I know.)
From first page:
The Spanish translation is due to Swyter!
Doing these translation is hard work, it is maybe a LOT of lines of text to translate. Swyter (in Spanish) and Foxyman (in Chinese) did a really great job: not only they translated, but also took care and double checked that everything looked fine and fitted into place. So, big kudos to them.
(As you know, Foxy also contribute to the code itself, polishing and finishing the "translatability" part, so that translation was made possible. Another task requiring patience, BTW.)
The search bug (where "no results" would occasionally be shown) should be gone now.
The last point is something we needed for our mod (TLD -- The Last Days. The Lord of the Ring one). You know how collision meshes can be made by quads (not only by tris). Expressing the same collision object with fewer flat quads is way more efficient in game, than with twice as many tris. If your collision objects are made with tris, this can be a great time saver to make them better: with that command, OpenBRF tries its best to find good triangle pairs which can be merged into single quads. You can do it on multiple collision objects at once too (just select them all). Even a few collision objects in native can be ameliorated this way.
(I also improved how collision objects are rendered in OpenBRF.)
From first page:
The Spanish translation is due to Swyter!
Doing these translation is hard work, it is maybe a LOT of lines of text to translate. Swyter (in Spanish) and Foxyman (in Chinese) did a really great job: not only they translated, but also took care and double checked that everything looked fine and fitted into place. So, big kudos to them.
(As you know, Foxy also contribute to the code itself, polishing and finishing the "translatability" part, so that translation was made possible. Another task requiring patience, BTW.)
The search bug (where "no results" would occasionally be shown) should be gone now.
The last point is something we needed for our mod (TLD -- The Last Days. The Lord of the Ring one). You know how collision meshes can be made by quads (not only by tris). Expressing the same collision object with fewer flat quads is way more efficient in game, than with twice as many tris. If your collision objects are made with tris, this can be a great time saver to make them better: with that command, OpenBRF tries its best to find good triangle pairs which can be merged into single quads. You can do it on multiple collision objects at once too (just select them all). Even a few collision objects in native can be ameliorated this way.
(I also improved how collision objects are rendered in OpenBRF.)
