Hardpoints editor with model preview.. work in progress!

[MarkyD]

excellent work mate 

[Aeries]

AHH! *squeals*!

I wonder if this'll be done when I get to hard pointing the Mithra!?

...ah hell, who am I kidding... Excalibur will be out WAAAYYYYY before the Mithra. *Seven years later*

Seriously, though. This looks freaking awesome! I cookie you for a great job so far!

[moed]

Man, this is awesome.

I've tried to use MPE before and honestly, it's too buggy for my taste.

Cookie time...

Great work!

[Jernej]

This unfortunately cannot replace the MPE without investing a lot more work hours that i don't have right now (having a job takes a lot of time), but i hope to give you a release which has at least some kind of editeability to let you place phasers properly when used in conjunction with the MPE (so you can check and set values of arcs and see how it'll look, then copypaste values back to MPE to save .py script).
 
EDIT: since hardpoints are just python scripts.. why didn't anyone make a universal one which like.. loads the hardoint data from a ini or xml file which is easier to edit?
 

[Jernej]

Playing a bit with fixing hardpoints for kb/m, it can do some fancy editing, but not yet enough (cannot set phaser matrix rotation yet):
 

 
The actual editor (yes, it looks butt-ugly):
 

 

[tiqhud]

can you make the orange, that you are using for the phasers a-bit more transperent, might help if there are some-ones overlapping.

[Jernej]

The orange is not precise actual coverage, but it is still very good, actual coverage shape is more like a section of a sphere, i am yet to make the rendering of phaser coverage precise enough (it is a complex system).
 
You can imagine the orange coverage like this: if you are watching towards the phaser origin point and you see it thru the orange thing the phaser can target you.
 
i can change the color of the thing, but the actual color doesn't matter much, because you can choose the scale for the phaser weirdness display and it is optional.
 

[cordanilus]

Wow, this is definitely going to be one handy tool once you're done. Looking forward to it.

[Starforce2]

indeed, that does look cool.

[Technerd89]

with this i might even *gasp* learn to hardpoint. looks good.

[Jernej]

I released the editor together with my little game here for those who wish to test it:
http://bc-central.net/forums/index.php/topic,4712.0.html
 

[Starforce2]

with this i might even *gasp* learn to hardpoint. looks good.

the MPE aint that hard to use..it's just an issue with crash bugs and lack of options...

[Jernej]

I've worked on improving the .py parser, obviously i made some very big flaws on how i process for example phaser colors.. i can continue hacking it until it would work, but if someone, anyone could help me hack app.py to dump it's hardpoint structures to kind of XML, ini, etc.. then this would be much easier, since doing reverse to generate back .py from xml or ini is much simplier.
 

[Aeries]

this is going to be really cool. I wonder if it'll be done when I've gotten to hard pointing the Mithra... that'd be so awesome!

[MLeo]

I've worked on improving the .py parser, obviously i made some very big flaws on how i process for example phaser colors.. i can continue hacking it until it would work, but if someone, anyone could help me hack app.py to dump it's hardpoint structures to kind of XML, ini, etc.. then this would be much easier, since doing reverse to generate back .py from xml or ini is much simplier.

The easiest way is to just load up a Python instance, create a Mock instance that only returns (new) mock instances (that can also log the paths) (easy to do) for Appc. And then go through all classes.

Every hardpoint related ty[e has a <<Type>>Property class and a <<Type>> class.

[Jernej]

There's around 30 objects that would have to be "mockified" that way, i think MPE's app.py would be more suited to hacking tho - it is smaller, but i could really do with some help with this.. i found out i'm not much of a python person, it's syntax seems like someone crossed C++ with perl and turned on strict identitation in pawn compiler :S
 

[MLeo]

There's around 30 objects that would have to be "mockified" that way, i think MPE's app.py would be more suited to hacking tho - it is smaller, but i could really do with some help with this.. i found out i'm not much of a python person, it's syntax seems like someone crossed C++ with perl and turned on strict identitation in pawn compiler :S
 

I think those are the same.

But the mock I propose can be fitted anywhere.

Part of the mock would be this (from memory, so not complete):

Code: [Select]

class Mock:
  def __init__(self, name):
    self.__name = name
  def __call__(self, *args, **kwargs):
    return Mock("%s(%s, %s)"%(self.__name, str(args), str(kwargs)))
  def __getattr__(self, name):
    return Mock("%s::%s" % (self.__name, name))
  def __str__(self):
    return "Mock(%s)"%self.__name
  def __repr__(self):
    return self.__str__()
Then, before you import App you do this:

Code: [Select]

import sys
sys.modules["Appc"] = Mock("Appc")


Oddly enough, perhaps, I think Pythons syntax is hardly anything like C++ or Perl (and I've programmed in both).
And I find the "indendation is scoping" quite readable. You have to agree that the mess people can make if you don't enforce indendation can be a crime, assuming you are working with more than 1 person at the same time, or if other people than yourself need to read the code.



The idea for the mock is to load up the hardpoint, then, assuming you print out everything, you can parse the result in some more friendly format.



[EDIT]

So you get something like this as output:

Code: [Select]

App::HullProperty_Create
App::HullProperty_Create("Hull")
App::HullProperty_Create("Hull")::SetMaxCondition
App::HullProperty_Create("Hull")::SetMaxCondition(9000.0)
.......

Ok, so only printing on __call__ would suffice I think.

[limey BSc.]

You have to agree that the mess people can make if you don't enforce indendation can be a crime, assuming you are working with more than 1 person at the same time, or if other people than yourself need to read the code.

Too true!! My programming lecturer can't seem to lay out a program properly at all! Makes it so much harder to read then it should be!

[Jernej]

MLeo: can you use that and dump a phaser? a PhaserProperty_Create one? i need to see how it dumps the colors and coords.
 

[MLeo]

@Limey98: It's not just for teaching. In everyday work this also helps.
Actually, any codestyle will help. Well, any that doesn't put everything on one line and doesn't require that everything is named with either $ or _ (which you can do in Java ).

@Jernej: You can, I think this Mock class will help more in this case:

Code: [Select]

class Mock:
  def __init__(self, name):
    self.__name = name
  def __getattr__(self, name):
    return Mock("%s.%s"%(self.__name, name))
  def __call__(self, *args, **kwargs):
    n = Mock("%s(%s, %s)"%(self.__name, str(args), str(kwargs)))
    print n
  def __str__(self):
    return "Mock(%s)"%self.__name
  def __repr__(self):
    return self.__str__()

I'm afraid it isn't perfect. So you will have to expand on this (one usefull thing to do, create a specific App.TGPoint3 mock, and a specific App.ColorA mock, that remembers setXYZ and setRBGA respectively). It's currently too late for me to do this, and I ought to have been working on other things as well.