I believe that your rightfull irony wasn´t caught. :roll:

I took KG26_Alpha's "warning" as being ironic, rather than serious.

But, if the moderators believe that my DM testing is spamming, then I'll stop.

Hehe just some "fun".......

When someones mistakes a He111 for a Me410 after so many "bug reports" posted.....

It was a polite "poke" that's all :)

here is another bug in tb3's cockpits
http://s26.postimg.org/6jdm84t95/201...2_19_52_13.jpg
http://s26.postimg.org/4sul6nbq1/201...2_19_52_55.jpg

IMHO it's not a bug, it's only a problem. The solution is called 'elevator trim'. ;)

what do you mean?

This is level flight.

You are looking down at the gauges at an angle not at eye level



http://s26.postimg.org/6jdm84t95/201...2_19_52_13.jpg

The plane's position is not necessarily horizontal in a horizontal/level flight. Much depends on speed and trimming. E.g. at slow speeds the plane is usually in a 'nose-up' position in order to keep altitude.
There is only ONE speed at which a plane can fly BOTH level AND in a horizontal position. If your speed is lower, you'll fly slightly nose-up; if your speed is higher, you'll fly slightly nose-down.

I see... Thanks for explanation sniperton

Can you DT please make a fix so that the kill is credited even after the player's aircraft has been destroyed. For example, in offline campaign it is frustrating to ram a bomber and not have your kill scored only because your plane hits the ground before the bomber does.

Attribute the points to the pilot not the aircraft,
the pilot has to successfully bail out and parachute to the ground ?

Yes, that's what I mean, as soon as the player's plane is destroyed, kills are not credited though the player is still alive (bailed out). Can it be fixed by attributing points to the "pilot" not his plane? Thanks a lot!

Hello

I have a question regarding bridge-kill statistics - in Quick Missions if I hit and destroy a bridge I get a certain amount of ground vehicles-kills and bomb hits statistics goes up, but not the brdge-kills one.
I apologise if this question has been raised before & thank you for any pointers as to solving this problem.

I've proposed these ideas before, but they bear repeating:

There's an even simpler and better way to credit kills. In the arcade mode, when a plane takes fatal damage, it issues a "Pilot Killed" or "Bailing out" message to the AI.

I've never understood why those messages shouldn't also instantly trigger credit for a kill. It seems like an incredibly simple bit of coding.

This fix would also solve the annoyance of not getting credit for a kill when an enemy plane crash lands. After all, the act of crashing automatically triggers a "Bailing out" message, since all the plane's engines are rendered inoperable.

If you wanted to get slightly more detailed about kill claims, you could also automatically credit the player with a "probable" kill after an AI plane takes enough damage to generate a "Return to Base" message, and a "damaged" claim after the player scores any damage on an enemy.

Allowing credit for probable and damaged planes then opens the way for realistic kill claiming based on nationality.

Japanese pilots could get full credit for "kills" which any other air force would consider to be "probables," or even for "damaged" planes.

Germans and most other air forces would get no credit for shoot-downs behind enemy lines unless there was another friendly plane close enough to observe a crash (the "confirmed kill" message in the game).

Planes equipped with gun cameras would get credit for enemy planes which break up in air or where the crew bails out while the player is shooting at it.

Allowing credit for damaged or probable kills would also allow simulation of the rather complex German kill credit system described here:

http://forums.ubi.com/showthread.php...ocedure-Forums

In game terms:

Single-engined fighter - no partial kill, 1 "kill" for a Asschuss (shoot down).

2-engined bomber - 2 "kills" for a shoot-down, 1 "kill" for a Herausschuss (Separation = Damage severe enough for a RTB message), 1/2 kill for a Endgueltige Vernichtung (Final damage = kill on plane which already had enough damage to generate a "RTB" message). Auschuss supersedes points for Herausschuss or Endgueltige Vernictung.

4-engined bomber - 3 "kills" for a shoot-down, 2 for a herasschuss, 1 for a Endgueltige Vernictung. Auschuss supersedes points for Herausschuss or Endgueltige Vernictung.

For units where pilots didn't get individual credit for their kills (like many US Navy units), you just tally up the number of kills/probables/damaged planes the player's formation racked up and divide by the number of planes in the formation.

Finally, while it would require more book keeping in campaign mode, and favors realism in favor of fun, you could also have "delayed kills".

Most air forces didn't award credit for kills immediately. Instead, credit was only awarded after intelligence officers got sufficient proof to credit the pilot with a kill. Until then, the pilot would have to settle for a "probable" kill.

This meant that, unless there was a crash site on friendly territory that civilians or ground forces could easily inspect, credit for a kill might be delayed for months or even years. (In a few cases, pilots only got credit decades after the fact, once investigators finally discovered the crash site, or historians finally corroborated one side's loss records for a particular time and location to kill claims made for the same time and place by the other side.)

In game terms, this might mean that you only get credit for kills scored on a previous mission after a later mission, or you might never get credit for a kill.

On the other hand, you might also get credit for a kill that was actually just a "RTB" result. Even in the best run air forces, fighter pilots typically overclaimed by a 2:1 ratio, and gunners might overclaim by a ratio of up to 10:1.

+1

Taxi to Takeoff Still not working Consistently
 

Althought I like this feature, it still is plagued with too many inconsistencies.

Taxi to Takeoff works for any OnlyAI flight;
Taxi to Takeoff in SP mode is great for humans if you use the overhead "guide" graphic (otherwise, it's not really needed).

But for OnlyAI flights, in SP or COOP, the delay tag is INCONSISTENT!

Below, I have a flight where Plane1 starts tagged to a stationary plane. This flight is AI only.



[r0100_Way]
TAKEOFF_005 172819.92 133867.21 0 0 &0
TRIGGERS 0 0 5 0
TAKEOFF_005 172763.92 133838.48 0 0 &0
TRIGGERS 0 2 5 0
TAKEOFF_005 172678.29 133898.70 0 0 &0
TRIGGERS 0 2 5 0


Nine times out of ten, this flight will NOT delay 2 minutes at waypoints 2 and 3. Or, they will delay at the WRONG waypoint.

What gives with this feature and can we have a more definitive instruction set than what came with the readme? As it's too ambiguous or the feature is broken... ?

Can TD give an official response to the delay in the takeoff_005 waypoint delay setting for AI planes?

Aviar posted this last year, too:

http://forum.1cpublishing.eu/showpos...3&postcount=14

When a plane gets a see-through hole, markings may be partially drawn on top of thin air. Pictured is the left side of a RAF BuffaloMK1, and there are gaping holes in the fuselage, with the interior and a small area of green grass visible, and the marking QV is fully drawn.

http://i61.tinypic.com/2yyr4ab.jpg

This is not exactly a bug, maybe more like a limitation of the engine. For comparison, a direct hit once completely removed a red star from a P-39N's wing, and it didn't look fake. Workarounds might be a lot of work, though, since markings are displayed in various places and sizes depending on plane, squadron, number and air force.

But there's more! The mirrors of P-51C-NT and MustangIII - you guessed it - don't block the sun.

Hello DT, the Fw 190 D-9 1945 engine overheats and dies quickly in a power-dive above 700km/h. It's like the auto-pitch mechanism doesn't know what to do at super high speeds. More details in this thread: http://forum.1cpublishing.eu/showthread.php?t=228928.

It seems that the jettison stores - command doesn't work with the wonder weapons X-4, Hs 293, Fritz X or Bat bomb. Normal bombs/rockets can be jettisoned even when standing still on a runway, so I don't think airspeed is the issue.

Missing years and text
http://s26.postimg.org/n09f2tpcp/201...9_22_59_25.jpg

http://s26.postimg.org/6b7z6wsrd/201...9_23_01_00.jpg

I don't agree with this.

You have to get your plane back to base so the "guncam footage" can proved you killed something.

Missing mirror in the mc200 series cockpit

Here is a bug in hurricane models when you gear up or down the wheels
http://s26.postimg.org/ux332jfkp/201...0_18_07_06.jpg

This is completely irrelevant.
First, what "guncam footage" was ever used by a Zero or an I-16?
Second, in the game you still get a score if you ditch your plane in sea and your guncamera drowns.
Third, I just rammed a B-29 and I had my wingman as a witness but I didn't get a kill because my plane crashed before B-29 did.
So I pointed out a simple problem of scoring system employed by the game's engine. I believe this should and can be fixed.

In Il-2, the problem is that the kill is credited to the plane and not to the pilot. If the attacking plane crashes before the attacked plane does so, then the kill is lost for the surviving pilot who in RL could still claim that kill.

What, specifically, is the bug you're mentioning...?

I hope to see it better from this screenshots

http://s26.postimg.org/sme7pujkp/201...1_13_13_47.jpg

http://s26.postimg.org/idlqk0vix/201...1_13_18_50.jpg

Agreed. Different nations used different standards for kill claiming, and for nations where kill claims were hard to verify, it could take years, or even decades, to get confirmation for a kill.

In some ways, as frustrating as it is, the current kill scoring system is incredibly generous since it usually counts planes that crash as a result of damage that isn't immediately fatal. Realistically, those kills would only count as "probable kill" or "damaged" claims.

Yep. I've pointed out one simple way to fix this problem. Other folks have also made good suggestions. It seems like a simple programming fix, so no reason to to do it.

* Assign kills to the pilot, not the plane.
* Assign kills as soon as a plane catches fire, break up, has a pilot & co-pilot kill result, or when the AI prompts the crew to bail out.
* Instantly assign kills when a plane ditches or force lands (i.e., anything but a wheels down landing at an airfield).

the same on FW and tempest models
http://s26.postimg.org/qv3mdwtqx/201...2_13_06_44.jpg

You mean the asymetrical retraction of the landing gear? Probably intentional and historically correct. Don't know for Hurri+Tempest, but for Fw I'm 95% sure, and AFAIR also Zero and Bf109.

Yes, seems to be so:
https://www.youtube.com/watch?v=93SkZqXFWg4

No, he's talking about the clipping. Part of the gear (actuator) pokes through the wings briefly during the up/down animation.

The bug it is outside of the cockpit in the wings

http://s26.postimg.org/yde1efna1/201...3_17_18_26.jpg

http://s26.postimg.org/wo9jk3wyh/201...3_17_18_37.jpg

http://s26.postimg.org/y216few7t/201...3_17_18_45.jpg

http://s26.postimg.org/fwjmnm7bt/201...3_17_18_56.jpg


That's right

There's quite a few aircraft with those clipping issues with the landing gear.

Also the see through wings at wind angles is an age old problem. When asked about it years ago, Oleg said it wasn't an easily solvable issue. Something to do with the graphics engine. It's not aircraft specific although its certainly worse or more visible on some than others.

Missing mirror? on p51c and mustangIII

http://s26.postimg.org/m4ni0z995/201...5_19_45_29.jpg

http://s26.postimg.org/jbuagy8wp/201...5_19_46_05.jpg

Here is a bug that appears when the wings of p51b are hit
http://s26.postimg.org/bqaczpo61/201...9_13_11_20.jpg

Also, with one or two other aircraft (don't remember which), part of the main wheel clips through the upper surface of the wing after the gear is fully retracted.

Didn't know that about the Hurri's and FW's gear mechanism, though...

ntrk recording lag style stutters
 

Anyone noticed online style lag stutters when playing ntrk recordings of offline (ie QMB) fights? I didn't notice these odd stutters (eg recording playback skips quite a few frames like in online lag) before v4.12.2m - but I could be wrong.

My actual dogfights are very smooth averaging 120+ fps using the the built-in fps meter.

When I playback stock recordings like The Black Death, the stutters don't seem to appear. So the stutters seem to have been introduced by v4.12.2 perhaps?

It's a shame because I can't make nice smooth videos anymore.

Has anyone figured out how to fix this problem via some Win 7 settings?

Problem with P-51 CG
 

There is a problem with the fuel loading on the Mustang. This I believe effects the CG and causes bad handling. In practice the 85 gal tank behind the pilot was used first, if it was loaded at all. Only on long missions was it used, then pilots switched to it after take off, to burn it down before switching to drops if used. In this game fuel is loaded into rear tank first and the handling shows it as it would in real life. This should be changed to make this airplane handle like it would if properly loaded.
This is my first post since this game came out.
Bill. ( 352FG_PZ_X)

IL2 is AFAIK incapable of shifting CoG. And as this was asked for before at least n-times and has not been changed since, I would assume its not easily fixable.

That aside, Mustang handles quite okay when not selecting full fuel load and has still enough left to stay in the fight for quite some time. And then it behaves okay, and boy it is fast. If it only were armed with Hispanos...

50% is an hours flying approx

Yep! We all have to remember that the fuel gauge isn't real and it doesn't represent fuel tanks that are full or empty individually. Just one big tank really.

A Mustang Mark IA with the four 20mm Hispano cannons would be a nice addition (and a P-51A and a A-36 Apache :cool:).

This is more of an issue with damage modeling. One fuel leak can quickly drain your tanks dry.

While dynamic CoG is either beyond IL2's limits, or would require too much re-coding to be feasible, having fuel shut-offs for damaged tanks might not be unreasonable.

This wouldn't even need a command in the game; it could be assumed as part of the DM as a reflexive "damage control" action on the pilot's part. For example, if you get a hit in a fuel tank that holds 85 gallons of gas, the fuel leak could automatically stops after you lose 85 gallons (or 85 gallons * whatever percentage of fuel you had when the leak started).

On the FW190 that's not a bug. It was an indicator that the wheels were up.
It's a small rod, that shows that wheels are efectively down/up.
There is an anecdote about one of this rods being jammed, and the pilot arriving to wrong conclusions not knowing of this plane problem and executing a belly landing believing that his gear was still up.

Actually it's a nice detail.

- When using the Go-229, the pilot model's head tilts way too much up and down. It seems that the X and Y axis are reversed - if you look up/down in the cockpit, the pilot external model looks slightly left/right. When you look all the way left and right, the pilot head tilts very, very unnaturally!

- Another .ntrk recording bug: if you select a B-239 as an opponent in the QMB, set map as Normandy1 and look at the B-239, it sports an unpainted, metallic skin. However, if you record this as a .ntrk and watch it, it has the default FAF brownish/green paintscheme instead. This bug appears at least when the B-239 is Finnish, and it doesn't seem to appear on the Crimea map.

The rear gunner of the B-29 gets decapitated when he is killed.

Hmm... ISIS operated flak? :roll:

When flying the yak-7 series I've noticed that the center of gravity of the plane is still too much backward (the camera is centred on the antenna pole) and that they seem to overheat to fast IMO. I've also noticed the problem of COG on the Pe-8 where it is behind the wings.

THAT will mess with the ESRB rating! At least if it's intentional. . . :O

SB bomber cockpit lights flicker
 

Instrument lights and cockpit lights both come on when selecting lights. Map reading lights are whitish and seem to flicker due to prop blur effects.
Also bombsight article has no brightness control.

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

Test: QMB, scramble, Brewster. Set pitch to 40 or 60, then hit 'Auto'. You'll cook the engine. (Hurri can take off, but with huge difficulties, and with overheated engine.)

Generally, after returning to manual mode, you always find prop pitch set to where you left it before hitting 'Auto'.

Mixture control appears to be working similarly.

Can anyone confirm who has these assigned to axes? (Unlike throttle, which works correctly, these are assigned to buttons in my config.)

Thanks

Craters
 

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.
[IMG]http://ist3-1.filesor.com/pimpandhos...Craters_01.jpg[/IMG]
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.
[IMG]http://ist3-2.filesor.com/pimpandhos...Craters_02.jpg[/IMG]

I don't know if this is an issue.

Thank you very much.

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.

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

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...

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.

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

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

+1

Optinal HUD message of actual trim setting
 

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

Yes please
+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...)

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.

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:

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.

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...d-speed-Forums

here is a small bug like the p40b/c bug
http://s26.postimg.org/5318gqh09/201...6_13_19_36.jpg
http://s26.postimg.org/5h2kgc13t/201...6_13_19_57.jpg

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

P-38 Airspeed Indicator wrong
 

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...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.

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.

Here is another bug in p47s
http://s26.postimg.org/ou92xbqmx/201...7_14_15_12.jpg

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!

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

Eventlog error with Bridges and Bridge Destruction
 

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

Hi,

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

~S~

one more bug
http://s26.postimg.org/shjdafo2h/201...4_16_23_00.jpg

IL2 1946 4.2.12m yellow cursor disappears after Important Windows Update
 

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

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.

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.

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

Track Playback Issue 4.12.2
 

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!

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 :)

What patch?
There's a patch?

It's been over a year. Good lord.

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).

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!

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.

http://forums.oce.leagueoflegends.co...chmentid=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 :)

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.

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 !!

:)

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.