[WMCoolmon]

Internal thread (for me when I start coding this):
http://www.hard-light.net/forums/index.php/topic,33845.0.html

As per mikhael's request, a brief outline of stuff I'd like to have
gr - Basic graphics library
For all 2D drawing functions, like line, circle, box, bitmap, etc.

g3d - 3D graphics library
For all 3D drawing functions, like models or bitmaps in 3D space or maybe 3D lines

sxp - SEXP functions
Maybe just an evaluate-sexp function. This would mostly be a hack to get SEXP data and functions integrated where Python doesn't have 'em

mth - Math lib
Whatever functions aren't included with default Python math libs.

Presumeably some of the appropriate python libs would be imported by default, so you wouldn't have to import them every time. The math library in particular, since getting rid of the prefix would make it more readable and easy to use and there really aren't many functions named "cos"

Past that...

Ship class
Features simple stuff like get_speed get_name get_target etc.

Mostly I've been more concer



HUD Stuff - basically once new HUD stuff is define, it turns off the original ones. The goal is more to provide an all-new system than to integrate with the old one, that would be more trouble than its worth.


Now to quote my post in the big feature thread:

For the new HUD I was thinking along similar lines. The old :V: system is so hardcoded it isn't even funny.

For both of these I'd probably be relying on Python integration as well to give a lot of flexibility (without sacrificing much simplicity) to modders.

So general idea for a gauge entry:

Code: [Select]

$Name: Blah
$Show in: ("cockpit" "target cockpit")
$XCoord: 100 ;; Draw 100 pixels to the right of the left edge of the screen
$YCoord: 240 ;; Draw 200 pixels down from the top edge of the screen
$Draw: {
     # What you want to draw goes here. Like to draw a
     # 100 pixel-square X:

     # Top left to lower right
     gr.line(0, 0, 100, 100)

     # Top right to lower left
     gr.line(100, 0, 0, 100)

     # Draw the current target model too?
     g3d.draw_ship_model(self.target(), 0, 0, 10, 10)

     # Write the name in the upper left
     gr.text(self.target().get_name(), 0, 0)

     # Note that 'self' would refer to the ship you're
     # currently viewing from, rather than just the player ship.
}

Gauges would be separated into different 'screens' (I use the term because that's the class name for the new GUI, Gui_screen), each screen would correlate to a different ship type or something.

Assuming all this got implemented, it'd be really really flexible; you could do pretty much anything you wanted with the HUD, the only limit would be how advanced of Python knowledge you had. [/B]

[mikhael]

So, is this mainly a script your own HUD thing, or is this intended to eventually be linked deeper into the engine?

[WMCoolmon]

Right now it's going to be mainly for the HUD thing, but if I can get it working, Bobb has expressed an interest in using it for the textures system.

I'd also like to use it for the armor.tbl system to get rid of the cumbersome calculation system in there now.

I didn't really plan on linking it into the physics system or something, but things like that could probably be arranged on request. My *preference* would be to have a global functions library, so everything available in the HUD would be available elsewhere.

[mikhael]

I was thinking more along an abstraction layer between the low end engine, and the player, implementing all the existing game systems and SEXPs in Python. That would make the engine fairly universal and move the hard coding up to a level where more people could deal with it. It would also have make certain things (complete ship animation channels and the like) more readily available.

[WMCoolmon]

Yeah, that's a lot more work than I'd like to plan on doing at the moment.

If I can get the system I described fully working it'll be a huge step forward in hud modding and very extendable.

[mikhael]

If I can help with the python stuff, I'll do anything I can.

[Goober5000]

NO NOT PYTHON!!

*runs away screaming*

[mikhael]

Why not python? Python rocks block.

[WMCoolmon]

What scripting language would you recommend (Besides SEXPs )?

[mikhael]

I nominate Perl. Or Rexx. Or VBScript. Or PHP. Or Java!

No really, I mean it. Stay with Python. It is TEH WIN, to be so 20th century. Easy of readability, good exceptions, good tracebacks, lambdas, blah blah blah.

[Nuke]

think you could move more stuff into python, so we could do custom weapon flags and such?

i dont care what scripting language you use, just so long as its about the same ease of use as quake-c.

[WMCoolmon]

Basic interpreter is up-and-running.

• I can't compile in debug mode because I don't have python24_d.lib
• I haven't gotten it so that you can drop the initial "gr." and the like via C
• I've coded the basic HUDGauge GUI function, but haven't actually gotten proper parsing set up (right now it just reads 'python.tbl' and executes Python after $Python:)

However, here's going to be the basic idea wherever Python is involved...

At program start, *all* libraries will be initialized. These will be usable in all fields, at least via the "import" command.

(TODO) Individual subsystem (EG HUD, Texture system) may define libs to be auto-imported, so no import command will be necessary. Or, they can make all functions available.

Wherever a Python 'field' is, you can do one of two things. If you just want to throw in a single-line expression:

Code: [Select]

$Python: gr.line(1,2,3,4)

Or, if you want a multiple-line code block:

Code: [Select]

$Python: {
     gr.line(1,2,3,4)
     gr.line(4,3,2,1)
}

THe {s may be pretty much anywhere you like so long as the Python code is inside them.

The onlylimit to how long a Python code block may be is the maximum parsable filesize. A line may be up to 4096 bytes long. (But you should really be using a code block for that :p)

[WMCoolmon]

Here's the basic C API in fs2_open:

PyBytecode python_parse();
The magical parsing function; it compiles Python into bytecode. AFAIK you do not need to have a 'session' going for this to work

PySession py_session_create();
Creates a new Python 'session'. This is a virtual thing I came up with to make everything easier on the mind. Any modules you import etc will only be availabe in this namespace

void py_session_import_module(PySession* session, char* module_name);
Imports a module into the current session; the same as saying "import module_name" in Python. (Still not working)

void py_session_use_namespace(PySession* session, char* module_name);
Makes a module's functions freely available, without needing to use the module name. (Still not working)

PyResult py_session_evaluate(PySession* session, PyBytecode* code);
Actually executes Python code that was parsed into bytecode.



I've tried to abstract stuff as much as possible so it's not necessary to worry about calling X_INCREF and X_DECREF (PyResult, PySession, and PyBytecode are all basically identical classes that call them).

[WMCoolmon]

I've got single-line expressions successfully evaluating as strings, floats, and integers in C.

Basically this adds a few functions to PyResult:

Code: [Select]


bool GetLong(long *dest);
bool GetDouble(double *dest);
int GetString(char *dest, int dest_size);




As far as modding goes, the basic limitation here is that it looks like that if the field takes a return type, you're not going to be able to take multiple lines. Meaning, I don't think you'll be able to import something for something like "$X Coordinate:".

[Goober5000]

Originally posted by WMCoolmon
What scripting language would you recommend (Besides SEXPs )?

Pretty much anything except Python.  I've had too many bad experiences with it.

And don't get me started on that thrice-cursed indentation rule.  If I wanted whitespace to stand for anything, I'd use Whitespace.

[kasperl]

Originally posted by Goober5000
And don't get me started on that thrice-cursed indentation rule.  If I wanted whitespace to stand for anything, I'd use Whitespace.

That is a joke on itsself. A good one too....

[FireCrack]

Are you saying that python is whitespace sensitive?

[WMCoolmon]

Code: [Select]

if my.func() is True:
     my.do()
my.otherthing()

do() will only execute if func() is true; otherthing() will always execute. A tab is used to delineate a code block, or whatever they call it, rather than brackets.

It doesn't look like it has any problem if you start off with a tab or something.

Also, I think that it's sensitive to tabs, rather than spaces (i used five spaces in the example b/c i'm lazy)

[mikhael]

Originally posted by FireCrack
Are you saying that python is whitespace sensitive?

Yes, it is. Python enforces a consistent indentation patter at the block level. It doesn't matter how you do your indents, so long as they're consistent. This annoys sloppy coders.

This makes people like me, who have to read other people's code a lot, very very happy.

[Kazan]

Originally posted by Goober5000
NO NOT PYTHON!!

*runs away screaming*