New Trail Effects

[Hammish]

Sooooo... I finally got BTC updated in terms of skills to be loadable, and I noticed that the trail effects seem to be handled completely differently now.  Is there a global setting for things like the decay on particle effects for trails that I can tune back down to the original level, or can you offer some pointers on how to adjust the new values and what they represent?

Just curious as to if you have a straight conversion number (seems to be about 80x longer decay, give or take) and if I need to modify every single engine trail or not.

[ai_enabled]

Hello!
We've added a second, much longer trail, which is configured automatically based on the properties of the main trail defined in XML. You could switch trails length in the video options ("short" setting means old behavior without the second trail).
For visual consistency we didn't added any properties to modify the length of the second trail in XML. You could change it together with look of the primary trail by modifying <particle_lifetime>.
Also <particle_speed> is now overridden to 0 value for forward engines active mod. Otherwise the second trail could not be in sync with the primary trail.
So you don't need to modify anything in your XML trails definitions if them looks good. The players who don't like long trails will simply go to video options and make them short as they were before.
Regards!

[Hammish]

I guess what I'm looking for is a way to force a revision to the old system within a mod; as it stands right now anyone with medium or long trails enabled will find BTC completely unplayable, given how long the trails end up persisting on some weapon shots.  (Seriously, the screen looks like I'm playing with 80s vector graphics, and the engine rapidly lags out.)

So, any way to do this, or is it now hard-coded into the UI?  If it'd help, I could post an experimental version of my current version (actually loads with the newest VE) and you could see the effect and possible alter pointers.  If not, and if the trails are always going to be modified by the engine going forward, it seems like BTC may be DOA.

[ai_enabled]

We had very tight time frame to make v1.4 (it took considerably much more time than we excepted), so we hardcoded the coefficients for secondary trail right into the engine and thought it will work fine for most mods as well. Of course we could move it to the trail XML definition with the next patch if you wish it .

As the temporary solution you could decrease overall trail length by lowering <particle_lifetime> value. This value is multiplied on some hardcoded coefficient and used as particle lifetime for the secondary (long) trail. If you set it around 0.5, then long trail will live around 15 seconds on "long" trail length setting. So for 0.25 it will give you 7.5 seconds I think. However the result may look not so nice as it was before v1.4.
Also the <particle_count> value is multiplied on another coefficient for the secondary trail, so if you set it too high (>300) the secondary trail may appear too bright.

Regards!

[Hammish]

Right, lowering the lifetime is what I tried doing originally; the issue with it, at least for weapons effects, seems to be that if I set it low enough to be workable with 'long' trails, then it has almost no trail at all when they are set to 'short'.

What I think I'll do is tinker with them to make them slightly shorter, since I'm adjusting them to make use of new 3D projectiles that Flessen whipped up anyway, so that they look nice at short-length, okay at medium-length, but are unplayable at long-length... and then just warn people in the mod setup that they need to set it to short or medium.

If you do tinker with it in the future, though, it sounds like it'd be a LOT of work to add an extra variable to every single trail just for the secondary coefficient.  Would it be possible instead to just save the desired trail length option in a brand-new XML included with core.cpk?  Something like trail_attributes.xml, and inside you just have three coefficient settings for long, medium, short.  Change the formula in the engine so that it retrieves the coefficient from that file instead of using raw values, using the field for the current options setting, and voila!  It'd even have the benefit of not breaking existing mods, because if someone hasn't updated and included a new version of their .mpk with new coefficients, it'll just use the default values from .cpk.

[ai_enabled]

Oops) we've already done what I've described above - and we just pushed v1.4.8 to Steam and uploading it to our website.
After downloading, please have a look on trail_engine_hull_shuttle.xml
there are a few new parameters starting on <long_trail_***> which are optional - if they're missing, the game will automatically calculate everything as it done now.

So you could now specify <long_trail_particle_lifetime> parameter to achieve desiring effect. You could even set all parameters to zero if you don't want to have any long trails for this type of trail (so it will look same as it was before v1.4).

BTW, please note that the particles count for long trail should be quite low (around 25-35) otherwise they will be very bright and use extra performance on rendering. If you set this value too low, then the trail will appear not smooth (player will be able to see individual particles when closeup the camera). If you want them to look smooth, set particles count to 25-35 and regulate alpha to achieve desired brightness.

Regards!

[Hammish]

Awesome!  That'll work too, I don't have /that/ many additional trails to work with, even in BTC, since a lot of the effects share trails that are just scaled.   I just didn't want to break any existing systems, but you mentioned that if the new values are absent it just uses the existing system... so, hooray for legacy support.

I'll take a look at my particle count as well, I never really messed around with it all that much, but quite a few of them are set way higher than what you mentioned, probably because all the original trails from way back when, when I first stated working on the mod, were very short and thus the count didn't matter much.  I'll tinker a bit now that I know the system will be great going forward.

Thanks as always for being so responsive, this is a project I love and folks on Steam seem to be keen on getting a fresh version of it, from the messages I get.

OH.  Totally off-topic but pertaining to modding as well: does AT have any issues with us tweaking existing models as well as skins, if we're using them in mods?  I should have asked before I did my work on the dedicated carrier I have coming up but it totally slipped my mind.  (I basically took the missile cruiser, stripped the launchers off the sides and then gave it a custom skin that makes it look like it has flight decks on three locations.)  I know everyone seemed cool with reskins on stuff, wasn't sure if it applied to modeling as well.

[Lurler]

OH.  Totally off-topic but pertaining to modding as well: does AT have any issues with us tweaking existing models as well as skins, if we're using them in mods?

Not at all, as long as it is a mod for VE feel free to use any of the existing assets

[Hammish]

Awesome!  And yeah, it totally is.  If I was ever going to use something of someone's outside of their product I'd make -sure- to ask first.  My wife is a lawyer, she'd smack me around even if I wasn't an honorable, dutiful sort.

I'll be sure to post a screenshot when I have a moment, too.  I actually love how it turned out, with the flight deck along the underside it reminds me a lot of the TCS Tiger's Claw from the old Wing Commander games.  It's just lacking the heavy guns on smaller outrigger wings.

[Hammish]

Quickie question:

When getting BTC up to shape today I noticed that there seems to be a new projectile type: #4, bullet.  Or maybe it's not new and I just never noticed it existed.   What's the diff between type-1 (direct hit) and type-4 (bullet)?

[ai_enabled]

Hammish, we've separated missiles and bullets, otherwise we were unable to separate AI weapon usage for different weapons types (AI will fire bullets more often than missiles now, previously it uses the same setting for both types).

[Hammish]

Ahhh, okay.  So the projectile type just feeds into the AI script in terms of how often it checks to see if it should fire/refire?  That's actually quite handy since my mod has a few rapid-fire weapons that were previously unsuitable for pirates given how long they took between shots.

[Hammish]

Another quick trails question as well, and then an unrelated follow-up:

The values for long_trail_x, are those then added to the base trail stats if trail is set to long?  And how does that affect medium trails?  I figured it might be something like:
short trails = regular trail_ attribute
medium trails = regular trail_ attribute + 50% of long_trail_attribute
long trails = regular trail_ attribute + 100% of long_trail.

Second question: the skill to raise consumable effect, that should work in conjunction with repair modules as well, yeah?  Since they actually start the same buff name on the ship, I figured.  My question would be if they also affect repair beams, and if the buff affects outgoing heals, incoming heals, or both.  I figured it'd be incoming only (if I have +consumable repair skill and someone else heals me, I get a bonus since the buff is on my ship), but I figured it was also worth an ask.