Jump to content

SAS_Storebror

Members
  • Content Count

    1117
  • Joined

  • Last visited

Posts posted by SAS_Storebror


  1. I can definitely say that at the time or RRR'ing that IL-2 in my video, there was no damage added to it.

    The artillery shell coming in nearby is way before RRR starts and there's no other arty shell or anything else which could damage the plane after that.

    It's the RRR process itself that throws the plane in the air violently, and further throws it up a second time split seconds thereafter.

     

    :drinks:

    Mike


  2. Habu I've sent you the track (which naturally also holds the mission files) so you've got everything you need to make up your mind now.

    If you still think invisible debris should cause RRR zones to kill planes, then I'll simply give up on this issue.

    I've got enough of such "oh well, let's change the manual" reactions to bugreports @work, no need to waste my time on something similar when I'm longing for recreation.

    No hard feelings.

     

    :drinks:

    Mike


  3. Let me rephrase this a tad simpler:

    Debris should never cause RRR to turn into a plane destruction zone.

    Never ever.

    Let alone invisible debris.

    That on it's own is a bug to me and should be put on the list of things to fix, not on the list of things to deal with on the mission builder / player's end.

     

    :drinks:

    Mike


  4. Thanks for the feedback gentlemen but please enlighten me:

    If this is not a bug and any invisible debris could cause your plane to get completely destroyed from RRR'ing it, how on earth is a player supposed to know in advance whether a position is "good" for RRR or "bad"?

    I mean yes, you could specify things like "don't RRR inside shelter" or "don't RRR within 5 meters distance to a visible object".

    But in case of the video I've posted, there is no such thing.

    The plane's standing on grass, no other object nearby.

     

    And if invisible debris from artillery shells could cause this to happen, then in my humble opinion this is definitely an RRR bug.

    I think so because it's impossible neither to the player nor the mission designer to avoid it.

    For instance, as a mission designer I could put an RRR zone in the wilderness, with nothing else around it within a mile distance, and with no other actor doing anything with, in or to that zone.

    The next player who comes along and drops a bomb right in the middle of that RRR zone would render all these efforts futile because the debris of the bomb would make the RRR spot unusable for the remaining mission: Without any warning to other players, the RRR zone would turn itself into a killzone for anyone attempting to RRR there.

     

    Bug or not?

    I don't see how this could not be a bug.

     

    :drinks:

    Mike


  5. I have yet to see the dserver.exe crash again after re-enabling RRR a day ago, however right after re-enabling and testing RRR online, I've become victim of the next alleged RRR bug.

    See the video below, RRR happens at about 2:00 and 3:26 (same RRR event, two perspectives).

     

    Apparently each little part being repaired causes a little explosion to happen, with the first one throwing the poor IL-2 into the air violently and subsequent explosions throwing it around a little.

    Seconds before RRR happens, an artillery shell impacts about 20 meters off the plane (see thumbnail picture).

    This should have no impact on the RRR event, I'm just mentioning it so people don't confuse one with the other.

    The "explosions" seen at each RRR part being repaired are definitely not from any arty shell or the like, they're coming out of nowhere.

    Here's the sortie log: http://sas1946.rocks:8000/en/sortie/log/15756/?tour=1

    There's two damage events: No. 1 at 18:23:06 is from touching trees (that's where I lost my right aileron), No. 2 is the RRR event.

     

    I've got the track of this sortie so if devs need it, give me a shout.

     

    animated-new-years-eve-smiley-image-0004

    Mike

    • Haha 1

  6. On 12/14/2019 at 8:36 AM, Habu said:

    Storebror, do you have a mission where each time you use the RRR crash the dserver, i can have a look and try to run test with it.

     

    I don't have such a thing, but when I re-enable RRR on our training mission I expect it to start crashing about once a day again.

    All user reports indicated that crashes usually happened when either planes fell victim of enemy bomb raids or heavily damaged aircraft landed right into the RRR area (which is pretty small).

    I'll re-enable RRR, give it a try, and if the server starts crashing again (it didn't for more than a month now, never crashed since RRR was disabled, which was the only change to the mission) I will send you the mission file(s) (it's three of them, each with the very same effect).

     

    :drinks:

    Mike


  7. Thanks for the feedback and thanks for clarification.

    I totally agree, RRR is something we've been longing for a long time and I've been excited when I saw it's implemented.

    Even more so, I've been surprised to see that it's not only "not working as expected", but even killing servers.

    One of the more populated servers (TAW or WoL, can't remember exactly right now) disabled the feature right on day one because of this.

    And that's been told here.

    Which makes me wonder why none of the devs/testers seem to have noticed any of this before.

    Anyway... we tried to make it work for quite some time but eventually disabled the feature on our DServer as well.

    Not because of strict evidence that a certain reproducible action would yield to a server crash - the closest to being reproducible indeed was the major engine damage - but rather because the DServer crashed every other day or so when RRR was enabled, where it's yet to crash again since we disabled it more than a week ago.

     

    :drinks:

    Mike


  8. 6 hours ago, WWDriftwood said:

    Far as I know; Server has never locked up because of the RRR service truck.

    Interesting.

    I can assure you that the DServer does lock up.

    Did you host your multiplayer sessions from DServer.exe or did one of the players host them?

    With DServer, I never got to the point of locking up my (Client) game, the DServer always locked up before.

     

    :drinks:

    Mike


  9. Thanks for your feedback guys.

    Just to see what is what, I did a pretty simple test:

    Use a standard Halberstadt with standard loadout, 100% fuel, skill level "novice" (i.e. "low") in Quick Mission.

    Arras map, 1000m start altitude, head-on approach.

    For player plane, I chose each of the available planes in the set with ~30% fuel each, standard loadout.

    After starting the quick mission, I've turned on autopilot immediately and let AI fight against each other.

    10 of such sorties for each of the planes available.

    Result: The Halberstadt won each and every fight.

    No entente aircraft ever was able to defeat it. Never ever.

    The utmost thing that happened was that the Sopwith Camel sometimes scored 2 or 3 bullet hits against the Halberstadt.

    Each and every time, the Halberstadt gunner, despite being at "novice" level, humilated the entente planes in no time.

     

    :drinks:

    Mike


  10. Multiplayer :

    Choose any plane of your choice.

    Park inside RRR area.

    Let some other plane drop bombs on you or let artillery or tanks shoot you... Anything that causes immediate fatal damage does the trick.

    As soon as your engine gets killed, DServer locks up.

     

    :drink2:

    Mike 


  11. At the risk of becoming guilty of thread necromancy, could any of you FC experts enlighten me as to what the status of two seater gunners is?

    I've flown a couple of sorties recently and to me it seemed that nothing changed.

     

    For instance, I flew a sortie agains a Halberstadt with loadout set to "empty" and skill to "low", and five times in a row the Halberstadt gunner got me on first pass, regardless whether it was head-on, diving vertically on him, coming from below, 90° deflection or whatever I tried.

    Invariably, when I closed in at ~700-800m within the blink of an eye, my pilot got show, the engine got shot (usually oil leak) and the fuel tank got shot. All at once. Always, every time.

    I then set myself invincible and tried to attack the same Halberstadt offline, trying to kill the gunner.

    No chance.

    I've unloaded all 800 bullets of my brave Spad into the gunner's cockpit from less than 50 meters distance, to no avail.

     

    Is it just me or are the two seaters still UFOs?

     

    :drinks:

    Mike

    • Like 1

  12. On 10/28/2019 at 8:05 AM, SAS_Storebror said:

    Brief description: DServer.exe locks up for apparently no reason on Patch Level 3.201, 3.201b and 3.201c

    Detailed description, conditions: Random mission, DServer.exe starts flawlessly and keeps running for a while.

    All of a sudden, the DServer.exe process starts using 100% CPU power on one core.

    Players lose connection.

    The Server is still listed online, but players can't connect.

    Remote Console (RConClient) connection is still possible and the Server accepts all kind of commands and does reply correctly.

    DServer.exe Windows shows no change in SPS, Tick Delay and Tick graph anymore.

    Log listview still gets updated (you can see RConClient connection activity for instance).

    Clicking "File" menu is still possible.

    Selecting "Exit" causes the process to lock up completely, it can only be terminated manually using Task Manager.

    This issue got introduced with Version 3.201.

    We did not see any DServer lockups before (last was on 21st July 2018).

    Only change on Server side was that missions now use the new "RRR" feature.

    Additional assets (videos, screenshots, logs): Unfortunately there's nothing being logged in any logfile. All I can provide is screenshots of the issue, please find them below.

    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.

     

    To second my previous post, the issue doesn't seem to stem from RRR as lately DServer.exe crashed when nobody was flying on the Server.

    Would be nice if some Dev could take a look at this and/or give a hint how to avoid it, because right now the Server is offline due to crashes at 30%-50% of times and it's a real PITA having to look after the process every other hour.

     

    Lockup on November 02:

    1469886882_DServerlockup2019-11-02.PNG.7d542d5040af197311955a4ec776ca9e.PNG

     

    Lockup on November 03:

    871177886_DServerlockup2019-11-03.PNG.f989a7c8af633546b071fc3070833031.PNG

     

    :drinks:

    Mike


  13. Well the video... it's 5/10 at best.

    2/3rd of the video just explain to us that a bad or mediocre Demo kills sales.

    That's a no-brainer.

    I don't think we should worry about the Devs not being able to kick out a reasonably good Demo. They did so with ROF so it's not like they don't know what to do and how to do it.

    IL-2 Great Battles also doesn't fall into the 10/10 "must play" category.

    And that's not even the Devs fault.

    The game might be 10/10 (I think it's close, but rather 9/10), but we have to face the fact that CFS games are a niche market.

    As such, the target audience is small enough to make any effort to enlargen it turn into bigger sales numbers, even if the Demo is "only" on the same level like the game is.

     

    Of course it takes away Developer time.

    That's something we, as the customers, cannot judge correctly.

    James will have to sharpen a pencil and calculate it all the way through.

     

    :drinks:

    Mike

×
×
  • Create New...