More stuff accessible from Python

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

More stuff accessible from Python

Post by chuck_starchaser »

This is a bit of a "general" feature request. Problem is, too many things happen in C++, which, as a modder, one has no access to, and that, IMO, one should.

A perfect first example is quitting the game, either by pressing [ESC] after dying, or by pressing [ESC]-Q while still alive. Apparently this is done in C++ and there's no easy way to modify. At PU we want quitting actions to lead back to the opening main menu, rather than quit the whole application back to the desktop; but we can't seem to do it because the quitting is hard-coded.

Another is targets. We'd like to separate navigational targetting from tactical targetting, but it seems we have no access. It makes no sense that the "target nearest/most dangerous" hostile would target a base, even if it's a hostile faction base, when in PU most bases don't even have turrets for defense. And if I select a jump point as a navigational destination, it makes no sense that I would lose the selection when I need to target a ship, either to fight it or to talk to. Most importantly, the original Privateer game had independent navigational targeting (which put a white cross around your destination, rather than a locking square), and we'd like to make PU be like the original Privateer as much as possible. Question is, if AI is in Python, why not targetting?

Another example is ship purchases: It seems that in PU, when you buy a ship from the ship dealer guy, the purchase goes through a Python function; but if you purchase a ship through the ships GUI, the purchase is done in C++. This is a problem because we wanted to modify the purchase code so that if you have cargo in your current ship it gets moved to the new ship, automatically, if it fits; and otherwise it tells you that your cargo can't be moved and refuses the purchase. (This is to patch possible exploits such as having a Paradigm fully loaded with catnip, flying a cloaking Excalibur fighter to Kilrah, landing there, then having your Paradigm delivered unscratched with the full cargo.)

Another example: Right now there's a bug in PU which I hear is present in vegastrike as well... If your hull gets damaged, once you land, sometimes the price for repair is astronomical. Yes, it would be nice to have the bug fixed, but it would be nicer still if the computation for the repair cost was in a python function, so that one could just fix it. Not to say that it doesn't make sense that repairing something shouldn't be more costly than buying new, sometimes... It does make sense: if I total my car, how much would a garage charge me for putting it back together to brand-new condition? But in that case, we need a means to DUMP the item, just like one can DUMP mission cargo in the commodities room. But it seems that all of the GUI stuff is hard-coded and inaccessible to modders.

Another one: Faction name display on the HUD. We wanted the display code to automatically capitalize the first letter, plus the first letter following an underscore, for HUD purposes; but this is in C++ and Hellcat pledged to change that code, but we're still waiting, months after. Now we'd also like to NOT display any faction names that end with single or double underscores; but again, no access...

There needs to be some kind of policy in place for what's to be C++ and what's to be Python. Presently it seems kind of random.
Last edited by chuck_starchaser on Wed Mar 05, 2008 7:12 pm, edited 1 time in total.
Xit
Bounty Hunter
Bounty Hunter
Posts: 186
Joined: Mon Aug 06, 2007 2:34 am
Location: Cambs

Post by Xit »

I don't really see why it makes sense to do any base/docked functions in C++, the extra performance shouldn't ever be needed...
Save The Economy
http://vegastrike.sourceforge.net/forum ... hp?t=10605

My boxes: Dual Opteron 280s, Geforce 7600, 2GB RAM, but waiting for a new PSU! grrr...
500 MHz Compaq laptop that gives DC electric burns
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Yep, the whole news/missions/commodities/ships/upgrades GUI should be in Python, IMO.
But even things like quitting, in space, it seems rather absurd that there'd be no Python callback, nothing...
And everything having to do with text in the cockpit should be Python too, IMO.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

catching exits and returning to the main menu should be the defacto behavior anyway, the only reason it's not is that the main menu is new and nobody's bothered to take the time to make the changes to the exit handling code.

maybe we do this already, it's not my area in the game.. But it would be ideal to have hooks in C++ to use python callbacks. Then we could basically have python provide those features or fallback to the C++ defaults when no callback is provided.

I think the way it works now is python calls a function, waits for a return then does something else. If it's not correct me. I would think though that VS c++ would require a lot of python callbacks, rather than just providing exports, to avoid these issues you are talking about. and maybe it does. I've never looked.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

The thing is, i'd hate to see things like AI and the economy and (even though it is) dynamic universe in python and not in a faster C++ version. Get initial values from hooks, have hooks to handle specific items, have hooks to handle transactions, but the longer we're in python, the longer we're not simulating (since we're not threaded) and the more memory we use. that's about the biggest reason i have for not dumping everything to python. Even on bases, i'd like to see the rest of the universe continuing with little to no slowdown despite our playing with upgrading our ship. It'll be a great day when we can have the player in a base that is under realtime attack by ships in space, and you have to rush to launch to try and survive it's destruction.

I think it's amazing that we use 200MB on load even before we start creating units and loading textures, the only thing i can think of is the python files loading eachother to get things rolling.

I'm not anti-python and thus anti-mod. I just dont know it we import python functions into the C++ backend, which is how i think most of the game should function, not the other way around.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Glad you agree. The Quit-to-Main Menu thing would be wonderful to see ASAP. Everybody at the PU forum keeps asking for it. PU doesn't have compressed textures yet, and it takes much longer than vegastrike to load. (Well, I don't know if that's the only reason... but this is subject for another post in the Modding Help Forum... Ehm... No such forum...)
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

it is probably the main reason. PU doesn't do dyn universe, so all in all, pu should be a much lower footprint than vanilla VS. Go back and look at how long VS took to load before i made all the textures DDS. Then look at it today. many times faster, I would say it loads well over 10 times faster.

You guys dont have shader stuff to worry about. I think it would be very easy to move everything over to DDS for PU, including backgrounds and such. Plus. if you're using the latest VS svn and have png files, those dont get compressed. So you're using tons more memory than you should be if you use png's widely.

That's up to you though. Textures would have to be checked for power of 2 sizes, then just run a script to convert them all. Your game will load to main menu in like 10 seconds and into the game in less than 20
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Hahaha, safemode, you've probably forgotten it was me that convinced you to go to dds compression, last year; in that dev forum thread about the old hiccups. You're absolutely preaching to the converted. :) I never actually imagined it was going to make SO MUCH of a difference, though, I confess. I updated my vegastrike svn yesterday and I almost lost all my hair. Astonishing. No, the only reason we haven't started converting stuff to dds is that a) we have a pile of urgent stuff to deal with; particularly in the testing branch, with dynamic universe, btw. Spiritplumber came up with with a dynamic universe "solution" for us, then took off for no reason, and we're banging our heads against the wall trying to make it work. b) For ships I want to finish the work I started on shaders first, because that will dictate the texture packing. My original idea was to put the u and v of the normalmap into the alpha channels of the glow map and damage texture; but recently you mentioned there's a dds compression format for normalmaps. Plus, while all other textures are shared by all LOD's, normalmaps we need one per LOD. So we can't mix it with the rest. Finally because the normalmap needs twice the resolution as the other textures, IMNSHO. But I'm waiting for klauss or Hellcat to test and commit my tangent code, first. Having tangents in the mesh will free up shader instructions I can use for more important stuff. So, it's got to be tangents first, then shaders, then blender noodle automation of texturing (long story) and finally dds'ing.

But the quit to main menu is a MUST, anyways; it's just so "Alpha" for a game or app to just exit like that... Unprofessional.
Post Reply