F35 Lightning II - JSF

[cdn_biggdogg 29]

I'm not a modeler but here's what I found:

Quote[/b] ]Add UV map to all the model parts

and this:

Quote[/b] ]well, to check what faces causes that error, go to structure-->check faces.

if there are some faces not UV mapped, in the named selection window will appear the selection "* Cannot generate ST coordinates". Click on it, some faces will be selected. go to UV map button, and then click in this window the button "planar mapping".

usually that error comes up in GEO-FIRE GEO-VIEW GEO-SHADOWVOLUME LODS cause when you detect components, or Convex the model, UV maps are destroyed.

Hope this helps!

[.kju 3245]

binarize the addon or is it already?

[Panda-PL- 0]

Eble.....you've done some nice work but with almost all OFP conversions I've saw all have one thing in common and that is they generate errors such as this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Warning: rkt_f35\rkt_jsf_usn_mesh.p3d:1 Error while trying to generate ST for points: 1848, 1837, 1849

It doesn't say error. It says warning.  

We have had these discussions before: this warning means there is a face too small to calculate (normal or mapping, can't recall). look at your model ingame and if it doesn't show: leave it as it is, perhabs be more carefull next time you model not to triangulate in wrong way faces that have 3 points aligned in line, which is the common cause.

Warnings are OK, leave it (unless it shows ingame on the model).

[[aps]gnat 28]

@CDN_BiggDogg

The ST Warnings won't bring the Server to its knees, its more likely the Afterburner or FX scripts are.

[cdn_biggdogg 29]

@[APS]Gnat

We're using the Su33 Addon with the afterburner and vapor effects without issue so I can't see it being a problem.

It's been our experience that addons generating the ST errors do eventually cause the server to become unstable and unplayable or crash it completely. Once we removed them or updated them to fixed versions the missions are more stable.

[Guest RKSL-Rock]

@[APS]Gnat

We're using the Su33 Addon with the afterburner and vapor effects without issue so I can't see it being a problem.

It's been our experience that addons generating the ST errors do eventually cause the server to become unstable and unplayable or crash it completely. Once we removed them or updated them to fixed versions the missions are more stable.

Its not exactly the errors themselves its the fact that it continually writes to the error log that causes the drop in performance.  Add 10 clients all reporting the same error and you start to build up "lag".

The ST errors themselves are caused by "stretched textures".  There are usually found on faces where the mapping is badly or incorrectly done.  You'll see alot of these errors in OFP ports because of the Planar mapping method we all used to use in OFP days.

You have a choice:

a) Fix them by remapping the faces causing the errors.

Or

b) Ignore them and binarise them.  The game will stop reporting them then.

ST errors are only a problem when you use normal maps and some RVMAT shaders.  Incorrect mapping will "drive the game engine nuts" trying to draw the faces properly and cause serious performance problems in most cases, eating up GPU a lot of cycles trying to draw something it just cant do.

Its always better to fix the problems than ignore them in my book.

[[aps]gnat 28]

We're using the Su33 Addon with the afterburner and vapor effects without issue so I can't see it being a problem.

Well ...... the Su33 is also full of ST errors ..... so are they really the issue?

I'm fairly sure Southy's implementation of the FX scripts on the F35 are not the same as the Su33, so the problem possibly lays in the difference.

[cdn_biggdogg 29]

Quote[/b] ]Well ...... the Su33 is also full of ST errors ..... so are they really the issue?

I'm fairly sure Southy's implementation of the FX scripts on the F35 are not the same as the Su33, so the problem possibly lays in the difference.

We're using the latest release of the SU33 and it's not reporting any ST errors in the server.rpt.

We're at the point that we test any new addon and if we see it generating the ST errors then we just don't include it. You might get away with one or two on a server but it's just downhill after that. I believe RockofSL to be right when he says it's not the error but the reporting of it! Makes sense!

So to clear it up I'm not saying that the F35 is causing lag because we're not running it. I'm just stating that the ST errors need to be fixed one way or another if possible. As a server admin to a coop 20 man server, we're not too concerned about errors that pop up once and don't interfere with any other part of the mission but the errors that constantly generate over and over are a problem such as the ST errors!

[eble 3]

The first release of the F35 is not binarized, that will come with the next beta version.

The main reason I didn't binarize the pbo was I wanted people to able to take the F35 apart and have a look at various aspects of what I'd done.

It was only when footmunch released the F16 un-binarized that I was able to take the first steps in conversions.

I'm hoping that will fix the problem, the FX scripts are different to the Su33 but really only in minor ways and the activation method.

Cheers Southy

[[aps]gnat 28]

b) Ignore them and binarise them.  The game will stop reporting them then.

The first release of the F35 is not binarized, that will come with the next beta version.

Theres the answer.

[modemmaik 53]

The ST errors themselves are caused by "stretched textures".  There are usually found on faces where the mapping is badly or incorrectly done.  You'll see alot of these errors in OFP ports because of the Planar mapping method we all used to use in OFP days.

You have a choice:

a) Fix them by remapping the faces causing the errors.

Or

b) Ignore them and binarise them.  The game will stop reporting them then.

ST errors are only a problem when you use normal maps and some RVMAT shaders.  Incorrect mapping will "drive the game engine nuts" trying to draw the faces properly and cause serious performance problems in most cases, eating up GPU a lot of cycles trying to draw something it just cant do.

Its always better to fix the problems than ignore them in my book.

I usually map the ST-reported faces to another sum-texture, having a matching unique color. I also remove materials from faces mapped to this texture.

This way, the GPU does not try to shade etc. the incorrect faces.

But to be honest: I have not detected any issue weather I remap them or binarize them. But remapping does not take much time an I am able to detect, which faces are streched in the model. Usually they look a bit strange in game, because they have only a "stripe" pattern on it, which belongs to the hand full of texture bits used to color those faces.

[ricnunes 0]

However I have one problem to report regarding specifically the VTOL version of the F-35, the F-35B and the problem is that it's possible to take off vertically with the aircraft but it's impossible to land vertically (a thing which should be much "easier") with the F-35B. The problem seems to be related to the fact that when we select the "auto-hover" option the aircraft starts almost imediatly to take off even if the throttle is totally cut back which shouldn't IMO happen - For example it doesn't happen with BIS Harrier. The F-35B should only take off vertically (with "auto-hover" on) when the player applies the throttle.

This is due to the ArmA engine - currently, the 'autohover' action on the fixed-wing jets points the jet thrust downwards, and permanently sets the throttle at a set value. in the ArmA harrier, this is set so the aircraft slowly descends, and it seems southy has set it so the F-35 slowly climbs. unfortunately there is NO way to directly control the throttle to climb/descend in this mode, and the player can only descend if they point the nose downwards and 'trick' the game engine into cutting the throttle for you.

given this limitation, personally, I think it would be better if it handled in autohover mode in the same fashion as the harrier - as in it should slowly descend in the hover as opposed to climb. it seems odd that I can take off vertically with a full warload, but then have to land either conventionally or in a real awkward 'forward crab' motion at the end of a mission.

Roger on the problem Hailstorm!

And I completly agree with your oppinion that is better to have a solution similar to the Harrier (no VTOL) and a much better vertical landing than what we have now afterall it's much easier to land vertically and to takeoff vertically even in the F-35B.

I also liked the Pyroflash solution of using afterburner (even if the real F-35B doesn't use afterburner during verical takeoffs) and if this solution is possible to implement it would definitly be a solution for this problem.

[ricnunes 0]

One more thing (perhaps a bit of nickpicking on my side) about this F-35 JSF addon:

- Did you know that the F-35B and the F-35C (the carrier variant) don't have internal cannons. They can only carry cannons when fitted thru external cannon pods.

Only the F-35A carries an internal cannon!

And I think that BIS is doing the exact same mistake as in this addon in ArmA2 (they seem to be fitting an internal cannon in their F-35B).

[hailstorm 4]

in regards to the whole F-35 hover discussion, this i found interesting... maybe southy you can get permission to incorporate this VTOL system into the F-35. haven't tried it myself, but it looks promising.

[pyroflash 5]

the only way an F-35B can take off with even a slight warload is to use afterburner. the only reason it doesn't use it in RL is because it melts the Carrier deck.

As for the cannon. The F-35B/C models can both use cannons, but they have to be mounted directly aft of the Lift fan and under the weapons bay. I believe the ammo is also carried externally via ammunition pods, but i could be wrong about that.

[hailstorm 4]

PyroFlash, this is just my personal thoughts, but I find it hard to believe a pilot would even consider using the AB while the aircraft is hovering - I'm just thinking about the systems and physics involved AFAIK, the F-35B uses two systems to hover, the main engine, with the nozzle at the back pointed down, and a vertical lift fan just behind the cockpit that provides an equal amount of thrust to support the front half of the jet, which is powered by the main engine drive shaft. If you muse that the jet uses afterburner in this configuration, wouldn't that only increase the thrust out of the rear engine only? AB by itself increases thrust, but not engine power/engine RPM - thus I can't see how the vertical lift fan can somehow get more power to compensate, resulting in the whole jet unbalancing and going arse-over-tit? I haven't seen any documentation that says AB is used, although I haven't seen any testing of an aircraft with a full warload either, so any documentation to prove either way would be interesting.

[NoRailgunner 0]

The F-35B's system generates more than 40,000 pounds of lifting force. More tests + flights must have been done before the F- 35 enters operation in 2013.

STOVL Propulsion Ground Test

[ricnunes 0]

A few considerations about the F-35:

Like I previously said the F-35B and F-35C don't carry an internal gun, but can carry for some missions a gun fitted in an external pod which is fitted or pluged in a centerline pylon position under the aircraft belly which means than in those variants (F-35B and F-35C) the gun is in fact an external weapon which it isn't always carried and when carried the fired rounds come from below and not from the left side like in the F-35A.

In real life the F-35A which have an internal gun carries 180 rounds of ammo while the gun pod fitted in the F-35B and F-35C carries 220 rounds of ammo and not 300 like in the Addon and as far as I can tell as in ArmA2.

And yes, the ammo in the gun pod (F-35B and F-35C) is carried inside the gun pod (externally to the aircraft). Here's an interesting site that shows (bottom part) how the gun pod "works":

http://www.aerospaceweb.org/question/planes/q0163.shtml

Regading the F-35B and again in real life, NO afterburner is used when the aircraft is in VTOL mode, the F-35B while landing or taking off vertically can't use its afterburner. I don't believe that the reason for this is because it "cooks" the aircraft carrier's deck or something like that. I believe that the reason for this is due to the fact that the main engine exaust nozzle is vectored in a 90 degree down position which makes impractical the use of the afterburner since for example this would most probably cook the main engine exaust nozzle.

I also believe in HailStorm point that an afterburner would unbalance the lift between the main engine and the lift fan.

But neverthless and while it's not realistic to have afterburner while in "VTOL mode", using afterburner while in "Auto-Hover" in the F-35 addon would IMO be an interesting idea in order to solve/overcome the problem that exists in ArmA when modeling VTOL operations.

[pyroflash 5]

No, the F-35B can use its afterburner during VTOL operations, but the problem is that it does melt the runway surface. The F-35B cannot however use the full extent of its afterburner in VTOL mode, it can only use its first stage of afterburner.

[eble 3]

I thought I would give a quick update as to where I am with beta 2,  I have slightly altered the model of the F35C navy version(USN) to reflect the larger control areas, at first glance it looks the same but the main wings/elevators are about 10% bigger.

I have been playing around with the flight model for the vtol, increasing weights etc, as it stands at the moment, I’d prefer to leave it as per the original i.e allowing vtol without scripts.  (Aircraft can takeoff  vertical, and land with a slight forward movement of 18knts, with the increased weight it will decrease height quicker) still looking at this tho, so it might change again for beta 2

Afterburner now toned down, I have looked at applying the afterburner to the vtol operation but the way this is scripted it provides forward motion and it isn’t associated with the angle of the engine exhaust, without extensive re-scripting this isn’t going to be a viable option (unless someone wants to script it)

USAF version fixed now showing correct roundel

now XEH compatible thanks to william1

I’m aware the F35B/C do not have an internal guns, I’ll look at adding the external gun pods (if anyone has reference photos of the pods attached to the F35 that would help)

Still to do – Damage textures/improved shadows.

Binarise pbo,

Southy

[Guest RKSL-Rock]

No, the F-35B can use its afterburner during VTOL operations, but the problem is that it does melt the runway surface. The F-35B cannot however use the full extent of its afterburner in VTOL mode, it can only use its first stage of afterburner.

What are you basing that on?  Considering the thrust rating of both the Lift fan and the main engine with and without after burner I find that claim to be very improbable. As someone else has already said, it would result in a thrust imbalance and destabilize the hover.  Which would mean in a violent nose dive.  

Quote[/b] ]The Pratt & Whitney F135 engine, which produces about 28,000 pounds of thrust in military power and 40,000 pounds of thrust in afterburner…

You have to remember the lift fan can only generate so much lift and it doesn’t have an afterburner itself.   So that would be upto a 12,000 pound difference forcing the tail up and over the nose. So I really cant see it myself.

[ricnunes 0]

No, the F-35B can use its afterburner during VTOL operations, but the problem is that it does melt the runway surface. The F-35B cannot however use the full extent of its afterburner in VTOL mode, it can only use its first stage of afterburner.

Oh yeah? Like RockofSL previously said, in which base you make that claim?

Anyway, in the following site from globalsecurity (which by the way is a quite reliable source of information):

http://www.globalsecurity.org/military/systems/aircraft/f-35-specs.htm

You can clearly read in the "F-35B PROPULSION - Vertical Thrust (STOVL)" part that the lift is:

"39,700 lb

After burner not used in

STOVL mode. Shaft-driven lift

fan augments engine’s lifting force."

I think this clearly dismisses the "mith" that the F-35B can in real life use afterburner during STOVL/VTOL.

[ricnunes 0]

I’m aware the F35B/C do not have an internal guns, I’ll look at adding the external gun pods (if anyone has reference photos of the pods attached to the F35 that would help)

Unfortunally I don't have and I couldn't find a photo of a F-35B/C with a gunpod attached.

The only image of the gunpod that I've found was in this site (in the bottom) that I've already posted in a previous post:

http://www.aerospaceweb.org/question/planes/q0163.shtml

I think that the image in that site may be enough to build an aproximate model of the gunpod for the F-35.

It is known that the F-35B/C gunpod will be attached in a centerline position below the aircraft's belly and the exact position where the gunpod will be attached in the aircraft will be between the 2 internal weapons bay.

[pyroflash 5]

It can use its afterburner, doesn't mean it does IRL. plus, would still be a useful game mechanic even if it is not used IRL.

[eble 3]

Being Christmas and all, I've gone back and given the F35 a once over and made a beta 2.

addon now includes:

F35C variant with larger wings/control areas (will install hook for final version)

Binarized PBO (should fix all errors)

Animated canopy

new canopy glass textures

revised rvmats/spec maps (now not so super shiny)

change flight model (more in line with other aircraft addons)

toned down afterburner included spearate sound (tweaked for multiplay)

sonic boom with sound @ 855(audible on the ground)

lots of little tweaks

The F35 still is capable of VTOL from standstill, for the final release I will probably change this to mirror the harriers handling.

Have fun all

Southy

Updating the front page but in the mean time you can download it here:

removed to correct errors