![]() |
|
#1
|
|||
|
|||
![]()
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. |
#2
|
|||
|
|||
![]()
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 ![]() |
#3
|
|||
|
|||
![]() Quote:
![]() 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.
__________________
Find my missions and much more at Mission4Today.com |
#4
|
|||
|
|||
![]()
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. |
#5
|
|||
|
|||
![]()
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?
|
#6
|
|||
|
|||
![]() Quote:
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. |
#7
|
|||
|
|||
![]()
Here is another bug in p47s
![]() Last edited by shelby; 02-27-2015 at 02:35 PM. |
#8
|
|||
|
|||
![]()
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! |
#9
|
|||
|
|||
![]()
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 |
#10
|
||||
|
||||
![]()
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 |
![]() |
|
|