Jump to content

SAS_Storebror

Members
  • Content Count

    1329
  • Joined

  • Last visited

Everything posted by SAS_Storebror

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. Correct. Actually it's rather the DServer log that suffers from this.
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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.
  16. 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
  17. 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
  18. ... 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
  19. Thanks Jim, will test and report either tomorrow or on Monday. Cheers! Mike
  20. 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
  21. Okay, found it out myself. Reason was that funny AI picked another fake airfield because it was 2 pixels closer. That airfield had no chart attached, so AI decided to ... yes ... what? Scramble with single engine planes right from parking position, and do that weird dance with multi engine planes. Funny. Cheers! Mike
  22. Hi guys, Did any of you ever try the "Taxi to Takeoff" functionality lately? Maybe even with multi engine planes? I've just tried it, and what I see seems... disappointing, to say the least. A Bf 110 spawned, shut it's canopy, turned on engine No.1 and... ...throttled up full power on that engine. Donut. Throttled back again. Throttled up. Donut. This repeated like 5 or 6 times, until engine No.2 was up. The AI decided to start rolling by applying full throttle again. Donut. Plane ended up in opposite direction of the Taxi path, so... full power again. Donut. This repeated like 10 times, until the plane hit a splinter box. Left wing fell off, tail fell off, engine stopped. Okay... so I thought the plane would now despawn, which would trigger the "OnDestroyed" Event and give AI another chance, but... No despawn. The plane keeps sitting dead like that. What a bummer. AI messes up any mission script completely like that. Am I missing something or is this "Taxi to Takeoff" just not working? Cheers! Mike
  23. Exactly. Precisely. Thank you so much for putting the whole truth about these endless debates in just two sentences. I'm subscribing each and every word of it. Cheers! Mike
  24. Make that "one of the many possible interpretations" and I fully agree. Evidence is what's missing here all the time. Cheers! Mike
×
×
  • Create New...