Page 4 of 6

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Aug 21, 2013 6:53 pm
by klauss
pheonixstorm wrote:Actually its whatever Klauss or myself can do. John hasn't been around in years, though I did get him to add me as forum admin and a dev for the svn. I just haven't really had the time for anything. Or the motivation it seems...

As far as GG goes.. It still uses VS .5 for the engine and we can still compile current svn to use spheremaps rather than cubemaps. So the only real change needed for GG is to update the core python code.
There's a set of patches made for GG that improve lots of aspects, that touch the python side. Some were applied, some wheren't, so merging with VS python will be tricky.

Making cubemaps for GG isn't actually that hard either, so it's worth a shot. Cubemaps are superior in many aspects after all, and you really don't want to adapt all the shaders that in VS now use cubemaps to spherical addressing, just to avoid creating them. I'm not actually sure that'd be less work, it'd probably be more work. So making cubemaps is, IMHO, the best option.

Re: Frankenstein’s Monster is Alive!!

Posted: Thu Aug 22, 2013 10:54 pm
by ermo
Today I've been thinking a little about how to make Privateer: WCU be a mod 'overlay' on top of current VS data/.

The idea is to not duplicate any VS python code unless absolutely necessary and generally try to leverage VS .py modules as-is. So far, I've simply come up with having the PWCU mod live in its own data/ root folder and only having the .py scripts it needs to override existing VS .py modules -- e.g. faction_ships.py and campaigns.py would be two obvious candidates.

Is it possible to do this by simply ensuring that the sys.path is set up such that the PWCU data/ mod folder is searched first, and then afterwards, the VS data/ folder is searched for whatever modules aren't present in the PWCU data/ folder? Or is there a much better way that I haven't considered?

From looking at the VS source side-by-side to the PU source in a visual diff/merge tool (diffuse, if you must know), it is clear that this should largely be possible. Sure, there are different factions, bases, fixers, probabilities and campaigns, but overall it seems like a lot of the code can be re-used unchanged, which also has the nice side-effect of giving the hypothetical PWCU network support from the get go.

If my understanding of the code etc. is not completely off, It should certainly be doable to port the existing PU assets largely unchanged to VS in the way I've tried to outline above? But perhaps there's something here that I don't know or haven't considered?

Re: Frankenstein’s Monster is Alive!!

Posted: Fri Aug 23, 2013 8:28 pm
by klauss
I think it could be possible, but it might be tricky, since you'd have to find the place to mess with sys.path that runs the earliest, before importing any of the overridden modules.

You can perhaps have the engine do this, but I'm not sure.

PU status update

Posted: Thu Sep 05, 2013 3:16 pm
by ermo
Just a quick note that I have completed the initial 'cleanup' of the 'pristine' (if one could ever call it that...) PU SVN r505 so that it works on Linux with the newest VS engine source. There were a variety of case-related issues and of course a few updates to the python scripts to use the newer VS iterator API.

I've previously played with travists's frankenstein mashup and my own PU-frankenstein, but both attempts have proved ... less than satisfactory for a variety of reasons. So knowing what I do now, I figure that cleaning up PU r505 and setting it up in a proper Git distributed version control system and then porting over the changes from my own PU-frankenstein as well as travists's WCU-PU-GG frankenstein might yield a better result.

Since it doesn't appear feasible to recover the contents of chuck's wcjunction SVN repo, I've not imported any SVN repo history. That means that PU r505 is essentially a 'black box' from my perspective, and I have no way of knowing why things are the way they are. On the flipside, that also means that I can change stuff as I see fit, I suppose... :D

Once I do some more code cleanup (primarily debug-instrumentation), I'll likely upload the project to Github so you guys can try it out as well. Right now, I don't know when that will be, but I aim for it to happen soon-ish.

Re: Frankenstein’s Monster is Alive!!

Posted: Thu Sep 05, 2013 11:34 pm
by pheonixstorm
I was planning on putting PPU up on the WCU project svn. Most of them are there already, and I have the last release of Chuck's work from wcjunction locally. Both the main line and the cubemap branch ;)

Maybe I should get around to cleaning up the WCU project a bit... If you have an sf.net account pm it to me and I can add you as a dev for that project if you want.

Re: Frankenstein’s Monster is Alive!!

Posted: Fri Sep 06, 2013 11:47 am
by ermo
pheonixstorm wrote:I was planning on putting PPU up on the WCU project svn. Most of them are there already, and I have the last release of Chuck's work from wcjunction locally. Both the main line and the cubemap branch ;)

Maybe I should get around to cleaning up the WCU project a bit... If you have an sf.net account pm it to me and I can add you as a dev for that project if you want.
You don't happen to have access to the SVN log history as well, do you?

In any case, I'm not too keen on using SVN. I understand that things might have changed, but last I worked with SVN, my impression was that branching (and especially merging) was hell. With git, branching/merging (think topic branches like "asset-fixes" or "python-fixes") is a core feature which works very well. Plus, you don't lose logs if a server goes down.

Anyway, I can see that sf.net now supports git 1.6.x (or possibly newer, if their documentation is not quite up to date). I'll send you my newly minted username in a PM. :D

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 8:05 pm
by ermo
A question about textures:

I have been playing with renaming assets from wrong extensions (JPGs named .png for example) to simply .image . For sprites and animations, this works well, because the images are referenced in sprite files and animation files. For shaders, it's a question of renaming the files in the shader configuration XML files as well.

However, asteroid bases apparently use a (hardcoded?) value which is Asteroid.bmp. Where can I change this? Is it referenced within a mesh file somewhere? Same thing goes for the computer-backgrounds in the base computer interface -- I would expect these to be configured in a .py script, but I haven't been able to grep my way to them. Does anyone happen to know where I should look?

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 8:10 pm
by klauss
ermo wrote:However, asteroid bases apparently use a (hardcoded?) value which is Asteroid.bmp. Where can I change this? Is it referenced within a mesh file somewhere? Same thing goes for the computer-backgrounds in the base computer interface -- I would expect these to be configured in a .py script, but I haven't been able to grep my way to them. Does anyone happen to know where I should look?
All meshes have (inside the bfxm) the reference to the texture file.

You have two ways of fixing the reference:

One, is converting from bfxm to xmesh, editing the xmesh, and then from xmesh back to bfxm. It's tricky when there are LODs or submeshes, so care must be had.

Two, is using a hex editor. Since png -> jpg is changing 3 bytes, you should be able to do this, but you'll have to spot the references inside the binary file.

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 9:20 pm
by ermo
klauss wrote:
ermo wrote:However, asteroid bases apparently use a (hardcoded?) value which is Asteroid.bmp. Where can I change this? Is it referenced within a mesh file somewhere? Same thing goes for the computer-backgrounds in the base computer interface -- I would expect these to be configured in a .py script, but I haven't been able to grep my way to them. Does anyone happen to know where I should look?
All meshes have (inside the bfxm) the reference to the texture file.

You have two ways of fixing the reference:

One, is converting from bfxm to xmesh, editing the xmesh, and then from xmesh back to bfxm. It's tricky when there are LODs or submeshes, so care must be had.

Two, is using a hex editor. Since png -> jpg is changing 3 bytes, you should be able to do this, but you'll have to spot the references inside the binary file.
Thanks for the answer. I can't help but think that it would be cool to have a simple/bulletproof way to do this, instead of what sounds like a fairly error prone manual conversion process?

In case you were wondering, the hex-edit option is not on the table as I'm changing the length of the extension as well. :)

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 9:43 pm
by klauss
Ah, you want .texture.

So yeah, there was the UnitConverter GUI, but I'm not sure it's easier. What i'd like is having material defs separate from the bfxm, we talked about this before, but never fleshed it out.

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 9:47 pm
by ermo
klauss wrote:Ah, you want .texture.

So yeah, there was the UnitConverter GUI, but I'm not sure it's easier. What i'd like is having material defs separate from the bfxm, we talked about this before, but never fleshed it out.
Oh, so the convention is that stuff referenced in meshes is called <whatever>.texture? I wasn't sure, but good to know.

Could you perhaps outline the VS data/ policy in this regard, so that I might use that in my PPU revival attempt? :)

EDIT: Ok, so anything that is referenced by a 3D object is .texture and will probably contain mipmaps. Anything 2D only (which doesn't need mipmaps) is .image. Makes sense.

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 10:44 pm
by ermo
Apparently, my imagination didn't stretch far enough: It turns out that a number of PNGs are hardcoded into the VS Source:

Code: Select all

[ermo@sheila vegastrike]$ find . -name '*.cpp' -exec grep -H -n '\.png' {} \;
./objconv/mesher/to_OgreMesh.cpp:560:                "\t\t\t\ttexture $(TEXTURE_DIF_FILE=white.png) $(TEXTURE_DIF_TYPE=2d)\n"
./objconv/starsystemgen/starsysgen.cpp:590:                names ).c_str(), entitytype == JUMP ? "jump.png" : s.c_str() );
./objconv/basemaker/base_maker.cpp:1340:            FILE *fp = fopen( (startdir+input+"_day.png").c_str(), "rb" );
./objconv/basemaker/base_maker.cpp:1355:            FILE *fp = fopen( (startdir+input+".png").c_str(), "rb" );
./src/star_system_xml.cpp:574:            string myfile( "planets/ring.png" );
./src/star_system_xml.cpp:777:            string myfile( "planets/Dirt_light.png" );
./src/star_system_xml.cpp:831:            string myfile( "sol/earthcloudmaptrans.png" );
./src/faction_util.cpp:36:            fac->logo = FactionUtil::createTexture( "white.png", true );
./src/options.cpp:289:    DefaultAtmosphereTexture = vs_config->getVariable( "galaxy", "DefaultAtmosphereTexture", "sol/earthcloudmaptrans.png" );
./src/options.cpp:295:    DefaultRingTexture       = vs_config->getVariable( "galaxy","DefaultRingTexture","planets/ring.pngwrapx36wrapy2" );
./src/gamemenu.cpp:273:    window()->setTexture( "basecomputer.png" );
./src/gamemenu.cpp:484:    window->setTexture( "basecomputer.png" );
./src/gui/modaldialog.cpp:77:    window->setTexture( "basecomputer.png" );
./src/gui/modaldialog.cpp:113:    window->setTexture( "basecomputer.png" );
./src/gui/modaldialog.cpp:163:    window->setTexture( "basecomputer.png" );
./src/gfx/screenshot.cpp:29:        std::string filename = "Screenshot"+XMLSupport::tostring( count )+".png";
./src/gfx/screenshot.cpp:33:                filename = "Screenshot"+XMLSupport::tostring( ++count )+".png";
./src/gfx/mesh_gfx.cpp:1298:                static Texture *white = new Texture( "white.png" );
./src/gfx/mesh_gfx.cpp:1573:    static Texture *black = new Texture( "blackclear.png" );
./src/gfx/nav/navcomputer.cpp:194:    window()->setTexture( "basecomputer.png" );
./src/gfx/nav/navcomputer.cpp:1050:    window->setTexture( "basecomputer.png" );
./src/galaxy_gen.cpp:354:        entity.push_back( "white_star.png" );
./src/galaxy_gen.cpp:705:    static bool usePNGFilename = (VSFileSystem::LookForFile( "jump.png", VSFileSystem::TextureFile ) <= VSFileSystem::Ok);
./src/galaxy_gen.cpp:706:    static const char *jumpFilename = usePNGFilename ? "jump.png" : "jump.texture";
./src/cmd/planet.cpp:64:    string     nam   = f.meshname+XMLSupport::tostring( count )+".png";
./src/cmd/basecomputer.cpp:744:        picture->setTexture( "blackclear.png" );
./src/cmd/basecomputer.cpp:879:        picture->setTexture( "blackclear.png" );
./src/cmd/basecomputer.cpp:1498:        picture->setTexture( "blackclear.png" );
./src/cmd/basecomputer.cpp:1608:    window()->setTexture( "basecomputer.png" );
./src/cmd/basecomputer.cpp:1658:            window()->setTexture( "basecomputer_cargo.png" );
./src/cmd/basecomputer.cpp:1660:            window()->setTexture( "basecomputer_missions.png" );
./src/cmd/basecomputer.cpp:1662:            window()->setTexture( "basecomputer_upgrade.png" );
./src/cmd/basecomputer.cpp:1664:            window()->setTexture( "basecomputer_ship_dealer.png" );
./src/cmd/basecomputer.cpp:1666:            window()->setTexture( "basecomputer_news.png" );
./src/cmd/basecomputer.cpp:1668:            window()->setTexture( "basecomputer_info.png" );
./src/cmd/basecomputer.cpp:1670:            window()->setTexture( "basecomputer_loadsave.png" );
./src/cmd/basecomputer.cpp:1672:            window()->setTexture( "basecomputer_network.png" );
./src/cmd/basecomputer.cpp:2345:            descimage->setTexture( "blackclear.png" );
./src/cmd/basecomputer.cpp:6012:    window->setTexture( "basecomputer.png" );
[ermo@sheila vegastrike]$ svn info
Path: .
Working Copy Root Path: /home/ermo/VegaStrike/trunk/vegastrike
URL: https://svn.code.sf.net/p/vegastrike/code/trunk/vegastrike
Repository Root: https://svn.code.sf.net/p/vegastrike/code
Repository UUID: 9476613a-4e0a-0410-bcee-947800e9c4d1
Revision: 13659
Node Kind: directory
Schedule: normal
Last Changed Author: pheonixstorm
Last Changed Rev: 13657
Last Changed Date: 2013-09-04 21:36:42 +0200 (Wed, 04 Sep 2013)

[ermo@sheila vegastrike]$ 
 
... yeah. Would it perhaps make sense to make at least some of these PNG files not be hardcoded and instead be configured in e.g. vegastrike.config?

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 11, 2013 11:32 pm
by klauss
It'd make sense. Patches welcome :)

Re: Frankenstein’s Monster is Alive!!

Posted: Thu Sep 12, 2013 5:16 am
by pheonixstorm
It would also makes sense not to use DDS so much for anything png. Most png -> dds conversions not only make the files larger but kill off some of the details :(

Re: Frankenstein’s Monster is Alive!!

Posted: Sun Sep 15, 2013 5:04 pm
by ermo
pheonixstorm wrote:It would also makes sense not to use DDS so much for anything png. Most png -> dds conversions not only make the files larger but kill off some of the details :(
I wasn't planning on converting stuff -- I'm just changing the file extensions to .image/.texture respectively, like in VS. :)

Re: Frankenstein’s Monster is Alive!!

Posted: Mon Sep 16, 2013 12:26 am
by ermo
Can someone help me understand why PU currently does not display 'shield lines' in the HUD when I target other ships? Where is this configured so that I might check what has gone wrong? When I target a ship, the targetting HUD only displays the unit outline (and armor damage shows up fine), but I can't visually check the shield status of the target...

EDIT: I guess I'm looking for the "Shield Manifest" stuff in the .cpt files as seen here: http://wiki.vega-strike.org/HowTo:Edit_ ... ile_format ?

EDIT2: PU disabled the following config options (likely originally per klauss' comments below, but the sprites don't work / are not present / have been wrongly named / I inadvertedly nuked them / make up your own reason / etc.)

Code: Select all

<color name="outer_shield_color" r="0.98823" g="0.30588" b="0" a="1"/>
<color name="middle_shield_color" r="0.98823" g="0.70588" b="0" a="1"/>
<color name="inner_shield_color" r="0.988235" g="0.70588" b="0" a="1"/>
I'll re-enable them for now in PU, until I figure out what happened to the stuff that was likely supposed to be shown instead...

EDIT3: No such luck. Hm. Maybe I'm just too tired at this point. I'd better leave it for now and review it another day...

Re: Frankenstein’s Monster is Alive!!

Posted: Mon Sep 16, 2013 6:53 pm
by klauss
AFAIK, there's a series of config options to tweak the appearance of the VDUs, and Privateer-like mods tend to disable those lines in order to provide custom images for them (through cockpit files, using special sprites that "slice in").

Re: Frankenstein’s Monster is Alive!!

Posted: Tue Sep 17, 2013 9:36 pm
by ermo
klauss wrote:AFAIK, there's a series of config options to tweak the appearance of the VDUs, and Privateer-like mods tend to disable those lines in order to provide custom images for them (through cockpit files, using special sprites that "slice in").
I just checked what VS does, and in PU, there is no indication that the same approach has been taken. I also tried copying in the sprites + hud images from GG, and when I use those, not even the white stripe I outlined in red in the image above shows up.

I also tried firing up GG, and the HUD target shield lines display fine there with the same config parameters turned on and on the same VS engine version. I wonder what the heck is messing up the HUD target shield display functionality in (my version of) PU?!

Privateer: Wing Commander Universe WiP on github

Posted: Wed Sep 25, 2013 5:10 pm
by ermo
I just uploaded my in-development repo based on PPU SVN r505 to github. Before you murder me for not using SVN like you're used to, the rationale is simple: Git keeps history in each clone. Had PPU been hosted with Git instead of SVN, we'd have had history in every clone. Instead, we have no PPU history right now, which is sad. Also, github now has Windows support and Git automatically converts line-endings between Linux/Mac/Windows formats.

I have not tested PWCU with Windows yet, so it may or may not work with the VS windows binaries. Please note that the current copy is plain PPU -- no WCU data (systems etc.) has been ported over.

Here's the link: https://github.com/ermo/privateer_wcu

I maintain it on Fedora 19, if that makes any difference.

Re: Frankenstein’s Monster is Alive!!

Posted: Wed Sep 25, 2013 6:47 pm
by pheonixstorm
505 was the cubemaps branch so it will work with the latest binary. Or did last I checked

Priv:WCU status update

Posted: Wed Oct 09, 2013 6:30 pm
by ermo
At the moment, I'm working on the ship_upgrade.py script responsible for upgrading opponents. From what I can tell, it needs a little bit of love and some Priv-specific tuning. Presently, ships can be upgraded beyond their class (light/medium/heavy) willy-nilly, which makes some of the missions much harder than they should be, so I'm going to try to fix that.

I've also fiddled with the config file a fair bit, trying to make the setup options correspond better with the VS setup options, as well as ensuring that the config file was actually used instead of various built-in VS engine defaults.

Priv:WCU status update

Posted: Mon Oct 14, 2013 8:35 am
by ermo
*phew*

It turns out that the code that calls the ship upgrade routine prior to launching opponents would never actually use 'non-blank' ships -- that is, ships that do not end in '.blank' in units.csv. Non-blank ships are the canonical ships, in that they're equipped with the appropriate reactors, shields, guns and missiles -- in the other WC games, they would represent 'known quantities'. Blank ships, on the other hand, would be upgraded on the fly with little regard for their actual class (A Demon Light Fighter with heavy reactor and shields? Sure thing).

That in turn meant that the code which was dealing with whether factions would have exclusively 'non-blank' ships or a mix of 'non-blank' and '.blank' ships or even only '.blank' ships, was never respected.

My current thinking is to base the ship upgrade routines around the 'non-blank' ships and outfit the '.blank' ships with upgrades/downgrades relative to their respective 'non-blank' ships, based on the difficulty level. The difficulty level is apparently dynamic and depends on the worth of the missions you're currently undertaking.

In my design notes, I'm using the tiers 'Rabble' (opponent is outfitted with lower-than-spec parts), 'Average' (opponent is outfitted with spec parts -- i.e. the 'non-blank' version), 'Experienced' (opponent has 1st level ECM and plasteel armor, and might have a better radar and AI) and 'Hardcore' (oppenent has 2nd level ECM and tungsten armor, and might have a better radar and AI). There's apparently also a correlation between difficulty and the number of enemies spawned as well (perhaps unsurprisingly), so I'll have to ensure that I use a probability distribution which favors the 'Rabble' and 'Average' tiers over the 'Experienced' and especially the 'Hardcore' tiers somehow.

The overarching goal, of course, is to avoid having the ship upgrade routine unbalance the game, which is sadly currently the case (especially in some of the 3rd party mini-campaigns). Instead, ships should have a particular flavour about them, yet present enough variety so as to not become 100% predictable.

Re: Frankenstein’s Monster is Alive!!

Posted: Mon Oct 14, 2013 6:05 pm
by loki1950
Glad you found that I think that issue was introduced by someone who had a poor understanding of Python :wink: :roll:

Enjoy the Choice :)

Priv:WCU Status Update

Posted: Thu Oct 17, 2013 11:33 am
by ermo
I've committed a bunch of python changes made over the past couple of weeks, which are mainly related to the ship upgrade issue in my last post, but some of it is also general debug instrumentation for my own benefit.

During my playtesting, I've noticed that the Ferret models appear to crash the game (segmentation fault) when I buy them and subsequently visit either the ship upgrade showroom or the landing pad. If I save the game, quit and then start and load the same game, the ferret shows up fine in the landing pad initially.

Anyway, it would seem that the random encounter routine still sometimes result in .blank ships, so I'm going to investigate what causes that. While I can appreciate that variety is indeed the spice of life, and that having ship upgrade variability is a boon to replay value, I would prefer if the upgrade process was a bit saner at least. :mrgreen:

GitHub repo: https://github.com/ermo/privateer_wcu

Priv:WCU Status Update

Posted: Sat Oct 26, 2013 1:53 am
by ermo
I'm working on getting a Windows build up and running, but haven't had much luck using the stock VS windows build so far.

Stay tuned is all I can say for now...