4.12.2 de-bugging

[P-38L]

Hello Daidalos Team

I just recently notice an issue about craters.

In FMB I choose in Craters windows that all three types of bombs will vanish at 99999*80s, that makes them stay almost all the mission. From here all is right.
http://ist3-1.filesor.com/pimpandhost.com/1/_/_/_/1/2/J/D/D/2JDDs/Craters_01.jpg (http://pimpandhost.com/image/40429794-original.html)
But when I choose the Pe-8 and select for Weapons: 1xFAB-5000 (the biggest bomb this airplane can load) the explosion is huge, but the crater starts to dissapear within a minute and the rest of the small craters produced for other bombs remain as I want except the big one.
http://ist3-2.filesor.com/pimpandhost.com/1/_/_/_/1/2/J/D/D/2JDDv/Craters_02.jpg (http://pimpandhost.com/image/40429797-original.html)

I don't know if this is an issue.

Thank you very much.

[Pursuivant]

Player AI doesn't seem to use/adjust pitch control.

This is a known problem. "AI" as implemented when a player triggers the "autopilot" option is different from true AI as implemented for computer-controlled planes.

"Player implemented AI" does nothing with engine management other than throttle control.

In addition to the problems you mentioned, I know that manual supercharger settings also aren't adjusted for altitude, because I complained about this a few years ago and got an answer back from a member of DT.

I'd have to double check, but I also believe that "player implemented AI" doesn't use WEP or adjust radiator settings even when it is appropriate to do so.

[sniperton]

That is, it's a proper feature, not a bug. :grin:
Thanks for the clarification!

[Ventura]

Not sure if this has been addressed, but the 'Radio Silence' box in the FMB doesn't have AI stay off the radio.

Or is it only supposed to keep AI from non-important chatter? When they get attacked, they're all over the net..

Was trying to use this as a decoy to keep enemy form hearing calls on friendly wave length...

[Pursuivant]

Not sure if this has been addressed, but the 'Radio Silence' box in the FMB doesn't have AI stay off the radio.

If the "radio silence" option just keeps AI from calling out things like course changes and waypoints, but still allows it to use radios in combat, that's realistic.

Radio silence is used to keep the enemy from detecting your presence. Once you're under attack or you attack yourself, the enemy has, by definition, detected you so there's no more need for it.

There actually need to be three options for radio use:

* No radio silence.

* Radio silence. AI only breaks radio silence when they attack or are detected or spotted by the enemy.


* No radio. AI doesn't use the radio at all. Necessary for planes that weren't equipped with radios.

[sniperton]

We have buttons for
pitch +/-
supercharger +/-
mixture +/-
etc.

Please, please, could I have a button for radiator- ?

[stovak]

Please, please, could I have a button for radiator- ?

+1

[sniperton]

We have HUD messages for actual
pitch
supercharger
mixture
throttle
etc. setting adjustments.


It would be great to have one for trim settings as well. Could be made optional, via config.ini.

Thanks

[majorfailure]

It would be great to have one for trim settings as well. Could be made optional, via config.ini.

Thanks
Yes please

Please, please, could I have a button for radiator- ?
+1

And an optional HUD fuel gauge(keypress for fuel state) for planes that currently have no working fuel gauges, but had them in real life (e. g. the Yak family, P-40...)

[Pursuivant]

Please, please, could I have a button for radiator- ?

One button to open or close the radiator is a bit simplistic, since different planes had different radiator controls. Some had a simple open/closed option, others had detents that only allowed the radiator vanes to be opened in certain positions. Some had fully adjustable radiator controls.

The big problem with the radiator controls is that they're on a "pivot" rather than being on a "slider." That is, pressing the radiator control button once opens it to 20%, pressing it again takes it to 40%, and so forth, until you get to 100% open. But then, you press the button again and you go back to 0%! AFAIK, no airplane ever had radiator controls like that.

What needs to happen is that the default radiator control should be a "slider" where you can adjust the radiator vanes from 0-100% and back again. For planes which didn't have radiator controls, the "slider" is fixed at 100% open. For planes which had detents, pressing the radiator control button opens or closes the vents at the next level.

[stovak]

One button to open or close the radiator is a bit simplistic

I think he's not asking for a single open/close button, but an added 'radiator minus' button to close the rad/cowl in steps to go with the current 'radiator plus'. In order to close the rad by one step we have the awkward task of cycling through eight positions using the 'open' button, and it's quite easy to overshoot and have to start again. A 'close' button would be much appreciated.

There is a slider-axis option already, but of course we don't all have enough sliders :sad:

[IceFire]

One button to open or close the radiator is a bit simplistic, since different planes had different radiator controls. Some had a simple open/closed option, others had detents that only allowed the radiator vanes to be opened in certain positions. Some had fully adjustable radiator controls.

The big problem with the radiator controls is that they're on a "pivot" rather than being on a "slider." That is, pressing the radiator control button once opens it to 20%, pressing it again takes it to 40%, and so forth, until you get to 100% open. But then, you press the button again and you go back to 0%! AFAIK, no airplane ever had radiator controls like that.

What needs to happen is that the default radiator control should be a "slider" where you can adjust the radiator vanes from 0-100% and back again. For planes which didn't have radiator controls, the "slider" is fixed at 100% open. For planes which had detents, pressing the radiator control button opens or closes the vents at the next level.

What you described is what he's asking about. So you're both on the same page :)

He said he wants a "radiator-" and a "radiator+" so you can open and close. Maybe wasn't put the clearest way but it sounds like a good idea.

I'd actually say that for compatibility sake you can still maintain the Radiator Toggle or you can have Radiator Open and Radiator Close buttons that work in a similar way to the flaps. Not sure how many aircraft had an open/closed arrangement and how many had a system where they can be finely controlled (by slider for example).

It'd be a bit more work than just adding the button presses. The mechanicals of all of the aircraft we have might need a going over to know how each should function. Not a bad thing IMHO but it would take some time.

[sniperton]

He said he wants a "radiator-" and a "radiator+" so you can open and close. Maybe wasn't put the clearest way but it sounds like a good idea.

Yep, sorry for my English. The logical way would be to go from 'closed' to 'open', and then backward, from 'open' to closed'. Plus and Minus. No cycling through.

[Pursuivant]

Yep, sorry for my English. The logical way would be to go from 'closed' to 'open', and then backward, from 'open' to closed'. Plus and Minus. No cycling through.

I'm not sure if TD wants to bother with it, but "radiator" settings are even more complex than I thought for some planes.

For example, the P-39 series didn't have preset "detents" for the radiator like I thought. Instead, it had open and shut (i.e., 0 or 100% open) shutters for the Coolant Radiator and the Oil Cooler, as well as what I believe to be a 0-100% slider-type control (in the form of a push-rod that could be elevated or depressed) for carburetor air heat, and a switch for carburetor air filtration.

Carb air heat controls were necessary to prevent engine stoppage at altitude due to carburetor icing. Filter controls allowed the pilot to choose between hot unfiltered air (presumably waste heat from the air or oil cooler systems) and cold filtered air (presumably outside air pulled in via a filter intake).

Likewise, the F6F-5 also had separate shutters for oil coolant and the intercooler.

Things also get complex for the P-51's radiator systems, as this very old thread describes:

http://forums.ubi.com/showthread.php/3404-The-Mustang-its-radiator-and-speed-Forums

[shelby]

here is a small bug like the p40b/c bug
http://s26.postimg.org/5318gqh09/2015_02_16_13_19_36.jpg
http://s26.postimg.org/5h2kgc13t/2015_02_16_13_19_57.jpg

[Tolwyn]

That's not a bug. Just a re-using of model resources.

[Corvus Corax]

Hi folks,
I have found a minor error:
The airspeed indicator on all P-38 Models shows the actual speed in knots, but the indicator itself is marked with mph (the speed limitations on the dashboard are given in mph too). This can easily be detected by comparing the speed from the indicator with the speed shown on the HUD and switching between mph an knots.

Because not beeing sure whitch unit was used on the Lightning I searched an found this nice manual:
http://www.avialogs.com/index.php/en/aircraft/usa/lockheed/p-38lightning/aaf-manual-51-127-1-pilot-training-manual-for-the-p-38-lightning.html

Therein all speeds are given in mph, so its much likely that the the indicator should show mph as well.
Perhaps this small bug can be corrected in a future patch.

[Woke Up Dead]

The Rogozarski IK-3 is extremely tough, it takes many many 20mm shells to bring down, sometimes even more than many many. Wikipedia says it was built out of steel tube, wood, and fabric; not carbon composites, diamonds, and spider silk like its current durability suggests. Perhaps someone at TD could take a look at the damage model?

[Pursuivant]

The Rogozarski IK-3 is extremely tough, it takes many many 20mm shells to bring down, sometimes even more than many many. Wikipedia says it was built out of steel tube, wood, and fabric; not carbon composites, diamonds, and spider silk like its current durability suggests. Perhaps someone at TD could take a look at the damage model?

I can believe that the IK-3 is too tough. When it was first introduced to IL2, I recall the IK-3 as being superior to just about all contemporary planes in the game. Subsequent patches seem to have toned down its performance to make it roughly comparable to the Hurricane Mk II. Perhaps someone forgot to take a second look at its DM when they fixed the FM.

That said, fabric-covered, steel frame aircraft could be surprisingly tough, since bullets and cannon shells generally harmlessly passed through the canvas without exploding.

Even if an explosive bullet or cannon shell exploded on contact, it typically just blew away fabric, leaving the steel frame intact. Unlike a monocoque constructed plane, that meant only an increase in drag, but little or no structural damage. The IK-3 DM might be an attempt to model this effect.

Unfortunately, I don't think that IL2 can model drag increases due to damage separately from reductions in structural strength due to damage. Obviously, it can't model different sorts of damage, which leads to the odd situation on some planes where the damage textures show more holes than actual bullets which hit the plane, and which show damage different places than the bullets actually hit.

[shelby]

Here is another bug in p47s
http://s26.postimg.org/ou92xbqmx/2015_02_27_14_15_12.jpg

[yak-9]

i'm interested in flatter modeled effect with this update.particularly for yak family. for early versions flatter starts on 550km/h and does not depend on altitude.on 650km/h plane crashes.it is not right since it should depend on altitude and can not be lower than max horizontal speed. if yak has 580km/h top speed at altitude-flatter should start at least at 600km/h at same altitude.
as far as i understand.
so i consider this as bug!?
thanks fo attention!

[=VARP=Thor]

Setting Bridges as targets for an online mission.

Tested in IL2 multiplay the bridge is destroyed by 2 x 1000lb bombs, the target is closed.

When tested online with the same loadout, the bridge cannot be destroyed.
The target cannot be closed.

This has been tested over several days with no change in the result.
Hi all,
We all know that bridges in the game have some numbers. Numbers are going from* #0 to some number which depends on how many bridges some map have. All maps which have less or equal #255 bridges are ok and will not have any errors. Maps with >#256* bridges have this error.

Error example: Human is attacking bridge #256 and eventlog says he has* destroyed bridge #0 with coordinates of actual bridge #0.
Few more examples: attacked #257** destroyed #1
************************************** attacked #302** destroyed #46
************************************** attacked #533** destroyed #21

Error is the same in stock game and HSFX and changes of il2fb.exe to Ivan's 1GB doesn't help also.

After many test performed by CountZero, JG26/Badger and me, here is conclusion:
Error happens ONLY when human is connected to server and human is making that attack. If host attack the bridge everything is fine and any bridge destroyed on any map is reported correctly. Also if AI plane is performing the attack, everything is just fine. Regardless the bridge number it will be reported correctly in eventlog. SEOW bridge destruction by engineer doesn't cout because it is a SEOW internal process.

So,we have mystical pattern of 256. For bridges with higher numbers it repeat itself (#533-256-256=#21). At first we thought it is some visual thing where some players cant see bridge destruction. Then we thought they were lost and destroyed wrong bridges in our SEOW campaign. Now we know how this is happening. You can try to put a camera using this pattern and you will see destruction of the bridge in area where there in no one near and while you are attacking bridge on the other part of the map.
I have no idea why is this 256 pattern happening or how to fix this but my wild guess is that server knows what he is doing and what AI is doing,but some information he is reciving from human clients is wrong. Like i said just a guess.

Cheers,

Thor

[JG26_Badger]

S~:

For those of you that enjoy bombing bridges to either stop an opponents advance or to cut off the enemy supply lines there is a bug that has been discovered that is in the IL2 game engine.

We discovered this bug in an SEOW campaign that some participants were reporting that bridges were not registering destruction properly.

Each bridge in a map (both Road Bridges and Railway bridges) is assigned a unique number in the IL2 game. The bridge #'s start with zero (0 to whatever number the game assigns). Many of the maps especially large maps have more than 255 bridges (bridges numbered 0-255). If an AI plane or Client plane bombs and destroys any bridge# 0-255, the bridge destruction is visually displayed correctly in the IL2 game and the eventlog accurately reflects the correct bridge# destroyed. Therefore when the SEOW DCS analyzes the eventlog those events are accurately captured in the SEOW Mission Planner and stats pages.

The problem occurs when a client player (human) bombs a bridge that has a bridge # greater than 255, for example bridge # 256 this bridge will not be destroyed in the IL2 game. Visually it will be undamaged however bridge # 0 will be destroyed. Bridge # 0 will be in a totally different location, this is recorded in the eventlog. So when this is analyzed with the SEOW DCS it records the event and a destroyed bridge at the location according to the eventlog which is not correct. This only occurs with a client player (human), the AI planes will destroy the bridge #256 and the correct bridge # will be displayed destroyed visually in the IL2 game and the eventlog will show bridge # 256 destroyed. A host human that is playing as the host (not using the host seat) will be able to bomb bridge 256 and the eventlog will show bridge 256 destroyed just as the AI plane does.

So the problem is any client that bombs bridges # > 255, the bridge # that will appear destroyed both in the eventlog and visually in the IL2 game will be that (bridge# - 256). As you can see this is a serious problem. I hope members of Team Daidalos will look into this an try an fix this problem with the eventlog.

Thanks
S~
JG26_Badger

[=VARP=Thor]

Hi,

I've made a post about bridges yesterady, but it never appear here.
So, i can only confirm what Badger wrote:)

~S~

[shelby]

one more bug
http://s26.postimg.org/shjdafo2h/2015_03_14_16_23_00.jpg

[SturmovikPilot]

After a Windows important update, the yellow cursor in the menu selector disappears when the mouse is moved, therefore the game can not be started.
Also after I install my Razer Tartarus gamepad the Throttle is not seen in the game. If I remove the stick then the throttle is seen.
Any help and suggestions are appreciated.
System is: Windows 8.1 Pro
gpu=EVGA Geforce GTX 760
Respectfully
Gregory Lee WIlliams

[TexasJG]

For whatever reason, I have to go back to the "Windows Desktop" to get control over the IL-2 mouse at the il2fb.exe startup. Always have to do so twice (2 times). First time gives me the full screen GUI, with the mouse centered, but no control, then second gives me control over the mouse. This started many updates ago.
Don't think it's a bug strictly speaking, more to the age of the programs.
Anyway, this work around is quick and easy, maybe it will help.

[RPS69]

For whatever reason, I have to go back to the "Windows Desktop" to get control over the IL-2 mouse at the il2fb.exe startup. Always have to do so twice (2 times). First time gives me the full screen GUI, with the mouse centered, but no control, then second gives me control over the mouse. This started many updates ago.
Don't think it's a bug strictly speaking, more to the age of the programs.
Anyway, this work around is quick and easy, maybe it will help.

That bug is as old as the game itself. And the solution is the one you applied.

[Janosch]

If a player has a blank callsign, then their aircraft isn't shown in an online ntrk film at all. During playback, they can't be viewed or seen, neither internal or external views.

[majorfailure]

After a Windows important update, the yellow cursor in the menu selector disappears when the mouse is moved, therefore the game can not be started.
Also after I install my Razer Tartarus gamepad the Throttle is not seen in the game. If I remove the stick then the throttle is seen.
Any help and suggestions are appreciated.
System is: Windows 8.1 Pro
gpu=EVGA Geforce GTX 760
Respectfully
Gregory Lee WIlliams

If it is the same problem me and others had, then reset your text size (desktop-right click -screen res-enlarge text) to 100%.
Also see here:
http://forum.1cpublishing.eu/showthread.php?t=229015

[Tolwyn]

No MODS (I promiose).

Ok. Pick a PE8. Any mission.
Sit on the tarmac.

Record.

Have a smoke.

Open bomb bay doors.
Close bomb bay doors.

Have some vodka.

Stop record.

Replay NTRK.

Kinda works okay. When you give the open command, they open... but then kinda close again right away. Then you give the close command, they open and then close again.

Um...

Ok.

Now...

PLAYBACK that track and start a NEW NTRK while playing that one back.

It gets ALL MESSED UP.

Open (they close).
Close (they open).

Ugh.

I know... Weird... but still!

[stovak]

Here's a line from the 4.13 guide -

Other fixes & tweaks

• Fixed NTRK & bomb bay door bug that caused doors to randomly close during playback

It looks like the problem is fixed in the patch :)

[Tolwyn]

What patch?
There's a patch?

It's been over a year. Good lord.

Here's a line from the 4.13 guide -

Other fixes & tweaks

• Fixed NTRK & bomb bay door bug that caused doors to randomly close during playback

It looks like the problem is fixed in the patch :)

[KG26_Alpha]

There was a v4.13 guide/(read me), uploaded and linked on here in the TD update thread.

Its currently been removed for revision (possibly).

[robday]

It's been over a year. Good lord.

Only a year! TD are enthusiasts, the work that they do (and we benefit from) is completely free of charge to us. In my other hobby (model railways) one particular multi-national manufacturer announced a number of models three years ago, some of which haven't even left the DRAWING OFFICE stage yet!

[Tolwyn]

Yes yes.
I know that the party line for everyone is that it's in their free time, blah blah.

In my other hobby, I'm a project manager, and this is just a little ridiculous.
Either get it done, or abandon it. Soon none of us will be flying it anyways.

I remember working on HUGE gaming projects (addons) in the 90s in my free time, with a group of talented people, and we didn't take a year.

I would love to see this patch. I think the features that they've discussed look promising. And I have been patient. That being said you have to start questioning what's going on and why it's taking so long. Diminishing returns.

Only a year! TD are enthusiasts, the work that they do (and we benefit from) is completely free of charge to us. In my other hobby (model railways) one particular multi-national manufacturer announced a number of models three years ago, some of which haven't even left the DRAWING OFFICE stage yet!

[ddr]

http://forums.oce.leagueoflegends.com/board/attachment.php?attachmentid=12128
very interesting sterile discussion :)
hope to see soon 4.13, in menawhile play 4.12 with pleasure :D
bye!

ok, this is a OT, excuseme :)

[stovak]

Yes yes. blah blah.

Those of us who enjoy the game as it stands and look forward to further improvements without seeing them as some kind of entitlement, will continue to enjoy the game and continue to appreciate the work that others put in to prolong the life of the sim.

The addition of 6DoF, widescreen and many other advances have made given the game a new lease of life with every update, far beyond anything we have any right to expect. Why people feel it necessary to complain all the time is beyond me, and I would understand it if the TD contributers just gave up in frustration.

Playing il2 is not compulsory. Updating with new patches as and when they come out is not compulsory. If you prefer earlier versions, carry on using them. If you prefer to give it up all together, please feel free to do so. The rest of us will happily go on without you.

[KG26_Alpha]

Ok calm down please.

:)

Not much longer, before you can report all the things that are wrong.

And enjoy all the stuff that's done right !!

:)

[Janosch]

Just one more thing, said Columbo:
http://en.wiktionary.org/wiki/bug#Verb

Joking aside, a map on a dogfight server can have at least two end conditions in addition to the time limit. One is that either side loses all planes, the other is that all their ground targets are destroyed. After either condition is met, a time out counter starts, typically ranging from 1 to 3 minutes from what I've seen. However, if the second end condition is met during this small time period, the time out counter is reset yet again.

I've seen this reset thing happen only once, and I can't think of any other explanation than two end conditions being shortly met one after another. I can't rule out some flaw in server/map settings either. Well, it's not too annoying.