Not a Known ANW Issue #01 or How to build AIP Submarines

[Bucks]

This is a response to one of Herman's "Known ANW Issues" - It has been "introduced" since the release of the ANW 3.9.4 update...

7. AIP endurance shows 4%

Unit display shows endurance at 4% even though it should be at 100%

Well maybe, and maybe it might be related to all AIP capable submarines included in the PDB and the way they are constructed. I've downloaded the [PDb] AIP endurance shows 4% (3.9.4).scn file and immediately noticed that there was an issue with the Sub's unit display.

The U 31 Type 212 DE 05 SSK is only displaying two types of fuel values, Fuel: and AIP Time:. The issue here is that the submarine is still a conventional Diesel/Electric boat, with the added capability of recharging its batteries while submerged through the use of the AIP system. Ufortunately every PDB AIP capable submarine is missing the electric/battery components of this relatively new system.

The screen capture below shows the lack of an electric propulsion system and associated battery fuel. I will then show the submarine's DB profile from the RE along with a set of screen captures illustrating the correct configuration for AIP submarines.

Cheers

Darren

[Bucks]

Ok the RE shows why the report is incorrect (not a game engine issue) as the real problem is the propulsion configuration of Players DB AIP subs.

I've made notes on this screen capture and will then add more from the HUD3 displaying the correct propulsion configuration for AIP Subs.

Cheers

Darren

[Bucks]

PDB AIP Sub Fuel loads:

[Bucks]

Now here are two examples of AIP subs using the HUD3. Infact these are the only two AIP subs I've added so far.

[Bucks]

And example Two showing the same configuration and differing AIP times.

[Bucks]

Here's the relevant details from the RE showing how AIP subs should be constructed as well as the correct AIP fuel units to use. Set of two screens follow.

Cheers

Darren

I hope we can see this issue closed as I don't believe it has anything to do with the Game Engine or coding but is a database configuration issue.

[Bucks]

Screen Two

[hermanhum]

ORIGINAL: Bucks

The U 31 Type 212 DE 05 SSK is only displaying two types of fuel values, Fuel: and AIP Time:. The issue here is that the submarine is still a conventional Diesel/Electric boat, with the added capability of recharging its batteries while submerged through the use of the AIP system. Ufortunately every PDB AIP capable submarine is missing the electric/battery components of this relatively new system.

The new changes will be implemented in the next PlayersDB release. Thanks for the explanation.

I concur that this isn't a Game Engine issue. It's a Game Documentation issue. This is (at least) the third instance of Undocumented Features causing end-user misunderstandings. I've looked in the:

a) AGSI wiki,
b) Release notes, and
c) eManual

There doesn't seem to be any public way to find out about these changes. Am I looking in the wrong places?

In fact, after the explanation, three problems have been taken off the List of Known Issues:

[blockquote][*]AIP Endurance same at Full and Flank speed

Full speed has 343:20hrs, and Flank speed has 343:20hrs, too

[*]AIP endurance shows 4%

Unit display shows endurance at 4% even though it should be at 100%

[*]Unable to switch off AIP

Sub has a diesel engine and fuel, but is unable to utilize either when run at Periscope depth after AIP fuel is exhausted[/quote]

[Bucks]

ORIGINAL: hermanhum

The new changes will be implemented in the next PlayersDB release. Thanks for the explanation.

I concur that this isn't a Game Engine issue. It's a Game Documentation issue. This is (at least) the third instance of Undocumented Features causing end-user misunderstandings. I've looked in the:

a) AGSI wiki,
b) Release notes, and
c) eManual

There doesn't seem to be any public way to find out about these changes. Am I looking in the wrong places?

You're correct, there's no documentation to be found, I even went back to the Harpoon 2 manual to find what I could:

Air Independent
This propulsion is used primarily on submarines. Air Independent functions as a diesel engine at Periscope and Surface depths, and burns stored oxygen at lower depths. The unit upon which this propulsion is placed must rise to Periscope and Surface depths to recharge its oxygen supply. Air Independent propulsion uses Diesel and Air Independent fuel types.

Maybe you had looked this over as well, seeing as you had the PDB Submarines configured this way. In effect the two fuel types listed are simply those the AIP system can actually utilise, not the only two the Submarine should carry. A little further on the H2 manual points to the following fuel capacity guidelines and useage which is basically where I began researching this subject:

Some Capacity Guidelines

The following list should give some indication of the amounts to use for the Capacity field.

Batteries - capacity represents seconds of operation at 5 knots.

Fuel Oil, Aviation Fuel, Gas Fuel, Diesel Fuel (on ships) - capacity represents tons of fuel.

Air Independent - capacity represents stored oxidizer sufficient to use 1 ton of Diesel Fuel.

Then I found the fuel consumption figures to base my initial calculations on after some quick research into the RL systems readily available on Wikipedia. Sometimes the best way to get things working is to simply "give it a go" and adjust your figures to take account of observed behaviour. A little like hunting bugs in the code, you apply a process and observe THEN arrive at conclusions based on the known facts and your observed behaviour:

Fuel Type: Diesel and Air-Independent (simultaneously)
Fuel Consumption
Cruise: Consumes fuel at rate of 100 * (tons fuel/Endurance)
Endurance= range (nm) /speed [6 -10] kts
Tons Fuel = the total fuel capacity of the unit.
Boost: same as Cruise.

- Diesel
A propulsion type for use in both submarines and ships. A combustion engine using diesel fuel. Must be within 20 meters of the surface to snorkel air for the combustion process.

Fuel Type: Diesel Fuel
Fuel Consumption
Cruise: Consumes fuel at rate of 100 * (tons fuel/Endurance)
Endurance= range (nm) /speed [6-10] kts
Tons Fuel = the total fuel capacity of the unit.
Boost: Same as Cruise.

I've also checked the ANW Database manual and it will need some work to have a correct and relevant explanation of the process of constructing AIP submarines. If you follow it as you may have Herman, you'd simply be back to square one (no electric motor).

5. For submarines using Air Independent propulsion, you need just the AI engine and two fuel loads. One load of diesel as calculated using the same equations as for ships, and one load of air independent fuel of the same amount as diesel. - HP3-DatabaseManual-rev1.2.pdf

I can see the need for rev 1.3 already. I will at some point in the future set about a corrected version of a DB editing manual shortly. There are many features not covered in the present version of the manual and also stuff relevant to getting the most from the HUD3.

Cheers

Darren

[th3flyboy]

Judging by what I see in this thread so far, it's possible that new documentation could take more bugs off that list than already stated by HH. It's possible that out of date docs could be causing more misunderstandings about how things are working, and as such, are causing errors at the DB level, where people think they are at the Engine level.

[Bucks]

ORIGINAL: th3flyboy

Judging by what I see in this thread so far, it's possible that new documentation could take more bugs off that list than already stated by HH. It's possible that out of date docs could be causing more misunderstandings about how things are working, and as such, are causing errors at the DB level, where people think they are at the Engine level.

You know you might just you be right th3flyboy.

Although only some people think it's the GE. AGSI did take the forward thinking step of stating there is a DB compliance framework and to avoid these issues following those guidelines might just make a lot of the list disappear and a lot of sense at that.

Although I doubt that it's "out of date" docs. I found most of the information for the correct construction of AIP subs from the original "in game" Harpoon 2 documentation from the late 90's. It's more a case of assembling the correct documentation and I have started to correct and bring the H2 docs up to ANW spec which I hope to gain Mr Gilman's permission to publish on the HUD3 website in the near future. In fact I have already used quite a few sections of the original manual to track down portions of coding that were not implemented in H2 or H3 but are now functioning parts of the ANW game.

I've already found at least 2 more "issues" that are based on the values contained in the PDB and will start another thread pointing out where the Editor has "gone wrong" and has incorrect values causing more issues that have been heaped upon the game engine rather than the Editor taking a hard look at his figures. It is of the upmost importance that the compliance guidelines are followed and implemented if these simple issues are to be fixed and the list reduced. I have even had the excuse fired at me that it shouldn't matter what values are used...

Unfortunately with the limited coding and testing resources available to AGSI, it becomes a question of time and I really don't see my job as correcting the PDB's mistakes. I have myself, had to correct or generate new systems to calculate values as now required for the HUD3 in relation to the DB compliance situation and the changes in the game's performance.

A perfect example are numerous ECM systems in the PDB that have negative values for their Search Output data and the only interaction this value has in game terms is for ECM detection, i.e. the range at which the ECM system will be counter detected by ESM systems. A negative value in this case has to my knowledge UNKNOWN effects on the GE's resolution and interpretation of this situation. The value should always be positive and is translated to detection range in the same way emitting radar systems are.

Of course those dealing with this section of game mechanics should have already understood this and looked at their own data before aportioning blame to the game's code. This is of course the reason we have a set of compliance guidelines and why there are at present only two DB's that are officially used for testing and development purposes (the PDB is not one of them).

Cheers

Darren

[hermanhum]

ORIGINAL: Bucks
there are at present only two DB's that are officially used for testing and development purposes (the PDB is not one of them).

Which, of course, explains why no problems involving actual game situations are ever reported for anything except the PlayersDB, since it's pretty much the only one that gets any play due to it's stability and the fact that the scenarios built with it seem to be the only ones actually tested. If AGSI actually had player input instead of just theoretical wish lists, the game would not be in its current state.

[Bucks]

ORIGINAL: hermanhum
Which, of course, explains why no problems involving actual game situations are ever reported for anything except the PlayersDB, since it's pretty much the only one that gets any play due to it's stability and the fact that the scenarios built with it seem to be the only ones actually tested. If AGSI actually had player input instead of just theoretical wish lists, the game would not be in its current state.

Of course the logical end point might just be that the reason the PDB is the only DB reporting errors is that it might be the one DB full of errors or not adhering to the compliance guidelines. Every DB is stable, I have to wonder if your English comprehension is up to speed. Or maybe Herman you're just one of those people who never makes a mistake, good comeback by the way [:D]

Catch ya on the flipside...

Darren

[hermanhum]

ORIGINAL: Bucks

Of course the logical end point might just be that the reason the PDB is the only DB reporting errors is that it might be the one DB full of errors or not adhering to the compliance guidelines. Every DB is stable, I have to wonder if your English comprehension is up to speed. Or maybe Herman you're just one of those people who never makes a mistake, good comeback by the way

Well, that's the funny part. Although the PlayersDB is used as the basis to report most of the bugs, those bugs are replicable in other DBs, too. In fact, of the 212 bugs currently listed on the Known List of ANW Issues, about 150 are verified with files from the PlayersDB. That still means 60 problems found with other databases. Even in the highly unlikely event that the PlayersDB was as buggy as the HUD3 and responsible for all 150 issues, that would still mean a mountain of problems.

The one logical conclusion is that ANW is a bug-infested mess. However, only folks who actually test would know that. Anyone who truly has a clue as to the state of the game would never utter,

ORIGINAL: Bucks

Every DB is stable...

[hermanhum]

ORIGINAL: Bucks

A perfect example are numerous ECM systems in the PDB that have negative values for their Search Output data and the only interaction this value has in game terms is for ECM detection, i.e. the range at which the ECM system will be counter detected by ESM systems. A negative value in this case has to my knowledge UNKNOWN effects on the GE's resolution and interpretation of this situation. The value should always be positive and is translated to detection range in the same way emitting radar systems are.

Yes, this is the perfect example.

The thread Attention DB Designers: Important ECM Changes is quite clear:

ORIGINAL: VCDH

I haven't tried negative values yet (which would be useful against less capable phased array radars)

I did try them and found them much more useful than the positive values. Looks like this is just another case of "Those who do not follow the HUD3 must be wrong" mentality. At least this one had documentation.

[blockquote]Reading the fine print can save you from future embarassment.[:D][/quote]

[Bucks]

But has anyone tested these values aginst visual sensors? I've looked at one of your listed problems; to me there seems a real relationship between some DB values and your "report".

Just because an experiment proves your point once, does not mean it becomes the truth. I've got some past experience in that so trust me.

Dale said he had not tried them, you can't see my name on the thread can you? Don't try to blame AGSI for poor documentation then what blame me for not reading it? Get serious Herman. You did try negative numbers... Although the new ESM system is limited by horizon range and the two values used are Search Output for counter detection and Track Output for self protection combat resolution modification. The only other characteristic taken into account is the "phased array" rafar flag that applies a modifed jamming effect to radars so flagged

Exactly how are the negative numbers more effective, please explain yourself? What did they produce and where did you document your findings? The number (search output) is used to determine the range at which the emitting jammer can be detected. Not the range at which the system jams. You and Dale can work that one out, I'll stick with what I know works. Personally it kinda sounds like that's a fairy tale or you need to add another "bug" to your list.

Sorry have 3.10 work to do, this and you become tiresome.

Looks like this is just another case of "Those who do not follow the HUD3 must be wrong" mentality. At least this one had documentation.

Reading the fine print can save you from future embarassment.

Where did I say I had that mentality, the discussion was in regard to how the system works, not which DB it was implemented in. I have documentation, and since I know my jammers work, how could I be embarassed? Herman be careful I don't take a microscope to that PDB of yours, might want to rethink the advice, take care out there now.


Cheers

Darren [8D]

[hermanhum]

ORIGINAL: Bucks

Just because an experiment proves your point once, does not mean it becomes the truth. I've got some past experience in that so trust me.

Dale said he had not tried them, you can't see my name on the thread can you? Don't try to blame AGSI for poor documentation then what blame me for not reading it? Get serious Herman. You did try negative numbers...

And therein lies the crux of the matter. You are not the determinant of what goes into a database. No one cares about your approval, agreement, or doing things your way. I used the numbers that I liked and they are different from yours. Seems as though the only problem is that no one wants to listen to you or do things your way. Thanks for your input, but I'll continue to use the values I think are best for the PlayersDB.

[Bucks]

Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

Seach output - Used by ESM systems to detect active radars or ECM systems. This is a positive number as it represents the output power of either a radar system or ECM system.

Here's the basis for my model:

Radar Search Signal/ECM Output is expressed as a log of the peak output power in watts.

To calculate the number for this field use the following formula: 100*LOG10 (Peak output in watts). If peak output in watts is not available, use twice the average output. I use an identical system so jammers fit the ESM detection modeling.

I'll pick the PDB Caiman OECM Sensor #756
SEARCH OUTPUT = -250

Since we're using a Logarithmic scale how do you arrive at a negative value?

100 * LOG10( X ) = -250

What value is X

LOG10(-1) = ERROR

Anyway back to work...

Thanks

Darren

[hermanhum]

ORIGINAL: Bucks

Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

Rubbish.

You the ECM value should have absolutely no effect on any visual sensor. The Visual Light bandwidth isn't even selected for any of the ECM systems. If they are somehow exerting an effect on the Visual sensors, you've got some majorly bad things going on. It would be like saying Radar has some effect on Sonar.

Utter rubbish.

[Bucks]

HERE IT IS AGAIN - NOTE VISUAL SENSORS ARE NOT MENTIONED IN MY PREVIOUS POST

I'm trying to explain how it works, it's not a popularity contest and there is a lot of "under the hood" stuff here. I wanted to ask how you arrived at your values and if they do work, exactly how they are being interpreted by the Game Engine. Ok it's outside my model and the expected values for use by the GE. If they do work fine but how do these negatives interact with your ESM systems? Don't they have issues detecting a negative output in the case of your ECM as compared to your positive radar output values?

See previous reply from Herman

Herman if your values don't fit the guidelines of the values the coding handles, pull your list down and go away, thanks for the admission you have no idea what your doing.

Seach output - Used by ESM systems to detect active radars or ECM systems. This is a positive number as it represents the output power of either a radar system or ECM system.

Here's the basis for my model:

Radar Search Signal/ECM Output is expressed as a log of the peak output power in watts.

To calculate the number for this field use the following formula: 100*LOG10 (Peak output in watts). If peak output in watts is not available, use twice the average output. I use an identical system so jammers fit the ESM detection modeling.

I'll pick the PDB Caiman OECM Sensor #756
SEARCH OUTPUT = -250

Since we're using a Logarithmic scale how do you arrive at a negative value?

100 * LOG10( X ) = -250

What value is X

LOG10(-1) = ERROR

Anyway back to work...

Thanks

Darren