Jump to content

SAS_Storebror

Members
  • Content count

    382
  • Joined

  • Last visited

Community Reputation

121 Excellent

1 Follower

About SAS_Storebror

  • Rank
    Member

Contact Methods

  • Website URL
    https://www.sas1946.com

Profile Information

  • Gender
    Male

Recent Profile Visitors

691 profile views
  1. SAS_Storebror

    [BUG REPORT] 20mm HE Ammunition

    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
  2. SAS_Storebror

    [BUG REPORT] 20mm HE Ammunition

    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
  3. SAS_Storebror

    Thread to gather your suggestions

    Correct. Actually it's rather the DServer log that suffers from this.
  4. SAS_Storebror

    Thread to gather your suggestions

    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
  5. 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
  6. 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
  7. SAS_Storebror

    Empty payloads bugging in MP

    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
  8. SAS_Storebror

    Multiplayer

    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.
  9. SAS_Storebror

    Yak series Dive and high speed behabeour too good?

    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
  10. SAS_Storebror

    Clear Timer mcu

    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
  11. SAS_Storebror

    Clear Timer mcu

    ... 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
  12. SAS_Storebror

    Clear Timer mcu

    Thanks Jim, will test and report either tomorrow or on Monday. Cheers! Mike
  13. SAS_Storebror

    Clear Timer mcu

    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
  14. SAS_Storebror

    Taxi to Takeoff

    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
  15. SAS_Storebror

    Taxi to Takeoff

    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
×