Blender Import/Export Script?

[kage]

so then how about:

Code: Select all

CONGROUPS 2
CONNECTORS 3 ground
   0.0 3.2 0.0 0.0 0.0 0.0 30000
   0.0 3.2 -3.2 0.0 1.0pi 0.0 5000
CONNECTORS 2 vtol
   1.2 0.2 1.0 0.0 0.0 1.0pi 6500
   -1.2 0.2 1.0 0.0 0.0 1.0pi 6500
   0.0 0.0 -1.3 0.0 1.0pi 1.0pi 50000

where each connector would have the following format:
  x, y, z, xrot (lateral), yrot (vertical), zrot (longitudinal) max_supported_weight

(and yes, i'm still pitching for floating point radians with the optional 'pi' keyword).

the above connector data would represent either a ground vehicle that would probably have a large cannon pointing forward in the center and a rear-firing machinegun in the back, or a vtol with two forward-firing machineguns near the front and a rear firing very heavy weapon (bombs) near the back, all of which are to be rendered up-side down.

[DevUrandom]

I dont know why we would need the rotation things...
Besides that: It looks good.
Why those groups? To deal with the vtol upside down turrets?
That could be done by a "up" vector. (Telling you where the upper side is.)

//Clarification

[kage]

I dont know why we would need the rotation things...
Besides that it looks good.
Why those groups? To deal with the vtol upside down turrets?
That could be done by a "up" vector. (Telling you where the upper side is.)

because sooner or later (actually a long time ago) modders want to put fully accurate multi-turreted warfare in warzone, and in real life, not all turrets point forward, and not all independently aimable weapons can swivle 360 degrees. the rotation stuff would allow you to specify its at-rest orientation.

if you wanted something like a rear-firing machinegun that could only aim horizontally between 160 and 200 degrees relative to the front of the vehicle, then you could specify it's state of rest (aiming "down the center") in the model, and specify a total horizontal arc range of 40 degrees (for 20 to the left and 20 to the right) either in the model or somewhere else like bodies.txt. once again, i'm using degrees here, but i am a proponent of using radians.

besides that, a truely flexible "up vector" would require at two rotational components, so you might as well just give it 3.

the groups would be for handling which hardpoints are available depending on the body and propulsion selected in the design window.

[Per]

Right now we need a way to distinguish between small, medium and large weapon connectors, so that (for example) you cannot place three archangels on a droid... I'm not against the possibility of stricter limits, but remember this has all to be matched be more accurate weapon descriptions and code to handle it. That may take longer to implement.

[kage]

i think per-hardpoint weight limits should handle that with more flexibility than going back and defining every weapon as either large, medium, or small. it's the modder's problem if they decide to give a body 3 hardpoints each with a 500,000 weight limit.

and i'm just suggesting we lay out the framework and ignore the new data until the code is implemented -- with the new style connectors, you could, in the forseeable future, just read the x, y, and z components and ditch the rest.

EDIT: could use a couple screenshots of any model with connectors when viewed from the top and side in pie slicer -- something with the way the connectors are being imported in my latest version seems slightly off, and i want to make sure it's not just me. since i can't run pie slicer (don't have windows), i'd really appreciate it if someone was able to do this.

[kage]

if anyone cares enough to want the latest working code i have at any given minute, my git repository is available at devel.last-ditch.net/blender-pie. if you don't know how to use git, you can just wait for the more official releases. each commit should at least be somewhat stable, but if you use an unofficial release for serious work, you may have to tweak object names to get them to export (oh, and exporting as of the latest commit probably isn't anywhere near working status).

[Deathguise]

could use a couple screenshots of any model with connectors when viewed from the top and side in pie slicer -- something with the way the connectors are being imported in my latest version seems slightly off, and i want to make sure it's not just me. since i can't run pie slicer (don't have windows), i'd really appreciate it if someone was able to do this.

These any good:

Top View Python PIE:
http://i192.photobucket.com/albums/z147 ... Python.png

Side View Python PIE:
http://i192.photobucket.com/albums/z147 ... Python.png

[kage]

exactly what i needed. thank you very much 

[kage]

as i've come to understand it, various gfx-related formats used by warzone may be changing a lot very soon, but i have no useful information: can any dev's enlighten me as to any changes that may affect the model format?

[DevUrandom]

For what I know we were only discussing PIE improvements. There is still this idea of mine to support an additional format, but it certainly is not very elabortated.
Anyone else knows more?

[kage]

You miss read my comments in irc chat.

i had expected that i did, but i just wanted to make sure nothing massive was happening, like switching to a binary format, not that i have any problem with something like that -- would just like to know about such things early on.

[kage]

version 1.1 of the import script is done, and i'm imposing an organizational format freeze, so if you import a model with this this version of the import script, it will be compatible with all pie_export.py versions in the forseeable future (current export script is broken, and that's what i'm working on next).

changelog is also included in the zip, but i'll also display it here (changelog is not complete).

---------- pie_import.py v1.1 ----------

- all contents of a pie will be sub-objects of a PIE object.
- pie 5 texture coords are now considered fully opengl compatible, and the
import script supports this specification.
- fixed some wierd list semantics in the blender code. should've worked before,
definitely does now: the texture material is correctly added to the mesh, and
thus using blender's rendering operation looks correct now.
- added framework for general configurability. this conf screen is mostly
empty, atm.
- config options can now be saved in their current state during import, and
reverted to either the user-selected defaults or script defaults. options may
also be configured in the "Scripts Config Editor" script.
- layering script can be automatically run by importer now.
- custom scaling factor can be selected during import. may be useful if the
user is editing pies larger in pie slicer for extra precision (a double size
model made in pie slicer should get imported with a scale factor of 0.5, for
example)
- now conforms to the "Scripts Config Editor" recommendations, and follows user
settings for verbosity.
- temporary and poorly done fix for per's texpage selection problem -- now
looks 3 levels deep for ./texpages if need be.
- now supports an arbitrary number of team colors
- fixed a nasty and hard to notice bug that always occured during import where
the model got mirrored along the x axis on import. afaict, *all* versions of
the import script always did this.

---------- pie_levels_to_layers.py v0.2 ----------
- user can now have levels re-layered at will be running a script on any number
of objects simultaneously (used to be part of the import script).
- now applies strictly to selected objects, but will now assign PIE_* and
CONNECTOR_* to as many layers as there are selected, descendent levels

---------- pie_common v0.1 ----------
- fixed bug where not all settings would get saved the first time. namely the
ones that didn't appear in the option gui for the import script. note: the
names under which options will be saved will likely get to change very soon.
- added gpl license block

[kage]

fixed a bug that prevented team colors from ever importing correctly. slipped into the code somehow, but is now fixed.

[kage]

i lied about the import format being frozen, since i now realize that there's no way to conclusively determine the texture anim offsets using just 3 samples based on the way warzone wraps things around. i've got an idea that should work in all common cases, and will work on implementing that.