Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by SAS_Storebror

  1. Du hast vergessen zu erwähnen, dass Du die Steam-Version von BoS hast. Und Du hast vergessen zu erwähnen, dass Du nach dem Update per Steam ein Login gemacht hast und dabei die Steam- und Web-Accounts zusammengeführt hast. Danach muss man sich per Steam einloggen, der alte "direkte" Login funktioniert dann nicht mehr. Stand aber auch so in der Ankündigung. Viele Grüße Mike
  2. Thanks for your statements Zacharias. Please don't get me wrong, I'm more than happy if we can find an explanation for why the Yak isn't suffering from Over-Revving, or particularly why it isn't suffering from it in comparison to other e.g. Luftwaffe aircraft. I do have the feeling that the russian engines might have wider limits, but I'm also sure that this will be put into question by Luftwaffe fans much more than it is already by myself, that's why I'm trying to shed light on this matter from many different directions. You've mentioned the piston speed as one possible criteria for how much an engine is "living on the edge" already at rated RPM. We can compare the mean piston speed for several engines easily to get an idea of how much this comes true - the max piston speed is slightly out of range as we'd need the rod length in this case as well, and I don't have it at hands for many of "our" engines. Nevertheless, the mean piston speed should tell us something already, and it's simple math: Pistonspeed=2⋅ Strokelength⋅ RPM This gives us the following mean piston speeds for instance: (Jumo 213E = 17.88m/s <-- not in IL-2) M-105PF = 15.30m/s (Yak-1) V-1710-F3R = 15.20m/s (P-40E) Merlin 45/50/66 = 15.20m/s (Spitfire Mk.V/IX) DB 605A = 14.93m/s (109 G) DB 601E = 14.40m/s (109 F) Jumo 211F/J = 14.30m/s (He-111, Ju-88) DB 601Aa = 13.34m/s (109 E) I'm afraid that judging by the piston speed, from the set of compared IL-2 inline engines, the russian Klimov should be the first to suffer severe damage as it features the highest average piston speed at rated RPM already. And to top it off, basically all the "red" inline engines seem to be living more on the edge than the "blue" ones, this only changed with the high-RPM Jumo 213. Cheers! Mike
  3. I get what you want to tell, and I'd like to believe, but I don't know what's backing up your statements. Basically what you're telling is that a WW2 piston engine will easily manage a 10% over-revving without taking damage, and all of this not just for a second or two, but also for a minute or more. In my book, this statement might apply to certain engines (the Allison maybe?), but probably not to all of them. I'd rather love to know what really applies to the M-105 than comparing apples and oranges (M-105 and V-1710). For instance on the contrary of your statement, I've just read a translated report from the U.S. who captured a Ta-152 H-1 from MDMW on the Erfurt airfield on 11 May 1945 (interesting sidenote is that this plane wasn't ever supposed to be there, but it was). The report has been prepared and approved by: Charles E. Thompson, Capt. John O. Gette, Jr. Lt. Col., AC., Chief of Section George C. Mc Donald, Brig.Gen. USA, Asst. Chief of Staff A-2 The plane in question was using a Jumo 213E engine, rated at 3250 rpm. The report clearly states "Under no circumstances the engine may be operated at more than 3300 rpm, otherwise it will overheat quickly and become blocked." That's a 1.5% margin. Just saying. Cheers Mike
  4. Source? I mean... just because Tractor pulling guys run it @4500 and engine modifiers tune it to the 4000's range, it doesn't mean that it was designed like that. And even if so, it doesn't tell whether the M-105 can take a 10% overspeed as well. I could, on the opposite, state that Lycoming has 5%/10% overspeed limits on all their engines (https://www.lycoming.com/content/service-bulletin-no-369-q) and if you exceed 10%, regardless how long, you've booked an engine removal + disassembly + complete overhaul. Cheers! Mike
  5. I've just faced the same issue on a friend's system yesterday. 2 hours fighting against Antivirus, Firewall etc., when in fact it was just this "2nd attempt" thing. I have tried several different systems with my account now, and 1 out of 4 shows the same behaviour. Every time I start the game, I get the dreaded network error message first, and on 2nd attempt it works. Would be great to know the basic reason behind this (and maybe even a solution...), but for now I can personally deal with the workaround too. Only thing that I'm afraid of is that IL-2 might lose a couple of users that way, because my friend was about to throw his game DVD into the bin already - a new user simply cannot know that he has to ignore the error message on 1st login and simply click login a 2nd time, so he has to think that the whole game just isn't working at all. Cheers! Mike
  6. Why Do you post this twice? Will we see a third thread with 5 exclamation marks soon? There's a dedicated and moderated thread for bug reports like this one: You will have to take the time and format your bug report accordingly, but with a little luck it won't just vanish in the common background noise that way. Cheers! Mike
  7. That of course works. It does for me as well. Launching the game from Steam works and you don't need to login anymore once you have completed the Account Merge procedure. What I was wondering about were certain reports about users being able to run the game without Steam (i.e. directly from IL-2.exe), either after or without the Merge. After the Merge (which I have performed on my account already), the game crashes to desktop when I run it without Steam. I guess that's what is supposed to happen, even though for me it's a sad thing, but sh*t happens. Without the Merge, official description was that you'd only have access to the game content bought directly from the website, but apparently, according to a couple of reports from different users, this is not the case (yet?). If I knew that before, I would have skipped the Merge and run IL-2.exe directly instead. But I didn't know, and now there's no way back. Cheers! Mike
  8. If that means that BoK will eventually become available on Steam, which is important for quite a few other members here, then I can deal with the hassle of having to have Steam on all Systems I'm using BoX on. Cheers! Mike
  9. Up to that point, this is the normal "Merge Accounts" procedure and it works for me too. I can start IL-2 from Steam without issues. This is the part that does not work after the merge anymore - at least for me. Starting IL-2.exe and logging in manually with E-Mail and Password gives a 10-second wait followed by a CTD. Cheers! Mike
  10. Nothing to argue against VP Modpack if WW2 is what drives you most, but HSFX? Why bother with something that's EOL for long time? Furthermore, "don't bother with BAT" sounds somewhat mean. Even if you are into WW2 only, BAT holds almost anything that's available in the 1946 world for you, and no one forces you to load any other module but WAW. The only thing you spend "on top" is a few Gigs HDD space for the other modules, but that's definitely worth it. Cheers! Mike
  11. Same for me, after the merge, manually logging in to IL-2 directly crashes the game. I guess it's supposed not to work anymore after the merge. Cheers Mike
  12. That's roughly what I'm suspecting as well. And if it's mainly a blast wave effect caused by the thin-walled Minengeschoß, then we have to remember that blast waves are getting reflected by surfaces like plane's metal skin, so the effect would even be smaller. Not trying to conclude anything, just saying. Cheers! Mike
  13. At the risk of telling complete nonsens (read: correct me if I'm wrong): Assuming a direct hit, I would expect all kinetic energy from a shell to be absorbed by the plane that got hit. However, the explosive energy would be distributed evenly in 3 dimensions. As the shells don't have no delayed fuze (?), this would theoretically mean that at least (depending on the hit point, could be more) half of the explosive energy would not "hit" the plane, but would be wasted into free space. In numbers, the destructive energy compared here, as listed in post 1... Minengeschoss = 138847 ShVAK = 39920 Hispano = 98461 ...would change to... Minengeschoss = 84514 (-39%) ShVAK = 34158 (-14%) Hispano = 74399 (-24%) This would still fail to support the test results, but at least point into their direction compared to where we're coming from. Cheers! Mike
  14. Correct. Actually it's rather the DServer log that suffers from this.
  15. Type of improvement: Multiplayer Explanation of proposals: Multiplayer In DServer.exe, please change logfile creation code from Windows API call "fopen_s" to "_fsopen" and enable shared read access to the logfile in order to give dedicated server operators a chance to see what's going on in realtime. Benefits: Bughunting, Cheater detection, Stats creation etc... everything would be much improved and could happen "on the fly" and not just when the mission ends like it is now. Cheers! Mike
  16. Is that true? I'm wondering because from a DServer operator's point of view, I'm used to have SPS and Tick Delay values. If SPS (Simulations per Second) falls off the normal 50.0 value by just 1.0, I see that the Server would start issuing "overloaded" warning messages to players. Same if the Tick Delay exceeds 20. 50 Simulations per Second would mean that all logic branches are executed once every 20 milliseconds. Assuming that "Tick Delay" is in milliseconds, it would fit perfectly: 20ms Tick Delay would let the game fall off it's tick rate by one full Simulation, which would trigger warnings. Therefore I always assumed that as long as the system is not being overloaded, it's safe to say that ticks fall within 40ms (- 20ms to +20ms, both extremes to be on the safe side), actually most probably even within 21ms. Vice versa, on a system being overloaded, anything can and will happen, so that's out of scope somehow. I would not expect any Tick I'm waiting for to take a second or even more to come. Cheers! Mike
  17. Hm... I guess we can expect the next BOS/BOM sale to give 66% off on both, which would make them cheaper than your offer. Not arguing, just saying... Cheers! Mike
  18. It's not quite that "empty" payloads cause such issue, it's much more that currently, regardless whatever you do, the payload at index 0 (the "default" payload) will always be available. This happens for all planes and it happens no matter what you do. Proper Bug Report has been posted here: Cheers! Mike
  19. Brief description: Default payload is always available in Multiplayer regardless payload/mod restrictions (Version 3.003). Detailed description, conditions: When you limit available mods and payloads on Multiplayer, regardless what settings you choose, the default (index 0) payload will always be available. In the attached sample you see an Fw-190 A-3 limited to mods 1 and 2 (SC-50 and SC-250) and payloads 1 and 2 (4xSC-40 or 1xSC-250 accordingly) in the mission editor. Server uses custom realism, Lock Payload and Lock Modification are both enabled. Nevertheless as you see in the second screenshot, it's possible for players to deselect all bombs and fly with "default" index 0 payload that way. The same comes true for any other plane, as reported elsewhere already. Additional assets (videos, screenshots, logs): Attached please find screenshots showing the issue: Your PC config data (OS, drivers, specific software): Windows 10 Pro 64 Bit (Fall Creators Update), Intel Core i5-2500K, Nvidia GTX 970, 16GB RAM, game on SSD.
  20. Agreed. Attached you can find a track of a dive test with the Yak-1 Series 69. In the beginning of the dive, the governor manages to keep the engine within the 2700/2800 rpm regime, but eventually when speed increases further (and probably the governor has reached "max coarse" setting), rpm increases beyond gauge limits (probably slightly above 3000). After losing all control surfaces, the plane recovers from dive by itself, coming up at ~550 km/h with the engine up and running just normal. This shouldn't be the case. The engine should be dead meat with pickles at that time. Cheers! Mike Yak-1 Series 69 Dive Overrev Test.zip
  21. True that Jim, and thanks for keeping track of this. That "restart at 0" behaviour was something I've learnt from your resettable timers. Thany you very, very much for these useful tools. Would be worth providing as a group for download. Cheers! Mike
  22. ... and here's the promised feedback: It works like a charm! Thanks so much Jim! Everything's fine and dandy now. I've put a reminder into the Mission Editor Manual for myself to re-read the precise usage notes about counters and triggers again after a couple of time, because not all of their features are quite intuitive. For instance, I wasn't aware that a timer MCU would restart at 0 when you trigger it again, whereas in order to pause and resume it, you can use the Deactivate/Activate Triggers. Also it's always good to remember the difference between a 0-second timer and a self-resetting "1" counter: In deactivated state, the 0-second timer will act as a "blocked link" between MCUs and will ignore all signals it receives while being deactivated, whereas the counter will act as a "hold" link which, if it gets triggered while being deactivated, will fire once being reactivated. Cheers! Mike
  23. Thanks Jim, will test and report either tomorrow or on Monday. Cheers! Mike
  24. Sorry for resurrecting this thread. I've just stumbled upon the same issue where I need a resettable timer (or something of that kind). Background of this is that I'd like to create an online mission where random planes spawn on ground, taxi to takeoff and leave the airfield. A first test showed that basically this works fine, however AI doesn't avoid collisions with other planes on ground if they don't belong to your own formation - and in my case they don't, because it's 4 individual planes which could spawn at any time. So the idea was to use a check zone MCU at first TAXI waypoint, so once the first plane spawned and received it's Takeoff command, all further Takeoff commands will be put on hold until the first plane reached the first TAXI waypoint. This will put enough space between the taxiing AI planes so they don't run into each other. However, due to unforeseeable factors (vulchers, player planes running into AI planes etc.) it might happen that an AI plane gets stuck between Spawn point and first Taxi point. In that case, I'd like to give way for the next AI plane to taxi to takeoff after a certain time. That time is roughly the maximum time it could take for the furthest AI plane to taxi to TAXI waypoint no.1 (the one with the checkzone trigger) from the time when it received the Takeoff command. This can easily be 2 minutes. So... the resettable timer would need to run for 2 minutes or even longer. I've tried JimTM's Timer Reset version 2 (I don't need no pause or resume), but the problem is that at the time when e.g. the first AI plane reached waypoint 1, the second will start to taxi and I need to restart the timer. At that time, the timer already has e.g. 1 minute elapsed. It has been "resetted" using the "IN Reset Timer" input, and then it has been restarted by using the "IN Trigger Timer" input again. However the result is not that it will fire after 2 minutes now as intended, but already after 1 minute - which is because the internal timer was active already from the previous "IN Trigger Timer" input I guess. The question now is: How to really reset the timer? It seems like the internal timer, the one that is responsible for the timeout, simply doesn't reset. Cheers! Mike
  • Create New...