Home Fries

TAW 2.0 Known Issues and Bug Reports

529 posts in this topic

Yes I have. Not sure what to do about it, though.

Hey HomeFries,

I did notice this problem as well, however during the weekend I have decide to install the baseline 2.01 version instead of using the patch (forgetting to save my progress btw ;-() and the problem seems to have disappeared ...

On the note: The only difference between this install and the previous ones is the fact that i didn't reinstall the c++ libraries and the codec.

Hope this can give some hints.

Again Thanks for the great work !!

My Rig:

Mobo - ASUS P5N72-T Premium

Cpu - INTEL Q9550 2,8 Mhz

SoundCard - SupremeFX II

Graphic - XFX Nvidia GeForce GTX 280

Memory - DDR2 Kingston HyperX 4GB

OS - Vista 64 Ultimate

Matteo

Share this post


Link to post
Share on other sites
Hey HomeFries,

I did notice this problem as well, however during the weekend I have decide to install the baseline 2.01 version instead of using the patch (forgetting to save my progress btw ;-() and the problem seems to have disappeared ...

On the note: The only difference between this install and the previous ones is the fact that i didn't reinstall the c++ libraries and the codec.

Hope this can give some hints.

Again Thanks for the great work !!

My Rig:

Mobo - ASUS P5N72-T Premium

Cpu - INTEL Q9550 2,8 Mhz

SoundCard - SupremeFX II

Graphic - XFX Nvidia GeForce GTX 280

Memory - DDR2 Kingston HyperX 4GB

OS - Vista 64 Ultimate

Matteo

Matteo,

Interesting find. I have done the same (i.e. I have done all combinations of installs on my rigs, and I haven't been able to get rid of the problem on a consistent basis (i.e. sometimes it's there, but most of the time it isn't).

So far as backing up your pilots, all the full install does is overwrite your players.lst; your original pilot is still in the players folder. Check the section in the TAW 2.0 Manual Addendum (or at the top of this thread, for that matter) regarding backing up and restoring pilots for more information.

Share this post


Link to post
Share on other sites
Matteo,

Interesting find. I have done the same (i.e. I have done all combinations of installs on my rigs, and I haven't been able to get rid of the problem on a consistent basis (i.e. sometimes it's there, but most of the time it isn't).

So far as backing up your pilots, all the full install does is overwrite your players.lst; your original pilot is still in the players folder. Check the section in the TAW 2.0 Manual Addendum (or at the top of this thread, for that matter) regarding backing up and restoring pilots for more information.

Hey guys,

I actually took a quick look at this sound issue, even going as far a disabling hardware acceleration on my sound card. The one relatively consistent thing I noticed, was that if you have a whole lot of objects in the air at the time you launch rockets or missiles, the higher the probability of the sound cracking up. I haven't tried using compatibility options on the exe itself yet. I might give that a whirl. But my guess is its the limitation of the sound engine (not engine sound, k?) being used by TAW.

Share this post


Link to post
Share on other sites
Hey guys,

I actually took a quick look at this sound issue, even going as far a disabling hardware acceleration on my sound card. The one relatively consistent thing I noticed, was that if you have a whole lot of objects in the air at the time you launch rockets or missiles, the higher the probability of the sound cracking up. I haven't tried using compatibility options on the exe itself yet. I might give that a whirl. But my guess is its the limitation of the sound engine (not engine sound, k?) being used by TAW.

This was my guess as well. Having the files extracted (and therefore larger) may also have something to do with it.

Share this post


Link to post
Share on other sites

Hey Home Fries a lil 2.01 bug with the Graphics?? I was flying the AWACS Kill mission and the time was about 3AM in the morning and when I reached around 26300 it was getting what appeared at first a Black and white picture, but the higher I got it just turned into a Night Vision clolor pallete but I did not enable Night Vision..

I went down below 26300 the normal night color came back but above 26300 it started to change. here is a screenshot Sorry only got 1 screenshot but you should get the idea:

f22nv.jpg

By the_nephilim at 2009-10-06

It was with the Full moon but the moon was small??

Share this post


Link to post
Share on other sites
Hey Home Fries a lil 2.01 bug with the Graphics?? I was flying the AWACS Kill mission and the time was about 3AM in the morning and when I reached around 26300 it was getting what appeared at first a Black and white picture, but the higher I got it just turned into a Night Vision clolor pallete but I did not enable Night Vision..

I went down below 26300 the normal night color came back but above 26300 it started to change. here is a screenshot Sorry only got 1 screenshot but you should get the idea:

It was with the Full moon but the moon was small??

Neph,

Have you been able to duplicate this condition after reloading TAW (including exiting out of the launch menu) and/or rebooting your PC? I ask because I have not been able to duplicate this with either dgVoodoo (DX9) or Zeckensack's wrapper, both starting with a moonlit night and starting with a moonless night and switching to a moonlit night using NVGTool.

In the 2.0 version of redmoon.txt, the transition altitude between palettes is 25000 and 28000 (moonpal ends at 28000 and al2_moon begins at 25000). 26300 is right near the middle, so if this problem persists it may be a bad al2_moon.col file. Reinstalling 2.01 may fix the problem (you won't be able to see the problem in D3D, so testing it here is a non-starter).

Just how small was the moon? I shrunk the size of the moon in 2.0 to about 1/5 of its original size for a more realistic look; is it smaller than that?

Share this post


Link to post
Share on other sites

I am really happy that TAW is being worked on again.

There is an old bug of TAW still present in TAW 2.0 which is that free fall bombs land ALWAYS way short of the target unless delivered in steep dive. This could either be the result of slightly wrong math for the calculation of the bombing reticle on the screen or a discrepancy between the math for the actual bomb fall and the HUD math.

Anyhow, this can be easily verified by flying eg. the training mission Bomb BAI - one has to just keep flying straight towards the town and drop a bomb with the marker somewhere inside the town area. The bombs will fall at least a whole mile short - it is really that bad. I hope that nobody tries to argue that you have to be fly lower or be in a steeper dive. I have flown pretty much all simulations out there (Jane's, F4, LOMAC) - the bombing marker in all of them works like it should.

Would be great if somebody could have a look at the source code and find what's broken...

Share this post


Link to post
Share on other sites
I am really happy that TAW is being worked on again.

There is an old bug of TAW still present in TAW 2.0 which is that free fall bombs land ALWAYS way short of the target unless delivered in steep dive. This could either be the result of slightly wrong math for the calculation of the bombing reticle on the screen or a discrepancy between the math for the actual bomb fall and the HUD math.

Anyhow, this can be easily verified by flying eg. the training mission Bomb BAI - one has to just keep flying straight towards the town and drop a bomb with the marker somewhere inside the town area. The bombs will fall at least a whole mile short - it is really that bad. I hope that nobody tries to argue that you have to be fly lower or be in a steeper dive. I have flown pretty much all simulations out there (Jane's, F4, LOMAC) - the bombing marker in all of them works like it should.

Would be great if somebody could have a look at the source code and find what's broken...

Hi there Traz,

I'm sorry to break this to you, but unfortunately nobody except the authors have access to the long desired source code, so problems with flight models and weapon physics, and bugs in the graphics engine have long been accepted as non-issues.

Regarding how TAW simulates dumb bomb release, the targeting reticle for dumb bombs and rockets more closely simulates CCIP rather than CCRP which is normally selectable in other study sims. CCRP in TAW is primarily used by precision bombs - specifically the GBU-24 and JDAM.

It takes a lot of practice to drop dumb bombs in TAW, since it also models the ballistics for dumb bombs. That means if you release at a relatively high altitude at level flight, the bomb will initially take a horizontal path but eventually start dropping vertically. Personally, I usually pickle a couple from 2000ft at around -10 to -15 pitch and it's worked pretty well for me.

Hope this helps relieve your frustration a bit. :thumbsup:

Cheers!

Share this post


Link to post
Share on other sites

@KoiMaax - thanks for briefing me in on the situation with TAW 2.0. The problem with flying in 2000 ft to bomb buildings in a AAA-defended city is an obvious one and is not an option in missions like "Bomb BAI". I'll try to see whether the accuracy goes up with what you suggest.

This is what the manual had to say about freefall bombs

There are three main techniques to be used

to deliver a Freefall bomb:

• From a shallow dive, usually below

20,000 feet and above 2,000 feet.

• Toss bomb (where the aircraft pulls up

and releases the bomb, imparting a ballistic

trajectory and greater range to the bomb),

the maneuver is usually carried out up to

altitudes of 20,000 feet.

• Level flight and release, from any altitude

down to 1,000 feet.

So from these claims it is obvious that ordinary freefall bombing is just plain broken in TAW (level flight bombing from ANY altitude > 1000 ft).

-Traz56

Share this post


Link to post
Share on other sites
I am really happy that TAW is being worked on again.

There is an old bug of TAW still present in TAW 2.0 which is that free fall bombs land ALWAYS way short of the target unless delivered in steep dive. This could either be the result of slightly wrong math for the calculation of the bombing reticle on the screen or a discrepancy between the math for the actual bomb fall and the HUD math.

Anyhow, this can be easily verified by flying eg. the training mission Bomb BAI - one has to just keep flying straight towards the town and drop a bomb with the marker somewhere inside the town area. The bombs will fall at least a whole mile short - it is really that bad. I hope that nobody tries to argue that you have to be fly lower or be in a steeper dive. I have flown pretty much all simulations out there (Jane's, F4, LOMAC) - the bombing marker in all of them works like it should.

Would be great if somebody could have a look at the source code and find what's broken...

Hi Well it may be the factor of it being a retard bomb and wind factors and bombing with a Freefall bomb is known NOT to be Accurate in a Level Drop in RL. Perhaps this sim modeled it correct and the other sims are off in a level bomb run ;).

You may need to be in a Shallow Dive at lower altitudes..and F4 and F-18 you still need to be in a shallow dive for CCIP or you can not get the reticle on target or be able to see the target so a shallow dive is needed... But you are right it could be a math problem be we are NOT able to fix it?? So either do a Shallow Dive at lower alttitudes or a Steeper dive at higher altitude and adjust the reticle with your eyeball and a lil practice ..

In this mission you can bomb THE TARGET at lower altitudes you just need to be patient and let the SEAD do there mission.. that pesky Shilka will be destroyed in time ;)

Share this post


Link to post
Share on other sites
Neph,

Have you been able to duplicate this condition after reloading TAW (including exiting out of the launch menu) and/or rebooting your PC? I ask because I have not been able to duplicate this with either dgVoodoo (DX9) or Zeckensack's wrapper, both starting with a moonlit night and starting with a moonless night and switching to a moonlit night using NVGTool.

In the 2.0 version of redmoon.txt, the transition altitude between palettes is 25000 and 28000 (moonpal ends at 28000 and al2_moon begins at 25000). 26300 is right near the middle, so if this problem persists it may be a bad al2_moon.col file. Reinstalling 2.01 may fix the problem (you won't be able to see the problem in D3D, so testing it here is a non-starter).

Just how small was the moon? I shrunk the size of the moon in 2.0 to about 1/5 of its original size for a more realistic look; is it smaller than that?

OK do this Homefries, In GME install the "Original Green Pallete from 1998 TAW" then select a time at 3AM and the go above 25000ft you will then be able to recreate it..

The problem is within that Pallete..

NOT sure if that thing I saw was the moon maybe it was an artifact of sort??? I saw the new moon and it looked fine ;)

Share this post


Link to post
Share on other sites
@KoiMaax - thanks for briefing me in on the situation with TAW 2.0. The problem with flying in 2000 ft to bomb buildings in a AAA-defended city is an obvious one and is not an option in missions like "Bomb BAI". I'll try to see whether the accuracy goes up with what you suggest.

This is what the manual had to say about freefall bombs

There are three main techniques to be used

to deliver a Freefall bomb:

• From a shallow dive, usually below

20,000 feet and above 2,000 feet.

• Toss bomb (where the aircraft pulls up

and releases the bomb, imparting a ballistic

trajectory and greater range to the bomb),

the maneuver is usually carried out up to

altitudes of 20,000 feet.

• Level flight and release, from any altitude

down to 1,000 feet.

So from these claims it is obvious that ordinary freefall bombing is just plain broken in TAW (level flight bombing from ANY altitude > 1000 ft).

-Traz56

Well, technically I don't think it's broken, it's just more demanding in TAW. Like Neph said, even in real life, most dumb bomb releases are done at a dive, and in salvos of 2 or more... and even that doesn't guarantee a direct hit.

Here's one thing I like doing in the "Bomb BAI" mission. I start level at 15K, then when I reach the kill box I wait until I almost overfly the AAAs. I then pull a 270deg vertical loop, by which I am vertically pointing straight down. I then aim the reticle to fall somewhere between the two Shilkas and release a single MK82 and then I level off at around 10-11K (just enough to get out of range). If done right (around 7-8times out of 10) the bomb lands right smack between both of the Shilkas and destroys them. You can now proceed practicing your shallow dive releases.

It's fun once you get the hang of it.

Cheers!

Share this post


Link to post
Share on other sites
I am really happy that TAW is being worked on again.

There is an old bug of TAW still present in TAW 2.0 which is that free fall bombs land ALWAYS way short of the target unless delivered in steep dive. This could either be the result of slightly wrong math for the calculation of the bombing reticle on the screen or a discrepancy between the math for the actual bomb fall and the HUD math.

Anyhow, this can be easily verified by flying eg. the training mission Bomb BAI - one has to just keep flying straight towards the town and drop a bomb with the marker somewhere inside the town area. The bombs will fall at least a whole mile short - it is really that bad. I hope that nobody tries to argue that you have to be fly lower or be in a steeper dive. I have flown pretty much all simulations out there (Jane's, F4, LOMAC) - the bombing marker in all of them works like it should.

Would be great if somebody could have a look at the source code and find what's broken...

Traz56,

I'll take it as a compliment that you think we did all these mods with the source code. In fact, the source code is not currently available, and while we could do quite a bit with datafile edits, what you describe is locked up in the EXE file.

However, you are correct in saying that CCIP in freefall should represent a more accurate solution. While wind, air temperature/pressure, and humidity have a big say in how dumb bombs will fall, you're right in your assumption that in-game CCIP should be more accurate (esp. since I don't believe these variables are factored into the actual bomb trajectory in-game).

I have added this fix to the TAW 2.x wishlist on the TAW Wiki.

Everybody, please consult this wiki if you wish to either contribute to fixes, or if you just wish to contribute things you would like to see.

Share this post


Link to post
Share on other sites
OK do this Homefries, In GME install the "Original Green Pallete from 1998 TAW" then select a time at 3AM and the go above 25000ft you will then be able to recreate it..

The problem is within that Pallete..

NOT sure if that thing I saw was the moon maybe it was an artifact of sort??? I saw the new moon and it looked fine ;)

You're right, Neph.

I originally made that for people using Glide in 1.5x, where Glide defaulted to NVGs on and didn't take East/West palettes or NVG altitude transitions into account. I never updated this mod for 2.0.

Since I use al2_moon and al4_moon for NVG altitude bands in 2.0 Glide, this is where the problem lies. That said, it's also an easy fix. I'll have this ready to go in 2.02.

In the meantime, you can fix this by deleting redmoon.txt from the \MODS\NVG - Original Green Palette from 1998 TAW\lev folder, then disabling and re-enabling the mod.

Share this post


Link to post
Share on other sites
I have added this fix to the TAW 2.x wishlist on the TAW Wiki.

Everybody, please consult this wiki if you wish to either contribute to fixes, or if you just wish to contribute things you would like to see.

Hey HF,

Could we add these desired fixes under the "Likely Requires EXE edits":

- correct implementation of object and terrain occlusion

- correct effective range of HARM

- correct glare effect when LANTIRN is enabled

Thanks! :D

Share this post


Link to post
Share on other sites
Hey HF,

Could we add these desired fixes under the "Likely Requires EXE edits":

- correct implementation of object and terrain occlusion

- correct effective range of HARM

- correct glare effect when LANTIRN is enabled

Thanks! :D

KoiMaxx,

The beauty of a Wiki is that anybody can make edits. Go ahead and add those, and I will approve them.

Share this post


Link to post
Share on other sites
KoiMaxx,

The beauty of a Wiki is that anybody can make edits. Go ahead and add those, and I will approve them.

Done! :lol:

Share this post


Link to post
Share on other sites

@Home Fries

Thanks for your reply. I must say, yes, I did assume you guys had the source code. I am amazed by what you have achieved without it. Thanks for your efforts.

I am also glad you share my view on the freefall bombing accuracy (or lack thereof) being an error in the simulation. What some people might not realize is that a simple (allegedly realistic) inaccuracy would result in a stray from the target in all directions, i.e. a random error, but would not explain why the bombs are always short in a systematic fashion.

Anyhow, I guess we will just have to be patient and hope that maybe eventually the whole thing is open-sourced (dreaming allowed).

Keep up your efforts. They are greatly appreciated.

Share this post


Link to post
Share on other sites

Well, although I think this is a moot point. Suffice to say though that technically, a ballistic body (barring variables like air viscosity, windage, or even coriolis effect) will be inaccurate primarily along its longitudinal axis (i.e. it will be either long or short). Since the bomb can only maintain so much horizontal velocity after release, it will always land short unless it is imparted with higher kinetic energy by tossing it or releasing it from a dive.

Saying that a simple inaccuracy would result in random impacts is rather contradictory. If the inaccuracy were indeed simple, then shouldn't it be consistent and repeatable? In the first place, I don't think the guys at DID had implemented any sort of other variables to dynamically affect the bomb flight path. And even being able to implement relatively workable ballistics in a simulation during that time was an achievement in itself. Personally, I think the modelling of the bomb physics is pretty accurate in TAW, but I do agree there is a problem with the modelling of the CCIP.

And yeah, I'm also one of those dreaming for that source code.

Cheers! :thumbsup:

Share this post


Link to post
Share on other sites
Well, although I think this is a moot point. Suffice to say though that technically, a ballistic body (barring variables like air viscosity, windage, or even coriolis effect) will be inaccurate primarily along its longitudinal axis (i.e. it will be either long or short). Since the bomb can only maintain so much horizontal velocity after release, it will always land short unless it is imparted with higher kinetic energy by tossing it or releasing it from a dive.

Saying that a simple inaccuracy would result in random impacts is rather contradictory. If the inaccuracy were indeed simple, then shouldn't it be consistent and repeatable? In the first place, I don't think the guys at DID had implemented any sort of other variables to dynamically affect the bomb flight path. And even being able to implement relatively workable ballistics in a simulation during that time was an achievement in itself. Personally, I think the modelling of the bomb physics is pretty accurate in TAW, but I do agree there is a problem with the modelling of the CCIP.

And yeah, I'm also one of those dreaming for that source code.

Cheers! :thumbsup:

You guys are both right.

Ballistic inaccuracy has always been more pronounced along the Y (long) axis than the X (lateral) axis. This is why people dive bomb and cruise missile terminal maneuvers are usually planned for as steep a dive as possible: this minimizes the error along the Y axis.

If you want to get technical, the accuracy of a dumb bomb delivery system is measured in what is known as Circular Error Probable (CEP), which basically says that half of your shapes will land within the circle, half outside. In reality, this is more of an oval, with the oval extending as the release angle (or terminal angle) becomes more horizontal.

So yes, there will be more error long and short (though there will be some amount of lateral error as well), but this means that assuming a consistent release and a good sample size, there should be hits both long and short of the target. If bombs consistently fall short of the target, there is an accuracy issue that goes beyond ballistic variables.

I haven't tested this, but here's my personal theory on the issue: the bombsight was programmed for use with weapons within the bomb bay, so that when the bomb cross is over the target and you pickle the bomb, it factors in the time it takes for the bomb bay to open prior to release. It's worth testing; let me know which mission you use to test your bombing, and I'll tweak it to allow for internal stores as well. Then I'll upload a GME compatible mod of the mission.

Share this post


Link to post
Share on other sites
You guys are both right.

Ballistic inaccuracy has always been more pronounced along the Y (long) axis than the X (lateral) axis. This is why people dive bomb and cruise missile terminal maneuvers are usually planned for as steep a dive as possible: this minimizes the error along the Y axis.

If you want to get technical, the accuracy of a dumb bomb delivery system is measured in what is known as Circular Error Probable (CEP), which basically says that half of your shapes will land within the circle, half outside. In reality, this is more of an oval, with the oval extending as the release angle (or terminal angle) becomes more horizontal.

So yes, there will be more error long and short (though there will be some amount of lateral error as well), but this means that assuming a consistent release and a good sample size, there should be hits both long and short of the target. If bombs consistently fall short of the target, there is an accuracy issue that goes beyond ballistic variables.

I haven't tested this, but here's my personal theory on the issue: the bombsight was programmed for use with weapons within the bomb bay, so that when the bomb cross is over the target and you pickle the bomb, it factors in the time it takes for the bomb bay to open prior to release. It's worth testing; let me know which mission you use to test your bombing, and I'll tweak it to allow for internal stores as well. Then I'll upload a GME compatible mod of the mission.

That's very interesting, I'll have a swing at it.

Cheers!

Share this post


Link to post
Share on other sites

Hey HF,

I did a couple of quick flights testing your bomb bay theory. It seems like the time to open the bays is automatically factored when released inboard stores. So in practice the CCIP marker is advanced a bit when releasing from a closed bay. I also tried releasing from the pylons and when the bays are pre-opened, and the release patterns were pretty much the same. So summary, at the proper release parameters, it doesn't matter if you are release from a closed or open bay or from a pylon.

What I wanted to do next is figure out what parameters are necessary to ensure accurate hits using CCIP during level release. I did this on the Bomb BAI mission. I found out that in order for CCIP to be accurate I had to be around 700kts at 1000 ft and around 800kts at 2000ft. I'll try to play around with higher altitudes... but judging from the speeds required, releasing from level flight could at best be done from under 3000ft. This are just quick tests though, so it is not final in any sense.

Regards.

Share this post


Link to post
Share on other sites
Thanks for the testing KoiMaxx.

No prob! :thumbsup:

@HF

I was having fun with the Additional Missions section (because I glimpsed UFO missions there before) and I kinda was thinking if it were possible to group the UFO series together in that section. Well actually, I already looked into it and it just needs a few lines moved in f22data\simultor.txt.

But it's just a minor cosmetic change and won't affect gameplay at all so it's no priority.

Thanks!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now