FACTIONALIZING EXISTING SHIPS

Post by **jackS** » Sun Aug 27, 2006 8:31 pm

Oblivion wrote:Hellloooo!

anybody there. lol

Need to know the correct naming standards so I won;t have to redo most of the work.

I'm guessing it's all in underslashes. Howver do I retain the dash for the spr files?

i mean

admonisher-hud.png? and admonisher-hud.spr

or admonisher_hud.png? and admonisher.hud.spr?

you don't need to worry too much about about the base names that you're defining and that are linked in the bfxm or in units.csv - the engine does a search for FACTIONNAME_basename for the relevant types of files.

geoscope · Post by **geoscope** » Sun Aug 27, 2006 8:35 pm

jackS wrote:@geoscope - why did you delete and recommit the clydesdale shield file? There should have been no changes required to that, unless you were simply renaming it to change the plurality expressed in the name ?

Still a bit of a newb to svn, yes, I was changing the plurality... I thought it was a mistake, that I'd missed when reanming to meet convention. All other shield files are singular... but after commitng, (stupid me) I started up VS, and found it wouldn't load, and that clydesdale_shields.bfxm was right. So back we went.

Also, the factions that the game understands are those declared in factions.xml - currently, factions.xml contains the following factions, along with a couple other special purpose factions, like "upgrades".

Mmm, I've going to have to change the kkl'k to kklk then for quite a few files... damn.

Post by **jackS** » Sun Aug 27, 2006 9:02 pm

@geoscope - the clydesdale mesh you committed is b0rken.

I am rolling it back.

You can immediately see from the file size that it's wrong - I'm thinking Oblivion added the LODs as top level meshes.

geoscope · Post by **geoscope** » Sun Aug 27, 2006 9:16 pm

Argh. I've renamed the rest. I think I've got them all... getting tired.

Post by **jackS** » Sun Aug 27, 2006 9:22 pm

From looking at the size, admonisher mesh also appears to be improperly constructed. I am checking all of the other meshes now.

The only thing that should have changed is the addition/alteration of a couple of strings, but I'm seeing significant file size increases that lead me to believe that LODs were improperly linked in as top level meshes, or some equivalent problem.

Also seeing a problem with the Aevant --> Areus conversion... this would appear to be endemic. I will look over the rest of the files, and continue editing this post.

Edit(s): Nicander also looks b0rken, as does the Ariston.

geoscope · Post by **geoscope** » Sun Aug 27, 2006 9:27 pm

Well, that one I'm not taking the blame for that one. I'm not a graphic artist... had no idea what size those files ought to be either. I wasn't even sure they had to be commited, I thought it was just the pngs and jpgs that were needing update, and only included the mesh, because they were in the archives I downloaded...

EDIT: I thought that the mesh file just had numerical data, for vertices and such. Anyway, now that I finished with the merchant_guild and klkk variants that needed renaming one more time, I'm not doing any more changes today, I need sleep... and I'm just likely to make more mistakes if I do anything else.

Post by **jackS** » Sun Aug 27, 2006 10:05 pm

geoscope wrote:Well, that one I'm not taking the blame for that one. I'm not a graphic artist... had no idea what size those files ought to be either. I wasn't even sure they had to be commited, I thought it was just the pngs and jpgs that were needing update, and only included the mesh, because they were in the archives I downloaded...

EDIT: I thought that the mesh file just had numerical data, for vertices and such. Anyway, now that I finished with the merchant_guild and klkk variants that needed renaming one more time, I'm not doing any more changes today, I need sleep... and I'm just likely to make more mistakes if I do anything else.

Not your fault, and there's no need to ponder "blame" - this is clearly accidental, and will be fixed. Re: file sizes, it's not how big the files should be, it's how big they should be vs. how big they were (i.e. the only difference should be the addition of a few strings, hence, a few bytes of difference in file size, whereas I'm seeing files that are nearly 1.3-1.5 times as big as they were before - hence my assumption that the LODs were appended as top level meshes - I'll see if that was indeed the case when I break them apart and try to rebuild them.)

The mesh files needed to be regenerated so as to point to the damage and glow maps that Oblivion made, because they didn't have them before.

Get some sleep - working tired is rarely a grand idea :-/.

I'll see if I have time to rebuild fixed BFXMs and commit them. I'll save doing any key changes until the content seems to be in a more stable state.

Post by **jackS** » Sun Aug 27, 2006 10:28 pm

I've confirmed that it is indeed an inclusion of LODs as top level meshes.

Compare:

08/27/2006 02:25 PM 508,296 0_1.xmesh
08/27/2006 02:25 PM 159,006 0_2.xmesh
08/27/2006 02:25 PM 57,468 1_0.xmesh
08/27/2006 02:25 PM 17,755 1_1.xmesh
08/27/2006 02:25 PM 5,217 1_2.xmesh
08/27/2006 02:25 PM 1,353,250 aevant.xmesh

to:

08/27/2006 02:22 PM 508,318 0_1.xmesh
08/27/2006 02:22 PM 159,015 0_2.xmesh
08/27/2006 02:22 PM 508,318 1_0.xmesh
08/27/2006 02:22 PM 159,015 2_0.xmesh
08/27/2006 02:22 PM 57,542 3_0.xmesh
08/27/2006 02:22 PM 17,829 3_1.xmesh
08/27/2006 02:22 PM 5,291 3_2.xmesh
08/27/2006 02:22 PM 17,829 4_0.xmesh
08/27/2006 02:22 PM 5,291 5_0.xmesh
08/27/2006 02:22 PM 1,353,268 areus.xmesh

The good news is that it's not hard (if a bit tedious) to put the models back together properly.

Will post more when actual progress has been made to that end.

Post by **jackS** » Sun Aug 27, 2006 11:06 pm

Admonisher directory checked in.

Will proceed in alphabetical order.

Edit: DOH!

Looks like I spoke a little too soon - further testing on the admonisher revealed that none of the .spr files actually referenced the correct hud images (because all of the hud images had been renamed, but the .spr files hadn't been changed to reflect this). This is probably endemic also, but even easier to fix.

Should have caught that before posting. Am clearly not being thorough enough in testing.

Must train harder.

---------

Additional note - the text on the Purist version of the Admonisher is backwards on one of the two sides.

Post by **jackS** » Mon Aug 28, 2006 2:53 am

Well, that took a bit.

I've fixed the broken meshes (everything with LODs was b0rked).

I've fixed the .spr files (almost all were in an inconsistent state)

I've tested these fixes for each of the vessels, for each of the factional variants provided.

I've updated units.csv (having different stats for different factional variants will eventuallyt be very desireable, but I'd like to not put them in until we have firmer stats for the base variants so as to reduce copy-paste errors)

I've committed these changes to SVN.

Additionally - for future reference to all who're interested in such things, do not attempt to change the keyname for "eject". It's hardcoded into the engine. Remember, every time you try to change a hardcoded string, a Shaper euthanizes a one-eyed kitten... or something like that. ("pilot" in the MPL is also hardcoded).

After dinner, I'll go through the python scripts to reference the Aeran ships that were renamed so that the new, damage-map-enabled content loads, instead of ... nothing at all loading. I will also go through all of the mission files, and change references, where they exist, for the benefit of those devels who use such files (like me).

-------

Other things of note (at least to my addled excuse for a mind)-

The Clydesdale is really shiny - can't figure out exactly why yet. I'll investigate further after more pressing things (units not loading due to renaming) have been addressed.

Text use, such as "Confed" on the Schroedinger and "PASN" often results in the presence of backwards text strings when a reflected piece of the texture is used on a symmetric portion of the vessel. This appears suboptimal. (Also, as noted, "Confed" on the Clyde is not properly oriented). Additionally, "Confed" probably isn't the best text string to be sticking on a military vessel - it's a bit informal "CIW" (Confederation of Inhabited Worlds, as per the mostly :-/ up to date dynamic_news_content.py) followed by a model number (to be made up at artist's discretion)

@Oblivion - Matte is good (shiny is strange for most things

) , but you seem to have washed out a lot of detail in your PPL files that was present in H.E.Day's original PPL files, where they existed - was this intentional? Likewise as a further (and future) efficiency optimization, if you are going to use the same specularPPL file contents for multiple faction variants, then you can save video memory by having both of them use the same specularPPL file (especially if you do it in B/W vs. color).

okiedoke - that's it for the moment. off to dinner.

Post by **jackS** » Mon Aug 28, 2006 4:59 am

So, for future reference, the only python file you should probably have to change when altering a key value for a ship should be faction_ships.py (although it never hurts to grep for other references)

The mission files.... well, they're a motley bunch, many of which time and consistency has forgotten about. It'd be nice if things were changed for them too, but the only folks using those files are almost certainly developers who are capable of doing it for themselves, so... less pressing. I've updated some of the commonly used testing missions, but I've left the others as-is for the moment, even if they have aeons and aelars in them, as they often have other relics of times and names gone by (and will happily wait a bit before being deleted, expunged, or updated).

----

Some more thoughts -

Aliasing effects on the Dostoevsky texture are actually fairly noticeable.
On a purely aesthetic note for that texture - is it just me, or would some extension of color towards parts of the rear be perhaps warranted? Not mine to decide, but it does come to mind.
One more thing of note on the Dostoevsky - if one looks at an Andolian or Klk'k Dostoevsky from the side, the gap in coloration between top and bottom is somewhat interesting.

so.. Woot. A fair chunk of content has been added, albeit not without some crankiness and likely further toiling before it's all settled.

(now to go see what's been polishing the Clydesdale to a mirror finish...)

Post by **jackS** » Mon Aug 28, 2006 6:36 am

also, as an FYI for anyone noting that key values have changed - yes, this makes your savegames unhappy.

geoscope · Post by **geoscope** » Mon Aug 28, 2006 7:19 am

Which were why the units keynames hadn't already changed even when the units in-game names had... but with VS 0.5 release coming up, it makes sense to pull that band-aid off quickly. Players can always edit their savegames, if they don't want to start over. Perhaps someone could also write a savegame update script to search/replace the keynames, such that all a player had to do was run the script, and optionally, provide the script their savegame directory as a commandline argument. Better yet, could that be incorporated in the save/load functions of the game? -- that is, have it look for outdated keys and call a function to update them as a game is loaded?

Oblivion · Post by **Oblivion** » Thu Aug 31, 2006 4:29 am

@geoscope: I'm REALLY sorry.

I did say TEST not COMMIT.

I realized my mistake just yesterday while testing them myself. With appending LODS among the top-level meshes. Thanks for the clarification JackS.

anyway, I've renamed some files, redid some maps. (Don't take them as final. I'm still tweaking what colors and patterns suit best.)

that is, have it look for outdated keys and call a function to update them as a game is loaded?

that would be good. but anyway, if someone really wants to port previous savegames, they could just rename the reference files. I've also editted my own units. csv at home and tested the ships. Not so much problems so far. I'll be uploading my editted units.csv along with finalized textures and meshfiles, it would only require cut and pasting or somesuch.

I'll be correcting some typos like why hyena is not Hyena. And things like that (adding descriptions too, a bit

, will be subjected to JackS' scrutiny later on).

areus_shield.bfxm, dostoevsky_shield.bfxm, ejectpod_shield.bfxm, gawain_shield.bfxm, nicander_shield.bfxm, sartre_shield.bfxm, schroedinger_shield.bfxm.... those ships never had them, still don't.

not my work.

but maybe in the future if I have some spare time. Anyway, shields will not be affected in any way with what I am doing now.

@JackS:

I've fixed the broken meshes (everything with LODs was b0rked).

okay, thanks. I'll fix the bfxm's back home myself as I add textures for the ships.

I've fixed the .spr files (almost all were in an inconsistent state)

All sprite files, textures and etc. are now properly linked in the new files I'll be uploading later. although PPL and GLo maps which are identical are still referenced separately for each faction, just so it could easily be editted later on.

Since matte is alright, I'll change this so PPL and GLO maps will be shared by all ships.

I've now stuck to the naming standards:

e.g. pirates_admonisher.png

I've found the faction names in the faction.xml file, still ahve some gripes with it tho - later...

Text use, such as "Confed" on the Schroedinger and "PASN"

will refrain from doing that from now on unless they will not be spelled out backwards (possible on some ships), i'll be restricting most text to capital ships and will follow the naming standards of the faction subgroups (in the ships.psf), i.e. highborn navy capships will feature the Ranks of Lords or something...

.

Additionally - for future reference to all who're interested in such things, do not attempt to change the keyname for "eject"

sorry.

Well just rename the texture files then. don't include the mesh files.

but you seem to have washed out a lot of detail in your PPL files that was present in H.E.Day's original PPL files, where they existed

i've backed up the files, HED's ppl really mas the ships shiny, which I don't like, though I'm not changing the PPL maps for alien ships. For humans however, I'm deleting all features in teh background and just leave the cockpits and windows shiny. If the ship has no windows then it will have no ppl. IS this alright?

Not your fault, and there's no need to ponder "blame" - this is clearly accidental

it's MINE MINE MINE!!!

*leaps off cliff edge*

Okay that's it. Will start posting some of the problems I had and the files with WARNINGS now.

Oblivion · Post by **Oblivion** » Thu Aug 31, 2006 5:35 am

A - target vertices appear not to have alpha maps or any map at all?? Any ideas what causes this? I editted the obj files directly from bfxm. So basically it's bfxm>obj>bfxm. I left the links to to blink.ani alone but this still happened... *sigh* and this is supposed to have the pirate texture.

B - hud images, good to go!

some complaints tho: the engine is suppose to convert the first letter of the faction to upper case... why is "klkk" still "klkk" and not "Klkk"?

And why are the ship names' first letters not in upper case also?

C - factional textures are kicking in!

A klkk dosty up close. Note textures are still WIP.

D - yep they are. the hyena don't look as bad as it did with the un-UVmapped spots texture... you got to admit it looks mighty delicious now.

E - two dosties. hey, why do flightgroups tend to be composed of the same ships?

F - ach.. mesh problems again. mesh doubling, right? and does the schroedinger thruster really look like this? it seems to be missing a the x and z planes? will edit the bfxm to stop the lods from being loaded too.

G - badass pink bubblegum bolts! take that! (who gets to pick the weapon colors? lol) close-up of the target vertices show that they do have textures, but the wrong ones and without alpha. I'm guessing this is a problem with blink.ani itself and not on the mesh?

H - looks bad. looks very very bad. THAT is why you should not use spec functions on every texture . Just because we can don't mean we must use it all the time.

I - some problems with the dosty; and caught it while trying to dock too! is this some primitive AI in action or a freak accident? It actually entered the fighter base then flew away again. anyway, found the reason - typo..

instead of "dostoevsky", wrote it "doestoevsky"... darn those long russian names.

note that the PPL and GLO maps are working.

J - tinkerbell with some fairy dust. what is this? it's supposed to be damage right? why BLUE? and why so wide an area?

some eye candy things. A pirate fleet:
THIS is what flightgroups should look like. (might be useful for splash screens later on)

Oblivion · Post by **Oblivion** » Thu Aug 31, 2006 6:21 am

The files:

NOTE: DON'T COMMIT THESE YET

Just for your perusal.

Will be making major changes on these files again. The old files are now changed too. See hud images for reference. if nothing else, the new hud images would be a good enough contribution. lol

aliasing will be dealt with in the future textures.

AREUS:

http://www.freefileupload.net/file.php? ... /areus.rar

ARISTON:

http://www.freefileupload.net/file.php? ... riston.rar

DOSTOEVSKY:

http://www.freefileupload.net/file.php? ... oevsky.rar

EJECT:

http://www.freefileupload.net/file.php? ... ectpod.rar

HIDALGO:

http://www.freefileupload.net/file.php? ... idalgo.rar

HYENA:

http://www.freefileupload.net/file.php? ... /hyena.rar

KIERKEGAARD:

http://www.freefileupload.net/file.php? ... egaard.rar

LANCELOT:

http://www.freefileupload.net/file.php? ... ncelot.rar

NICANDER:

http://www.freefileupload.net/file.php? ... cander.rar

SCHROEDINGER:

http://www.freefileupload.net/file.php? ... dinger.rar

that's everything FOR NOW.

Kangaroo · Post by **Kangaroo** » Thu Aug 31, 2006 7:25 am

Fantastic!

hmm... Could the conversion from bfxm to obj double anything?

wait.

Try this: convert schroedinger to obj and rename the old bfxm to anything else. Then tweak the obj and make the new bfxm.

Just my guess.

If I'm right, this should fix the doubling.

about the alpha maps: definetly something's wrong with the bfxm. Any chance that you misspelled anything there?

You da man, Oblivion!

geoscope · Post by **geoscope** » Thu Aug 31, 2006 7:45 am

@Oblivion: PM me to let me know when you are happy with what you have and think the packages are ready for inclusion, and I'll get them into svn. I won't jump the gun again, without giving them a test or two.

Zeog · Post by **Zeog** » Thu Aug 31, 2006 9:32 am

@geoscope: Please make sure that when changing the master_part_list.csv there aren't any quotation marks added to the keys and blank lines are not filled with commas. (Please confer the comment of revision 10570 if you haven't already: http://svn.sourceforge.net/viewvc/vegas ... v?view=log )

geoscope · Post by **geoscope** » Thu Aug 31, 2006 11:38 am

@Zeog: That was Open Office.. frigging spreadsheet program wants to quote ALL text string fields, which for our purposes is every field. Sorry I didn't catch that when saving. I've given up on using oOo for csv files. Still making slow progress on my editor, in the mean time, I'll use GAlex's.

Zeog · Post by **Zeog** » Thu Aug 31, 2006 12:58 pm

@geoscope: Yeah, oO is a pain when it comes to editing the csv files. I think there is an option when importing from csv that strings should or should not be enclosed within quotation marks. I have given up on using it though because I have a localized version that messes up with commas and points for decimals. It then interprets every number with a decimal point as a date and adds a year. I'm now using a text editor... that works perfectly if you don't want to balance the dataset and need the speadsheet layout. Have to give that csv editor a try, though.

Cockroach · Post by **Cockroach** » Thu Aug 31, 2006 5:20 pm

sweet....any plans for old-school noseart?

Post by **klauss** » Fri Sep 01, 2006 4:22 pm

Cool stuff.

BTW, Mesher's obj->bfxm->obj doesn't properly handle .ani files.
I might fix that this weekend.

Oblivion · Post by **Oblivion** » Mon Sep 04, 2006 5:40 am

@Kangaroo

Try this: convert schroedinger to obj and rename the old bfxm to anything else. Then tweak the obj and make the new bfxm.

nope, that's what's causing it. It's better to probably reconvert them to xmesh than directly to objects. that way, I can discriminate between hi-levels and lods easily.

no worries, I think I got it now. will still ahve to see them work ingame tho.

still don't know what caused the alpha map failure. Might be a mispelling. I'll be having to reconvert them anyway, so haven't looked at it yet.

@geoscope:

sorry again bout dat.

will do. thanks.

@cockroach:

wish I could..

would certainly look better. but it won't do to have the whole darn confed admonisher fleet to sport only one playboy girl on the nose, now would it. lol

they'd probably shoot each other from jealousy. If someone can provide the infrastructure for procedurally assigned maps, maybe we could do a bit of noseart on our ships. but not for now.

anyway, we're also restricted by the map size, you can't draw a cabaret dancer on a 30x30 pixel box without reducing her to a smudge of pink.

@Klauss:

that the reason for the ani failure? okay. thanks!

going back to the old bfxm>xmesh>bfxm workflow looks better, I guess. tho it's harder work.

still have no updates (got busy with two other models) but befor eth week is done, you'll be flying in style, which means either better style or worse..

Howard Day · Post by **Howard Day** » Tue Sep 12, 2006 6:11 am

Wow, this is impressive. I'm kinda shocked that you guys are still working from my designs. To be honest, I would had hoped that you'd have moved on to something....better.