Hard Light Productions Forums
Hosted Projects - FS2 Required => Frontlines => Topic started by: Black Wolf on March 16, 2017, 10:05:00 am
-
RELEASED! See below. Link. (http://www.hard-light.net/forums/index.php?topic=93336.msg1845259#msg1845259)
Been working on and off on this one for awhile. Diffuse map is now done (though the AO bake is still yet to be added)! Glow and shine shouldn't take too long, nor glow, but making LoDs and Debris will be a few days at best.
This thing is designed to be around 450m long - large by cruiser standards, but less powerful and with less endurance (i.e. ammunition for its missile turrets). They're meant to be patrol vessels - if you come across a situation you can't handle, you have the tools to defend yourself with your missiles and fighters, and tie down your enemies with your railguns while heavier help is scrambled through subspace.
The idea is that these are a significantly older design than the Fenris or the Titans, hence the different engines, and the fact that the engines are so far back on the model - the idea is that they emit dangerous radiation, so they have to be a certain distance from the crew when in use. Later in the war, the GTA will improve their engine design, and the Jupiters will be refit, filling in the space between the engines and the main hull. This will allow two things - a little bit more energy, allowing plasma turrets (then brand new tech) to be mounted, but primarily it will allow a lot more space for the crew - these things are really unpleasant to serve on - people, machines and ammunition are all packed together far tighter than on a Fenris or a Titan, making them very unpopular assignments.
Obviously, the model is very heavily inspired by Aldo's Piranha Cutter, and the Fenris-esque retexture that was done for Inferno, but it's not really a HTL of either model - its much bigger, and the fighterbay is new.
As usual with Frontlines stuff, as soon as it's finished it will be released. The Mk 2 variant isn't required for the current Frontlines campaign, but it will be eventually, so I'll get around to it before too long... hopefully.
[EDIT]Oh, the funky stretched UV map on the side will be a nameplate in the final model, but P3d only allows one texture unless you pay. Probably should have deleted the poly, but no big deal.
-
Update: The LoDs and debris are finished, the model is ingame and looking good. I've noticed some minor UV tweaks that need to be made, and there's still tabling to do, but broadly speaking it works, it shoots, all is well.
Unfortunately, I built this thing with call bad information. 100% my own fault, of course - I built it on the assumption that two key elements to make the rear fins work right were in the engine (look_at functionality and an animation trigger that works when a ship is moving, and not just when it's using an afterburner), but it turns out I should have done my research before I started, because that functionality doesn't currently exist. I've made some inquiries about how likely it is to get added in to the engine, but I'm uncomfortable releasing this without the functionality (or with the full functionality, but before the engine has it). For now, while I wait to see how that plays out, this one might have to remain unreleased - for a little while anyway. If it looks like the functionality I need isn;t going to be added in a timely fashion, I'll do a stripped down build and get it released that way.
-
A script could trigger the animation whenever the speed of the ship goes above a certain threshold. I think that could work around the engine limitation until that is implemented.
-
If you're familiar with animation code, this script should help you out (adapted from my own engine glow manager (http://www.hard-light.net/forums/index.php?topic=93171.0;topicseen)):
#Conditional Hooks
$Application: FS2_Open
$On Game Init: [
JupiterFinCache = {}
FIN_ACTIVE_THRESHOLD = .01
JUPITER = "GTFg Jupiter" --change this if you rename the ship!
]
$On Mission Start: [
JupiterFinCache = {}
]
$State: GS_STATE_GAME_PLAY
$On Frame: [
local numShips = #mn.Ships
for i=1, numShips do
local ship = mn.Ships[i]
if ship:isValid() then
if ship.Class.Name == JUPITER then
local signature = ship:getSignature()
local thrust = ship.Physics.ForwardThrust
local engines = (thrust > FIN_ACTIVE_THRESHOLD)
if engines ~= (JupiterFinCache[signature] or false) then
ship:triggerAnimation("scripted", 0, engines)
JupiterFinCache[signature] = engines
end
end
end
end
]
#End
-
If you're familiar with animation code, this script should help you out (adapted from my own engine glow manager (http://www.hard-light.net/forums/index.php?topic=93171.0;topicseen)):
#Conditional Hooks
$Application: FS2_Open
$On Game Init: [
JupiterFinCache = {}
FIN_ACTIVE_THRESHOLD = .01
JUPITER = "GTFg Jupiter" --change this if you rename the ship!
]
$On Mission Start: [
JupiterFinCache = {}
]
$State: GS_STATE_GAME_PLAY
$On Frame: [
local numShips = #mn.Ships
for i=1, numShips do
local ship = mn.Ships[i]
if ship:isValid() then
if ship.Class.Name == JUPITER then
local signature = ship:getSignature()
local thrust = ship.Physics.ForwardThrust
local engines = (thrust > FIN_ACTIVE_THRESHOLD)
if engines ~= (JupiterFinCache[signature] or false) then
ship:triggerAnimation("scripted", 0, engines)
JupiterFinCache[signature] = engines
end
end
end
end
]
#End
I'm not 100% sure how to implement scripting, but if this works, that would be brilliant - I could scotch the hydraulic rams for this release if need be.
-
If I've done it right, it should just be a matter of saving that as jupiter-sct.tbm and setting up the animation in your table and POF. Look at the Albanus if you need guidance.
Actually, come to think of it, I could test it with the Albanus. I'll add that to my to-do list for tomorrow.
-
It does indeed work, but it doesn't reset when the ship isn't moving (I've added the "reset when idle" flag to no effect). Is that expected behaviour? I'm not very well versed at all in scripting, but my reading of the script suggests that there's no way to make it work backwards at this point.
When it moves though, it looks great, exactly as I wanted. If I could get it to reset, then I could definitely release it sans hydraulics, and hold off on the final version of the model until after look_at gets re-implemented.
-
It does indeed work, but it doesn't reset when the ship isn't moving (I've added the "reset when idle" flag to no effect). Is that expected behaviour? I'm not very well versed at all in scripting, but my reading of the script suggests that there's no way to make it work backwards at this point.
It's supposed to play the animation backwards when the ship stops moving; that's what the "engines" variable is for in this call:
ship:triggerAnimation("scripted", 0, engines)
The fact that it isn't reversing would be a bug (although whether it's a bug with the animation system, the Lua interface, or the script itself is an open question).
-
That's exactly right. The final parameter to ship:triggerEngines indicates whether to play the animation forwards (true) or backwards (false... which, come to think of it, is ironically backwards itself, but whatever), and the engines variable is set based on whether the ship's thruster is active or not.
I guess we'll know more once I get a chance to test it myself. The script is nearly identical to my engine glow manager, which I know works properly, so I think it's a bug in the animation system and/or the Lua API. I've got some workarounds to try out if so.
UPDATE: Okay, I got in a test with an Albanus, and saw the desired behavior (the Albanus' pods flipped down when it was moving and reverted when it wasn't). I've attached my test case. Open up 0.fs2 in the tech room, flip on the third-person camera, and watch your own ship as you activate and deactivate your thrusters.
BW, can you post up the ships.tbl data for the relevant subsystems? The PCS subobject data couldn't hurt, either. Alternatively, it may be a versioning issue; I'm working on 3.7.4 here.
[attachment stolen by Russian hackers]
-
UPDATE: Okay, I got in a test with an Albanus, and saw the desired behavior (the Albanus' pods flipped down when it was moving and reverted when it wasn't). BW, can you post up the ships.tbl data for the relevant subsystems? The PCS subobject data couldn't hurt, either. Alternatively, it may be a versioning issue; I'm working on 3.7.4 here.
Ah, yes, the one possibility I didn't think of: it could also be bad data. :P
-
Hey, the script got it working! :) This is great. :)
-
Niiiiiiiiiice. Out of curiosity, do you mind me asking what you changed?
-
Niiiiiiiiiice. Out of curiosity, do you mind me asking what you changed?
I had my fin submodels set up flat, as per the p3d model, and an initial triggered animation to get them to start at the 30 degree level. So, the first time they moved, they'd go back to the flat planes, and then there was nowhere for them to revert to, since they were already there. I changed all the submodels to default to the 30 degree angle, and it all works now.
Makes sense when you think about it, but I'd not been. :)
-
(http://i.imgur.com/8eJaVNl.jpg)
With thanks to Xenocartographer for the scripting assistance, the Jupiter now basically works as intended. The hydraulics don't work, so they've been removed until look_at is brought back into the engine, but while they;re a nice piece of detail, the rest works pretty well. So, in keeping with the standard policy, here it is!
Release Link: https://www.mediafire.com/?79bhndmgb0mhebk
With well over a decade of active service to date, the Jupiter class frigate represents the apex of a previous generation of shipbuilding philosophy and technology within the Galactic Terran Alliance. Until the development of the Fenris cruiser, the Jupiter was the most powerful ship in the fleet, and even today, its twin forward railguns and heavy missiles make it a threat to any Vasudan ship it may encounter.
The primary mission of the Jupiter has always been long-range patrol, and its armament and design reflect that fact. It carries consumables for months of operation without restocking, and can adequately defend itself against threats both large and small. However, it small hangar, and complement of Comet class shuttles and Leto-I interceptors, grant the Jupiter enormous tactical flexibility, and Jupiters are therefore called on to perform a wide array of tasks in the modern fleet, including search and rescue, fleet support, high priority intersystem transportation
As valuable – indeed, essential – as these vessels are to the Terran fleet, there is no denying that the c lass is showing its age. Its engines are a generation behind modern standards, and must emit an unacceptably high level of dangerous radiation to move the massive frame of the Jupiter, necessitating their positioning far back from inhabited parts of the ship. Thus, while the Jupiter is significantly longer than a Fenris, available internal space is broadly comparable, and habitable internal space is significantly lower. Combined with the need to store ammunition for an entirely projectile based armament, supplies for several months of independent operations, and a small fighter wing, space for the crew is extremely limited, and service aboard a Jupiter is considered far more challenging than service on almost any other class of vessel.
To address these problems, fleet command is planning an extensive refit to bring the Jupiters up to modern standards. But with the first tranche of these refits not scheduled until mid next year, it expected that the current iteration of the Jupiter will be remaining in service for the immediate future.
(http://i.imgur.com/rAASip3.jpg)
A few little notes. Obviously, it's balanced for the early TV war, so don't drop it into a post-Capella battlefield and expect it not to get blown away. Secondly, it turned out a little bigger than I originally thought - about 515m long, so some of the scale on the windows and such is a little ownky. Try not to think about it! :p
-
A Vidar?
Wait, what? It's not Vidar :D! It's something much cooler! Looks like one of the first big ships hummanity ever launched. Love the triple main cannons and oddly-placed hangarbay.
-
A Vidar?
Wait, what? It's not Vidar :D! It's something much cooler! Looks like one of the first big ships hummanity ever launched. Love the triple main cannons and oddly-placed hangarbay.
Thanks, glad that the old school look is coming through. :) I'm pretty happy with how this one turned out, lost hydraulics notwithstanding.
-
Sorry for the Necro,
But I found a little bug in the model: the turret data for Turret03a is attached to the wrong subobject (detail0 instead turret03a-arm) in the download. Simple fix, easily homemade.
But if you want it I can give you the edited .pof.
(I use it now as the Fafnir-class "blockade enforcement" ship)
-
Thanks for posting that fix. It was causing the ship to become non-collidable when that turret was destroyed.
-
:yes: :yes: :yes:
-
We're using this model in SR and stumbled upon a few bugs which we managed to solve. Judging from the comments I see here, it appears that some of the issues were known and some were even fixed a couple of years ago at least, which makes me think that we may have installed an old version of the model. In any case, we'll take a look.