UnitConverter obj->bfxm

A forum for the discussion and development of programs to assist working on or playing with the Vegastrike engine and data sets.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Crashes vegastrike with "this app asked the C runtime to terminate in an unusual way..."
This bfxm is divided into many meshes, too; 13 of them. Probably the obj you have was the first I exported, with all materials assigned, which blender's exporter broke up; it oesn't seem the app is "putting it back together".
And there's no "techniques=" in there; there's an "alphamap", instead. This is by converting from bfxm to xmesh using the old mesher, tho...

Code: Select all

<Mesh scale="1.000000" reverse="0" forcetexture="0" sharevert="0" polygonoffset="0.000000" blend="ONE ZERO"  alphamap="" ="cinemut_opaque"  texture="tex_000.texture"  texture1="tex_001.texture"  texture2="tex_002.texture"  texture3="tex_003.texture"  texture4="tex_004.texture" >
<Material power="100.000000" cullface="1" reflect="0" lighting="1" usenormals="1">
	<Ambient Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
	<Diffuse Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
	<Emissive Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="1.000000"/>
	<Specular Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
</Material>
pyramid wrote:No idea about the mesher. It runs just fine here. Does it also crash when you run it from command line?
Yep, it does.
I think it just needs a .manifest to go with it. One of XP's new headaches.

EDIT:
Try with this test_bike.obj. It has all the polygons assigned the same material.
EDIT2:
Sorry, forgot; here's the test_bike.mtl.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

And I completely forgot to commit the manifest file to svn when updating vegastrike.exe with techniques. Save the following code as vegastrike.exe.manifest

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>
The bfxm had the techniques and textures correctly assigned. I made the screen shot with it and the file definitely contained the references to cinemut_opaque and the tex_00x.texture s. I have now uploaded the bfxm as one complete mesh under the same address as before.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Thanks!
Still crashes vegastrike, tho.
I already had manifest for vegastrikeR_techniques; but I backed it up and made a new one; but it still crashes. :(
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Too bad. Hopefully ace123 or klauss can help.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

The stranger thing is that vegastrikeR_techniques never crashed on me before; it's only with this bfxm that it does.
I just started a new game, from vegastrikeR_techniques, and no problem.
Sent an email to klauss. I think he's very busy with RL these days, tho.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Could you try again with this new .obj + .mtl, when you get a chance?
http://deeplayer.com/vs/shaders/testmodel/test_bike.obj
http://deeplayer.com/vs/shaders/testmodel/test_bike.mtl
What I did is I created a new material, assigned it to the whole bike, and then deleted all the unused materials, in object mode; then exported.
Maybe the unused materials were confusing mesher?
I hope that's it.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Here we go again (down the only road I've ever known... 8) ).

The conversion seems to work just fine here with both mesher and vegastrike.exe (both with techniques), except that I can't visualize correctly the textures with cinemut due to my card being so bad.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Same thing... :(
I'll send Klauss another email. He hasn't replied to even one email of mine in more than a week, tho.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Alright, I went back to working on the shader using the old bike.
Here's the latest version of CineMut Opaque, if you want to try it with the new bike; though it could very well be that the textures are borked; I've never tried them, of course.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

UnitConverter v0.27 is released to svn.

New features:
* doesn't require material export, the mtllib entry will be created in th eobj file if missing (and mtl file is created from scratch as before).
* you can now store your default shader under Config.
* fixed unwanted delete of file names on browse cancel.
* deleted the ini file from release. it will be created from scratch on first run, but you'll need to Config the app to work correctly (warning is shown).
* manual sounds entry form (though unit sounds do not seem to work in-game).
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Excellent! I'll try it when I get home, though I doubt my luck will be any different; I think the problem
is something with mesher and/or vegastrikeR_techniques. BTW, I messaged Klauss and apparently he IS
totally overwhelmed with RL work.
What maybe I will try to do tonight is try UnitConverter with the Hammer; though I won't be able to test
the texturing yet, as I have to bake PRT's for it, and that will take about 20 hours each.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

Out of curiosity, pyramid, how far do you consider the UnitConverter to be from "1.0"?
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Actually still quite far. So ar the still-to-do list:
# check textures for POT dimensions (with Python 2.6)
# magic check textures for image types accepted by nvcompress (with Python 2.6)
# unit.csv editor - add (more stats, mounts, docking ports, ...)
# maybe import and display model using OpenGL (just maybe)
# integrate LoD and submesh processing (grouped texture assignments)
# mesher add operation with several models(subunits) in the same workspace
# storing and batch conversion of faction textures
# make frames scrollable (for units editor)
# improve configuration read/write and screen updates
# converting one obj with submeshes with different textures

The time consuming thing will be the unit stats editing as every unit contains more than 100 parameters. I might also split it up in the future as an independent app within that framework.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Actually, units.csv is a plastic thing; a flexible format. One mod could have more, less, or different columns as another. I was just thinking of adding a column for heatseeking missile's alignment behind a ship needed to acquire/maintain lock (as HS missiles in PU don't behave like in the original Privateer).

Perhaps the easiest thing to do would be to make a generic function that just parses the first and second rows of units.csv and displays the names and units of each parameter sort of blindly, and gives you fields to fill in; except for the few you're closely concerned with, like for weapon mounts and stuff.

If your feature list is getting too short :), each ship usually needs .blank, .something and .template versions. They only differ in systems and weapons loadout, tho. Easy enough to do manually. On the other hand, if it's going to edit units.csv to add one line, it might as well add all three, even if it just makes them all the same. Then again, this is only for ships. Then again, the app knows whether it's a ship, from the info for the AI role column. Hmmm... maybe that one should be on the first page, a must-fill first.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:Actually, units.csv is a plastic thing; a flexible format.
Oops, I didn't know that (lack of documentation?). I have always assumed that the columns are fixed since they are related to engine functionality. If I add columns to units, then how would the engine know what functionality to execute for the new columns? I can understand that swapping columns is ok for the engine (though for UC it's not, needs to be revised) as it probably searches the column keys.
chuck_starchaser wrote:each ship usually needs .blank, .something and .template versions
Definitely a good idea which I will put on my task list. Though I see many extensions the ones that repeat for almost every ship are .blank, .stock, and .milspec. They will be a one to one copy of the main ship on creation and then can be edited to a different configuration.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

pyramid wrote:
chuck_starchaser wrote:Actually, units.csv is a plastic thing; a flexible format.
Oops, I didn't know that (lack of documentation?). I have always assumed that the columns are fixed since they are related to engine functionality. If I add columns to units, then how would the engine know what functionality to execute for the new columns? I can understand that swapping columns is ok for the engine (though for UC it's not, needs to be revised) as it probably searches the column keys.
You're right; the engine does have to know about a column in order to use it; but this is, anyhow, one of the common causes of engine changes. A couple of years ago, I helped spiritplumber to add a "tractorable" flag column to units.csv, to solve a problem about ships being able to tractor in jump points, permanently altering maps. I believe the tractorable flag is in widespread use now; but in the future there could be mod-specific columns, and config variables that cause the engine to use or ignore them. It's probably already happening, I'd bet.
In any case, what I meant to say is that units.csv's tendency to change often could be a real headache for you, if you hard-code input fields for it. A generic function that reads the current units.csv and formats its entry fields accordingly would probably be easier to code and maintain.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

chuck_starchaser wrote:In any case, what I meant to say is that units.csv's tendency to change often could be a real headache for you, if you hard-code input fields for it. A generic function that reads the current units.csv and formats its entry fields accordingly would probably be easier to code and maintain.
Absolutely right. I was thinking about creating dynamic UI for units.csv (which I still have in the back of my mind). As I'm a newcomer to python and tkinter, which has it's quirks with updates of screen objects (need to keep field variables to display values, need to track option field states, need to purge label objects before updates, ...), I had some difficulties to even update labels or option buttons. Meanwhile I have solved the main issues and I think I can start making an independent class for units editor which I could both, integrate into the UC and as a stand-alone tool.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

And i have a new feature request :lol: back conversion ie.from the bfxm -->obj + mtl it will be needed for the conversion of our existing stock where the original obj and mtl files may not exist :( although that task does seem to be more amenable to a simple bash script :wink:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Yeah. Makes sense to me when one wants to read the model parameters. To be added to UC feature requests.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

re: unit name extensions --

given a unit name BASENAME or BASENAME.EXTENSION , the engine, depending on configuration, will look for BASENAME.blank and/or BASENAME.template when performing certain upgrade calculations (the .template option is an older maximum value limiter that is not currently used by the VS dataset, but may be used by other data sets). Units of the form BASENAME.blank are considered as the base stats for BASENAME.* and any given BASENAME.EXTENSION variant is treated by the upgrade code (conceptually) as the result of a sequence of upgrades applied to the BASENAME.blank unit.

All other extensions are primarily decorative (other than potentially changing a line in the ships descriptive text, they have no particular effect). Additional extensions may be added at will for all variants of a given unit BASENAME.blank.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Just curious, how does VS manage not to use .template? How does it know where to stop with upgrades for a given ship? Is the info stored some place else? Or is upgrade volume the only limit?
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

chuck_starchaser wrote:Just curious, how does VS manage not to use .template? How does it know where to stop with upgrades for a given ship? Is the info stored some place else? Or is upgrade volume the only limit?
Combination of upgrade space and the prohibited upgrades field.
We wanted people to be able to make tradeoffs rather than provide hard caps (e.g. you _could_ buy that really big reactor, but then you won't have space for X, Y, and Z). There are few items/item categories which end up being explicitly prohibited by the prohibited upgrades field at present (overdrives for Rlaan and jump drives for in-system craft being the primary examples of cases where upgrades have been explicitly prohibited) but the prohibited upgrades field is configured so as to limit the number of a given class of upgrades one can have simultaneously installed, thereby providing an additional constraint (i.e. we can have additive upgrades but limit their number, even in the case of available upgrade space).

There is sufficient functionality in the prohibited upgrades field to, by explicitly denying upgrades beyond a given level on a per-name basis, duplicate most of the (intended) functionality of a .template entry, although generating said list by hand would be excessively tedious.
If the properties modified by any two upgrade families are disjoint, then this can fully duplicate the abilities of a .template entry.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Sounds like a good way of doing. I think for PU we're stuck with the template method, for now; but I'll give that a try with new ships, once we open into the Sol sector. Thanks.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

Maybe this is a better question for the moding forum, but speaking of upgrade code flexibility, would a recode of the VS engine's upgrade code be needed for a mod where thruster performance stats come from a thruster upgrade of its own instead of being an integrated part of a ship's stats?
Post Reply