Jump to content

SAS_Storebror

Members
  • Content Count

    1196
  • Joined

  • Last visited

Posts posted by SAS_Storebror


  1. Hi guys,

     

    How about adding the ability for DServer.exe to record TacView files?

    TacView's .acmi files are text files holding information about objects on the map, how they move and interact.

    It should be possible to generate all this data from DServer, and now that the game itself can do so already, it should be no big deal to port this functionality to DServer.exe

     

    Two big benefits from doing so:

     

    1. DServer.exe has the "full picture" of what's going on online, whereas each client's tacview record usually only holds what the client sees, i.e. is limited to it's "visibility bubble"
    2. Cheating could be detected, logged and reported much more precisely and easily.

     

    Probably there's many more benefits from such thing, so... why not?

     

    :drinks:

    Mike

    • Upvote 4

  2. On 6/19/2020 at 9:32 PM, raaaid said:

    we are electrical machines

    ...and the Arduino eats burgers.

     

    1 hour ago, raaaid said:

    a frictionless axle

    It's been a while since I saw one on sale in the local tool market.

     

    1 hour ago, raaaid said:

    the japanese research

    Leave me alone with the japanese research.

    I've gotta deal with 'em all day long, for more than a decade now.

    Trust me, handing a task to japanese researchers is like throwing a penny into a black hole in the hope of getting a dollar back.

     

    If that's your master plan, you're doomed.

     

    :drinks:

    Mike

    • Haha 2

  3. There's workarounds for many things, no doubt about that.

    The problem is the excessive complexity of such workarounds when a simple additional MCU could do the job.

     

    15 hours ago, Habu said:

    Randomise plane which is named in the plane of the pool, like you can do with different kind of plane, or activate Complex trigger which interact with the name of the random plane.

    Totally unrelated.

    What I'm talking about is an object link that gets generated at runtime, dynamically pointing back at the object that triggered the event/mcu.

    What you're proposing still requires individually spawned objects - that's a no-brainer.

    If I have 10 individual spawners, I can deal with each of them individually. Named or not.

    However if I have one single spawner spawning the same thing 10 times, then I have no way to isolate one of the spawned objects at runtime.

    That's the situation I'm talking about.

     

    15 hours ago, Habu said:

    Please re read what you wrotte

    This doesn't get us anywhere.

    If it makes you feel better: You are right and I'm wrong, your server is better than mine, bla bla bla... omfg...

     

    15 hours ago, Habu said:

    You can't perform all the action and AI you want

    Fact is with fake spawn I can have anything I want right now, and still have room for additional complexity.

    With formation spawn, current mission is too much (before you start to jump off the chair: For my server) already.

     

    This thread's title is "formation questions", it's been dealing with dynamically activated formations, and my result from lengthy attempts and research is that while it's possible to do it, it's not feasible for complex missions due to excessive CPU cycle impact.

     

    :drinks:

    Mike


  4. Ground attack... an endless pitty.

    Do you have wind on that mission by chance?

    That'll cause all kind of issues for AI in my experience.

     

    I've lately had two missions in my hands where AI acts completely out of bounds.

    First mission was a generated one from "Easy Mission Generator", with just a bit of wind on ground.

    A group of 8 Focke-Wulf was tasked to attack a group of 4 ships.

    What happens is this: All 8 Fockes line up in "line astern" formation, then they all dive on one single ship - straight down from starboard side of that ship, they all release their bomb when being like half a mile away, and all bombs hit the ship astern on the deck in exactly the same spot.

    That's precision... beyond imagination actually.

     

    Second mission is a hand-made one, with a group of two IL-2 1941 with two bombs and 8 rockets each.

    The planes approach a german airfield from the west.

    When reaching their last Waypoint, which is about a mile away from the airfield at 500m altitude, they receive the task to attack ground targets, anywhere on the base, with high priority.

    The result is: The IL-2s fly level and pass the base in the south, letting AAA shoot the crap out of 'em, and when being a mile to the south-east of the base, they make a slow right-hand turn (so to say, to the south, away from the base again), then line up for an attack at the base in south-to-north direction.

    Everything looks fine, the planes start to dive at a random object on the base, and then... nothing!

    It looks like a perfect dive-bomb attack run, but the IL-2s are pacifists!

    They don't shoot their guns, don't shoot their rockets, don't drop their bombs.

    Instead, they'll go around the base again, start the next attack run, do nothing again, repeat.

    Until being shot out of the skies.

     

    The very same pattern, with a pair of Focke-Wulfs attacking the russian base on the other side of the map, works perfectly fine.

    The Fockes go to the last waypoint, then go full-throttle dive attack at the base, drop bombs, break off and unload their guns at random targets until all ammo is gone.

     

    Weird?

    Weird.

     

    It's IL-2 GB AI ground attack at it's best.

    Unpredictable.

     

    :drinks:

    Mike


  5. 9 hours ago, Beebop said:

    As I understand the priority settings;

     

    Plane AI:

    Ace - I will give you everything coded into my AI brain.

    High - Sir, Yes Sir!  I will do exactly as commanded without fail.

    Medium - I will do what is asked but if I detect any enemy or if they attack I will clean their clock(s) first.

    Low - Sure thing boss...hey, something shiny, let's take a look.

     

    Waypoints:

    High - DO IT Maggot!

    Medium - Do your job but protect yourself and be aggressive.

    Low - I'd like you to do this but, meh, whatever.

     

    Eh... no, not quite.

    From my experience:

     

    Plane AI:

    Ace - I will give you everything coded into my AI brain. (i.e. AI will do the job, and they'll do it as perfect as possible to them)

    High - Sir, Yes Sir!  I will do exactly as commanded without fail. (i.e. AI will do the job reasonably well)

    Medium - I will do what is asked but I might just fail to achieve the goal. (i.e. AI will try to do the job, but the outcome is questionable)

    Low - Sure thing boss... I will miss the target though. (i.e. AI will try to do the job, but repeat mistakes endlessly)

     

    Waypoints:

    High - DO IT Maggot!

    Medium - Do your job but protect yourself. (i.e. AI will temporarily abandon orders if being attacked themselves - feeling like is enough sometimes, e.g. when an enemy plane makes a head-on approach nearby)

    Low - I'd like you to do this if you don't see anything shinier en route. (i.e. AI will continuously watch out for enemies en route and simply fight the first one that seems legit)

     

    :drinks:

    Mike


  6. Sorry to say Habu, but that reply of yours is a bit weird...

     

    1 hour ago, Habu said:

    No, the airfield is called administrator, but any players can use it, as the reload of the mission. I have the same goal as you, that player don't need any admin to manage the AI they want. I have mission where player activate AI from airfield.

     

    If all players on your server behave properly: Fine for you.

    My experience is that whatever element you hand out to "random guests" on your server which opens a way to abuse anything on the mission: They'll abuse it.

    For instance, I can definitely expect to find the first "funny" guy who'll have nothing better to do than continuously restart the mission (and thereby drive away all other users) within half a day max. if I'd implement such "administrator" airfield.

    And that's what I meant when saying...

    8 hours ago, SAS_Storebror said:

    You are relying on an Admin to actually operate the mission

    ...because leaving such mission running without an admin around, on a public server without password protection, is a no-go from my experience.

     

    1 hour ago, Habu said:
    8 hours ago, SAS_Storebror said:

    * Player Joined Server

    I don't understand what you mean.

    As simple as this: An MCU that triggers when a player joins the server.

    Is that really too hard to understand?

    Currently you've got no way to know when a player connects - the earliest trigger you can get is when the 1st player spawns.

     

    1 hour ago, Habu said:
    8 hours ago, SAS_Storebror said:

    * Player Disconnected

    I don't understand what you mean.

    Same as before, the other way around: An MCU that triggers when a player disconnected from the server.

    That way for instance you could count the number of players currently on the server, e.g. in order to keep a mission running as long as players are around, postpone nightly service tasks on the server, restart a mission 10 minutes after last player disconnects, ... there's endless use cases.

     

    1 hour ago, Habu said:
    8 hours ago, SAS_Storebror said:

    * Player Despawned (e.g. finished mission or got destroyed)

    I don't understand what you mean.

    Seriously?

    An MCU that triggers when a player finishes his flight, be it at will or forcibly.

    Can't see what's not to understand here.

     

    1 hour ago, Habu said:
    8 hours ago, SAS_Storebror said:

    * Real randomization (current implementation partly yields repeatable results)

    No, most of my mission (maybe in that one i provide) use randomise for the opponent.

    Congratulations.

    Our whole training mission is random!

    And since it is, and has been for more than a year already, we have sufficient experience with timer triggers of 50% probability to say loud and clear:

    The results repeat if you keep triggering a limited number of such triggers in the same order, same time.

    In the beginning of a mission, where there's no system-dependent random tick time delay (yet), this can be very annoying.

    That's another use case for a "Player Joined Server" trigger as it would automatically randomize the timing part and thereby even turn the "predictable randomization" of our current game into an almost real one.

    Let me say this straight and clear: If you have never experienced predictability in your randomization, then either it has a random time element beforehand, or you simply didn't watch it for long enough.

     

    1 hour ago, Habu said:
    8 hours ago, SAS_Storebror said:

    * Dynamic object references, e.g. a plane triggers a check zone and the check zone can object link back to that plane, whichever it is

    Use the complex trigger with a name unit. Have a look on my mission on the Administrator logic. The trigger is activated by a specific plane.

    You missed the point - I know how to use complex triggers with named units. Our training mission utilizes that feature quite a bit.

    What I'm talking about are real dynamic object references.

    Say I have one AI plane with a spawner and trigger that spawner 10 times in a row.

    Currently, the result is 10 AI planes of which I can't distinguish one of the others at mission editor level.

    What I'm talking about now is an object reference which, if let's say one of the 10 planes enters a check zone, would dynamically link back to that plane - just that, and none of the other nine planes that belong to the same spawner.

    Currently impossible to do.

     

    1 hour ago, Habu said:
    8 hours ago, SAS_Storebror said:

    With "real formation" pattern (activated on demand), the server gets overloaded when the 1st player spawns and it keeps being overloaded all the time.

    As you can saw with the graphic of my dserver, that's not the case with my server.

    Your test was performed with limited AI (missing bug issue) and no action on Tank and WW1 zone.

    It's fine that in your case an i7-4790k can barely deal with the load, in my case the i7-4770 can't.

    The fact that your server is on the "green" side of the edge can hardly count as a "solution" to the issue, can it?

    If it could, then we'd have no issues with DServer performance at all anymore.

    You "just" need an i9-10900k, liquid nitrogene cooling and 6GHz clock rate and everything's fine and dandy for some time to come.

     

    :drinks:

    Mike


  7. 10 hours ago, JV69badatflyski said:

    pushing the801d to1.8ata

     

    Sounds a bit out of bounds to me.

    Even with the latest late war "Leistungssteigerung", where the boost pressure regulator ran in a kind of "uncapped overdrive" mode using a simple valve, the pressure in the low blower gear was limited to 1.58 ATA and in the high blower gear it was 1.65 ATA.

    I've seen a couple of mentionings of this "Leistungssteigerung" where apparently people made a typo and quoted 1.8 ATA where instead it should read 1.58 ATA - it becomes apparent when the "1.8 ATA" guys state that the engine provides 2050hp power in that mode - that's the power at 1.58 ATA.

     

    Link for german readers, others might want to use Google Translate: https://www.deutscheluftwaffe.com/archiv/Dokumente/ABC/m/Motoren/BMW/Leistungssteigerung/BMW 801 D Leistungssteigerung.html

     

    :drinks:

    Mike

    • Like 1
    • Thanks 1
    • Upvote 1

  8. Thanks for your reply and the Test Mission @Habu.

    That's one massive training mission...

    Well, yours and our approach are similar in some aspects and completely different in others.

     

    Similarity for instance is that you are using the "Spawn/Fake Formation" style for AI planes too.

    That's what we stick to for the time being as well.

    The activation of "real" formations proved unfeasible in our tests due to server load inflicted from "not yet used" AI formations.

     

    The main difference probably is that you are relying on an Admin to actually operate the mission, whereas our training mission is supposed to run unobserved, "free for all".

    That's why we offer all flavours of IL-2 GB at the same time, so players can individually spawn WW1 planes, WW2 planes and Tanks, just as they like/wish.

    The individual parts of the mission (WW1/WW2 planes, Tanks) are activated "on demand" - i.e. when a player spawns in that part, or when a player plane reaches the tank battle zone - the latter is for combined air/ground operations, and it's by design that these parts can run in parallel.

    Actually all 3 parts can be active at the same time, depending on player spawn behaviour.

    With "fake formation" pattern this is no issue, the server's tick delay at maximum load stays well below 18 and usually is at around 15 when players are on the map.

    With "real formation" pattern (activated on demand), the server gets overloaded when the 1st player spawns and it keeps being overloaded all the time.

     

    To summarize what we've found out in this thread:

    • You can activate AI formations using the "activate" trigger.
    • All commands go to the formation leader only - including the "activate" link, "formation" commands and waypoints.
    • All events will be issued from each plane of the formation individually, e.g. "OnPlaneBingoBombs", "OnPlaneDestroyed" etc.
    • Formations eat CPU cycles even if they're inactive, the amount of CPU cycles consumed depends on the amount of inactive formations and the amount of check zones, proximity triggers and the like.
    • It's really sad that our oh-so complex Mission Editor lacks basic features like:
      * Spawn Formations
      * Player Joined Server
      * Player Disconnected
      * Player Despawned (e.g. finished mission or got destroyed)
      * Real randomization (current implementation partly yields repeatable results)
      * Simple if/then/else logic gateways
      * Variables of simple types (boolean, int, float)
      * Dynamic object references, e.g. a plane triggers a check zone and the check zone can object link back to that plane, whichever it is

    :drinks:

    Mike


  9. 2 hours ago, ICDP said:

    Are you telling me those movies where the hero shelters behind an upturned wooden table while being shot at from two metres by an automatic weapon are LIES? 😄

     

    Stalinwood.

     

    Whereas the P-47 fuselage, heavy as it is, sometimes seems to consist of super heavy duty marshmallinium.

     

    :drinks:

    Mike


  10. 4 minutes ago, ACG_Onebad said:

    350 meters is definitely not an extreme range by any means for a machine gun.

    While I agree that for an MG 17 350 meters should not be an "extreme" range...

     

    5 minutes ago, ACG_Onebad said:

    It's close range in terms of MGs (as far as infantry goes) where it can still kill and penetrate stuff with no problem.

    ...here I would say "it depends".

    In my service time we've been using the Heckler & Koch G3 and as far as it's combat range is concerned, the maximum specified combat distance was 400 meters (and that's where sight scale ended, too) and the maximum distance we've been shooting at in training was 300 meters - and at that distance, "precision" was a word from foreign language and successfully killing and/or penetrating anything "with no problem" was a tad out of bounds.

     

    :drinks:

    Mike


  11. 6 minutes ago, unreasonable said:

    Then perhaps not having an aerodynamic penalty for ball round hits is a pragmatic design decision, which probably applies to all calibers of ball and AP, not just .50 cal.  IE it is not a bug,  but working as intended.

     

    If you want to argue that the interpretation in the game is far from reality, you need an external document or similar as a reference and an offline test that demonstrates that game results are different. Same as for FM issues.  Otherwise all you have is an opinion

     

    In that case, please forgive me when I voice my opinion that such a design decision would not be pragmatic, but bold.

    Saying "HE rounds slow you down by 30 mph and AP just polished the surface" is like saying "Any bomb with a weight less than 500 pounds will cause damage to unarmoured vehicles only, and if the weight is less than 250 pounds it will only damage it if the driver has blonde hair".

    You will hardly find evidence for the opposite, 'cause the fewest attack reports will include the drivers' hair colour, yet human logic dictates that it's @unreasonable.

    .

    :drinks:

    Mike


  12. As mentioned earlier, the Tick Delay of 7 only happens on the real mission, not on the synthetic test mission.

    The real mission does have check zones, complex triggers etc., however none of them is active at mission start.

    All mission items are in deactivated state until the 1st player spawns, nevertheless the CPU toll of having disabled formations added strikes pretty hard on the real mission.

    And of course the check zones are dynamically activated/deactivated on demand, as well as AAA - most of them have check zones with duty cycle logic attached so even if they're active, they will only check like 5% of times.

    But anyway, at the time when the CPU load kicks in, each and every element of the mission is just sitting there deactivated, waiting for a player to spawn.

     

    :drinks:

    Mike


  13. 9 hours ago, MattS said:

    Just had a German 7.9mm machine gun wound me severely through the armored glass windscreen of the P-47...from 350m away.

     

    Plausible?

     

    Offline or online?

     

    In real life, it should not have happened.

    T.O. No. 01-65BC-1 "P-47 Thunderbolt Pilot's Flight Operating Manual" Section I "Description", 1. "Airplane", d. "Pilot Protection" (1) says:

    Quote

    ARMOR. - Front and rear armor protection sufficient to withstand U.S. .30, German .312, and Japanese and Italian .303 (7.7mm)-caliber fire by direct right angle hit is provided for the pilot.

    47.thumb.JPG.e70a1996888328434ad6f7189ae5aa39.JPG

     

    The reason I'm asking whether it happened online or offline is that if it was offline, I would expect the game to handle the armour protection correctly.

    Planes do contain definitions for parts/sections with armour protection and bullets calculate their energy loss while travelling through them, or the ability or inability thereof.

    However if it happened online, then what you saw isn't necessarily what the Server thought would have happened.

    You might have seen a bullet hit your pilot straight upfront, whereas the server thought it hit you in the side of your fuselage and you got hurt from shrapnel.

    Online, damage results are simply unpredictable at the moment as the Server has a mind of his own, and everything summing up to his conclusions is carefully hidden from us mortals.

     

    :drinks:

    Mike


  14. I'm not worrying about a tick delay of 7.

    I'm worrying about that idle tick delay of 7 - when nothing, really nothing happens on the mission.

    No actor being active.

    No checkzone being active.

    Nothing at all.

     

    The "normal" mission had a tick delay of appr. 15 while actively running, which means that an additional 6 ticks delay just from having the formation objects waiting on the map would push the DServer over the edge.

    It's sad that the game is wasting CPU cycles on inactive mission objects.

    It's even more sad that we cannot simply spawn formations.

    And the fact that you cannot pre-check such issues (see differences in results from test mission vs. "real" one) just makes matters worse.

     

    This unpredictable behaviour mixed with illogical limitations on our otherwise so versatile and complex mission editor is something that can drive you nuts as a mission maker at times.

     

    :drinks:

    Mike

    • Upvote 1

  15. Disregard my last statement about number of MCUs.

    The synthetical test with 500 flights of 4 bombers in "deactivated" waiting state showed no issues.

    20 such flights on a real mission though causes the Tick delay to raise from 1.0 to 7.0 and the CPU load from 3% to 30% accordingly.

    Dammit.

    The work of a whole week just going to waste.

     

    :drinks:

    Mike


  16. I think there's a misunderstanding here.

    The 5s timer will do the trick to have all planes ready to receive the formation command order, no doubt about that.

    However, as @Jaegermeister rightfully pointed out:

     

    17 hours ago, Jaegermeister said:

    before you trigger a Command Formation MCU, your formation will use the default Trail formation. If you have gone to the trouble to set them up in the formation you want them in, you should activate the Formation command 1 or 2 seconds after the Activate Command to keep them from jostling around in formation

     

    If you ever watched your formation coming to life, you will have noticed that they do some pretty weird moves in the beginning, and that's exactly because initially they'll try to align in default trail formation before the "real" formation command gets issued.

    Therefore, the longer it takes until the formation command is being received, the more the formation becomes disturbed.

    Not a big deal if your planes are well below ceiling altitude and well below top speed, but if your reach either of these, it takes a whole lot of time to realign the formation correctly after this "dance".

     

    13 hours ago, Jaegermeister said:

    I would suggest you limit the number of MCUs you use to the minimum for everything you do. Excess commands just slow things down.

     

    I would have subscribed to that statement up to version 3.x, but the reason I'm reworking a large mission from "single respawn" to "formation activate" right now is because with version 4.x, the sheer number of MCUs doesn't seem to matter anymore.

    Or to put it bluntly, if it would matter, PWCG missions won't work.

     

    I've tested this with a sample mission where one version consisted of one single flight of 4 bombers being activated at mission time, and the other version had 500 more of these flights (with all their internal activation/bomb run/destruction logic etc.) - all of them deactivated of course.

    The 2nd version of that mission topped out at a tremendous 20MB mission file size, but the performance (CPU load, ticks, SPS) was just the same.

     

    :drinks:

    Mike

×
×
  • Create New...