[StratComm]

Or the prefered method, replacing the map with a fully transparent 1x1 dds or tga map.  There are (albeit rare) instances where the green transparency rule doesn't apply, and nameplates really should be done with transparency rather than 0,255,0 interpretation anyway.

[Vasudan Admiral]

The idea of renaming it to "Nameplate" was so peeps could easily recognise and change it to whatever pre-made nameplate they wanted in Fred via the texture replacement, be it a puregreen mapped one, or preferably, an alpha transparent tga/dds version.

What happened with the old fenris in the media VP was that the actual nameplate itself "GTC_Orff.pcx" was replaced with a 1x1 map, which isn't helpful, since not only do people have no idea what resolution to make their custom nameplates to prevent stretching, but the nameplate texture for everyone was "GTC_Orff", but blank. :\

[karajorma]

I thought the green transparancy thing only went wrong when someone did something like colour reduction and it ended up not being (0,255,0).

Where else can it go wrong?

[StratComm]

It's rare, but at least in some implimentations that's a transformation handled by the graphics card.  I don't think it's even really an issue now, but there are certain setups (hardware setups) where pure green would come out pure green, not transparent.

[.::Tin Can::.]

Fan-han-han-tastic.

I forgot that Freespace 2 could look this good with just a bit of hard work put in by the good folks here at HLP.

Fantastic.

[taylor]

The green->transparent thing only works for ANI, PCX & 16-bit TGA files.  It's totally ignored for 32-bit TGA, DDS and JPG images.  32-bit TGA and DDS have true alpha support so that's what you have to use there.  JPG doesn't have alpha support but it probably won't ever give you pure green anyway due to compression artifacts so it saves load time by never doing the green conversion.  Also the green to transparency conversion is done in software during load of the image (when converted from 8-bit to 16-bit) so there is nothing hardware or system dependent about it.  As long as pixel(s) is pure green (0, 255, 0) and 8-bit PCX it will always be made transparent.

[StratComm]

Well that clarifies a misconception I've held then.  I could have sworn that there were instances where some people got pure green transparency and others didn't on the same maps, but maybe that's from a different game.

[ChronoReverse]

Not knocking the beautiful work on the Aoelus but is it just me but is a section of the texture seemingly of lower resolution to the rest of the textures?  I just find it's a harsh contrast to the ultra sharp textures for the rest of the ship

[Vasudan Admiral]

If you mean how 'even' the resolution distribution over the models surface area is (uneven would cause a low-res look on some parts) then it shouldn't really be a problem - everywhere gets approximately even res with a few small exceptions.

If you're refering to the texture itself (probably the blueish armour platings on the sides right?) then you're right, but there's not much I can do to change that annoyingly enough.
The tiled sections like that one were made with Lighty's upgraded versions of those original maps, and while they're bigger, sharper and better than the originals, they still were'nt quite high-res enough to match the area they have in the actual texture.

To improve upon that I'd have to redraw each hull plate on every part where it's used, and the difference probably wouldn't be worth it.

[Jetmech Jr.]

D/Led the Triton, and it's telling me that one of the subsystems (Turret 1, I believe) is missing from the model, causing it to crash.

Nm, it's not your fault, VA. It's the SCP build. D'oh!

[StratComm]

Originally posted by Jetmech Jr.
D/Led the Triton, and it's telling me that one of the subsystems (Turret 1, I believe) is missing from the model, causing it to crash.

Nm, it's not your fault, VA. It's the SCP build. D'oh!

Yeah, the turret names are a bit messed up.  The base objects should have "-base" removed from their names.

I'll check the other two while I'm at it.

EDIT: The other two are fine.  The catch is that some SCP builds are sensitive to the mess after a dash for subsystem names, while others are not.  Of course, the build your using probably didn't throw the error but the Triton probably has no working turrets.  It should be fixed, regardless.

[Galemp]

Since this thread has already been bumped, I'll just announce that anyone interested in the high-poly Hecate mapping should drop by the FS Upgrade forum.

[Vasudan Admiral]

Errr, that is a really weird bug. :\ Might it have something to do with the code that checks for "-destroyed"?

[StratComm]

Yeah, probably.  The old version of Styxx's plugin were notorious for oddities if turrets weren't renamed.  But as it stands, the tables and the POF don't agree on the turret name so the game doesn't make the turret active.  I've PM'd WMC, so hopefully the version in the 3.6.7 media VPs will have this minor detail fixed.

[Vasudan Admiral]

Just tested, and both turrets work fine in-game, even though the tables aren't looking for the correct names - which is probably why it escaped my bug-hunting. :\
Perhaps most builds ignore anything after a dash unless it's "-destroyed", but the occasional build won't?

[StratComm]

Maybe, what build are you using?  I get the feeling it's dependent on something else (though I have no idea what)

[Vasudan Admiral]

Ack, it worked perfectly under "fs2_open_366spec.exe", which is where I'd done all my testing. Only just now got around to testing it in the latest CVS build, and it didn't work. No crash, but the turrets were inactive.

Don'cha just hate it when things like this manage to slip by?

[redmenace]

does anyone have fighter06-02b.pcx?

[StratComm]

It's in mv_models.

[redmenace]

Nevermind, GalEmp helped me out. Turned out the copy I had was a 24bit pcx file. I just converted to TGA.