Jump to content

SAS_Storebror

Members
  • Content Count

    1395
  • Joined

  • Last visited

Everything posted by SAS_Storebror

  1. Thanks a lot for your quick service once more Vaal. Works a treat, everything's fine again! Cheers! Mike
  2. I'm afraid there's a small glitch in 1.2.23. Just got this error: [2018.07.19 18:15:56] unexpected error Traceback (most recent call last): File "C:\Python3\virtualenvs\il2stat\il2_stats\src\stats\management\commands\stats_whore.py", line 15, in handle stats_whore.main() File "C:\Python3\virtualenvs\il2stat\il2_stats\src\stats\stats_whore.py", line 69, in main online_timestamp = update_online(m_report_files=m_report_files, online_timestamp=online_timestamp) File "C:\Python3\virtualenvs\il2stat\il2_stats\src\stats\online.py", line 24, in update_online data = parse_mission_log_line.parse(line) File "C:\Python3\virtualenvs\il2stat\il2_stats\src\mission_report\parse_mission_log_line.py", line 231, in parse data = atype_handlers[atype_id].match(line.strip()).groupdict() AttributeError: 'NoneType' object has no attribute 'groupdict' [2018.07.19 18:15:56] Lock 2384413112416 released on C:\Python3\virtualenvs\il2stat\il2_stats\file.lock Traceback (most recent call last): File "manage.py", line 7, in <module> execute_from_command_line(sys.argv) File "C:\Python3\virtualenvs\il2stat\il2_stats\.venv\lib\site-packages\django\core\management\__init__.py", line 364, in execute_from_command_line utility.execute() File "C:\Python3\virtualenvs\il2stat\il2_stats\.venv\lib\site-packages\django\core\management\__init__.py", line 356, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "C:\Python3\virtualenvs\il2stat\il2_stats\.venv\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv self.execute(*args, **cmd_options) File "C:\Python3\virtualenvs\il2stat\il2_stats\.venv\lib\site-packages\django\core\management\base.py", line 330, in execute output = self.handle(*args, **options) File "C:\Python3\virtualenvs\il2stat\il2_stats\src\stats\management\commands\stats_whore.py", line 16, in handle stats_whore.main() File "C:\Python3\virtualenvs\il2stat\il2_stats\src\stats\stats_whore.py", line 70, in main online_timestamp = update_online(m_report_files=m_report_files, online_timestamp=online_timestamp) File "C:\Python3\virtualenvs\il2stat\il2_stats\src\stats\online.py", line 24, in update_online data = parse_mission_log_line.parse(line) File "C:\Python3\virtualenvs\il2stat\il2_stats\src\mission_report\parse_mission_log_line.py", line 231, in parse data = atype_handlers[atype_id].match(line.strip()).groupdict() AttributeError: 'NoneType' object has no attribute 'groupdict' Please find the sample Mission Report files that triggered this error attached to this pos. Cheers! Mike Mission Report 1.2.23.zip
  3. Apparently yes. If only that bug would have been reported in the dedicated/moderated bug report threads, I would have seen it first hand and saved me searching for the same issue myself. All that cluttered noise in the bug report forum is really a nuisance, it renders that sub-forum 99% useless. Cheers! Mike
  4. Final update on that DServer.exe issue from my side: Looks like I've found the reason for this issue and lo and behold, it seems not to be as severe as it looked at first glance. Actually I could nail it down to one single trigger that crashes DServer.exe. It happens when you have an AI Pe-2 ser.87 at airspawn. Player planes are not affected and it seems like no other plane is affected either. For instance, changing the plane type to a ser.35 already fixes the issue temporarily. That's been a rough ride, but I'm glad that the issue turns out to be a rather small one. Whatever kicked out all the servers from the list, it seems unrelated to this particular issue. Cheers! Mike
  5. Alright, I've found the reason for this issue: DServer.exe crashes as soon as there's an airspawn of an AI Pe-2 ser.87 with blister turret. Tried that several times with different mission setups, reproduceable issue. Changing the same plane to a ser.35 one solves the DServer.exe crash. Player plane spawns are not affected (they seem to crash on player side). This definitely is a bug in 3.005. Cheers! Mike
  6. It's in the "Tools" Menu on the top menu bar, 6th entry from bottom.
  7. Is it just me, or is the whole Dogfight Server List more or less empty now? A second ago, my own Server was the only one on the list, now after 10 minutes a second server joined... Cheers! Mike
  8. That's a bit cryptic I'm afraid. As much as I understood the Mission Resaver was not updated. Trying to open the old *.mission files in mission Editor doesn't work either. The only thing that worked for me was to use the "resave all missions in folder" function of the mission editor. Cheers! Mike
  9. Let me add that from a simple look at the Dogfight Server List, you can see that this issue might be wide spread. Prior to 3.005 update we've had about 3-4 pages to scroll through the list on a Full HD Monitor. What's remaining now is slightly more than 1 page. Probably many Server Operators didn't even notice that their server crashed yet, and those who remain can just be happy that their missions don't contain whatever triggers this issue. I hope this will be fixed soon and not put on hold like many other bugs. Cheers! Mike
  10. Okay I must admit, on 2nd glance the newly introduced DServer bug that keeps crashing our Server isn't all that funny, see report here: That's a real show stopper this time.
  11. Brief description: DServer.exe keeps crashing about when first player spawns Detailed description, conditions: Random mission, DServer.exe starts flawlessly, keeps running until first player spawns. As soon as first player spawned, seconds later DServer.exe crashes. Additional assets (videos, screenshots, logs): See attached Screenshots, Event Details as follows: Log Name: Application Source: Application Error Date: 7/18/2018 5:56:13 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: not-your-business Description: Faulting application name: DServer.exe, version: 1.0.0.1, time stamp: 0x5b4e5540 Faulting module name: DServer.exe, version: 1.0.0.1, time stamp: 0x5b4e5540 Exception code: 0xc0000005 Fault offset: 0x0000000000140997 Faulting process id: 0xda8 Faulting application start time: 0x01d41eab8ac2dd7e Faulting application path: C:\Program Files (x86)\1C Game Studios\IL-2 Sturmovik Battle of Stalingrad\bin\game\DServer.exe Faulting module path: C:\Program Files (x86)\1C Game Studios\IL-2 Sturmovik Battle of Stalingrad\bin\game\DServer.exe Report Id: 66c6fc47-b234-49f8-bc84-22ed1c2df62b Faulting package full name: Faulting package-relative application ID: Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Level>2</Level> <Task>100</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2018-07-18T15:56:13.382448600Z" /> <EventRecordID>11493</EventRecordID> <Channel>Application</Channel> <Computer>not-your-business</Computer> <Security /> </System> <EventData> <Data>DServer.exe</Data> <Data>1.0.0.1</Data> <Data>5b4e5540</Data> <Data>DServer.exe</Data> <Data>1.0.0.1</Data> <Data>5b4e5540</Data> <Data>c0000005</Data> <Data>0000000000140997</Data> <Data>da8</Data> <Data>01d41eab8ac2dd7e</Data> <Data>C:\Program Files (x86)\1C Game Studios\IL-2 Sturmovik Battle of Stalingrad\bin\game\DServer.exe</Data> <Data>C:\Program Files (x86)\1C Game Studios\IL-2 Sturmovik Battle of Stalingrad\bin\game\DServer.exe</Data> <Data>66c6fc47-b234-49f8-bc84-22ed1c2df62b</Data> <Data> </Data> <Data> </Data> </EventData> </Event> Your PC config data (OS, drivers, specific software): Windows Server 2016, Intel Core i7-4770 @3.8GHz, 32 GB RAM, 2x2TB HDD (Raid 1), 1GBit/s non-clocked.
  12. As a player I must say that the quick arrival of new content is really amazing. As a server operator, I must say that the progress on the "bug hunting" end is rather disappointing though. Especially when it comes to things that have worked before and got broken with a certain update, it's rather disappointing to see update after update following thereafter, and the broken things just remain unfixed and untouched. For instance, Patch 3.0 introduced an excessive CPU usage of DServer.exe as soon as you have AI bombers on your dogfight mission, even more so when they fly in formation. This was not the case on Patch 2.012d. It got reported instantly but is unsolved to the date. Another example, Patch 3.0 changed the way payload limitations worked in conjunction with Server settings. Patch 3.001 reversed that change again, but this time it broke the ability to prohibit the "default" payload for planes. For instance, in 2.012d you could enforce certain bomb payloads on bombers and fighters, since 3.001 you can't anymore. Reported immediately after 3.001 came out, still unresolved to the date. As much as I understand the commercial aspect of having to keep the ball rolling with new content that attracts new players, as much I get a feeling that the quality control and bug fixing in particular are somewhat falling behind. All of this should not say that this isn't a great game. It definitely is, it has great potential and it's the future of the WW1/WW2 CFS genre, no doubt about that. Cheers! Mike
  13. Just for the record: If you have ever linked a Steam account to your IL-2 Sturmovik account, then it's just normal for the game to crash on login when you try to login directly (without Steam). Don't know whether any of you is using a Steam version, so I'm just saying... The game itself runs fine on Intel HD graphics with default settings right after installation. Not playable (needs extremely low settings and resolution on Intel HD), but not crashing either. This is also just for the record because prior in this thread there were doubts whether the integrated Laptop GPU could handle it. It can. If the game crashes without further notice, I'd first check for error logs or crashdumps. Look here: Windows Event Log Logfiles in the game's "data" folder, any of them. Crashdump belonging to IL-2.exe in C:\Users\<your username>\AppData\Local\CrashDumps Cheers! Mike
  14. Saw it, bought it, no time to play with it yet. Nevertheless, big thanks for this great new toy 😎 Cheers! Mike
  15. 1st class service, thanks a bomb Vaal. Just in time for my purchase of FC&TC 😉 Cheers! Mike
  16. I guess we need an update to reflect the newly available kites from Patch 3.005 😎 Not trying to push though. I know Vaal will be faster than light anyway 👍 Cheers! Mike
  17. Nice effort, thanks for sharing. I'm wondering how reliable that data is though. This for instance looks odd to me.
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
×
×
  • Create New...