Jump to content

SAS_Storebror

Members
  • Content Count

    1196
  • Joined

  • Last visited

Everything posted by SAS_Storebror

  1. Du hast die Steam-Version Michael, da brauchst (und hast) Du keine Launcher.exe Viele Grüße, Mike
  2. 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: 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" Cheating could be detected, logged and reported much more precisely and easily. Probably there's many more benefits from such thing, so... why not? Mike
  3. It's not really gone (usually), but way less prominent. The main issue with clouds on max or "extreme" quality is the FPS impact. On my i5-9500k + GTX 970 rig @1440p I have like 50% FPS drop on missions using "heavy" clouds when max/extreme is set. Mike
  4. Bad ideas from my youth performed with my self-confidence today would be lethal Mike
  5. ...and the Arduino eats burgers. It's been a while since I saw one on sale in the local tool market. 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. Mike
  6. 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. 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. 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... 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. Mike
  7. 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. Mike
  8. 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) Mike
  9. Sorry to say Habu, but that reply of yours is a bit weird... 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... ...because leaving such mission running without an admin around, on a public server without password protection, is a no-go from my experience. 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. 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. 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. 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. 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. 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. Mike
  10. I had to refresh the page a couple of times, but finally it came up after all the 503 errors. Mike
  11. 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 Mike
  12. 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 Mike
  13. Stalinwood. Whereas the P-47 fuselage, heavy as it is, sometimes seems to consist of super heavy duty marshmallinium. Mike
  14. While I agree that for an MG 17 350 meters should not be an "extreme" range... ...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. Mike
  15. 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. . Mike
  16. Wild guess: The fact that the bomber was straight in front of him? Mike
  17. 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. Mike
  18. I think an i7-4770 CPU should be sufficient to run missions of reasonable complexity. Nevertheless, mission files in both versions (spawn and formation) have been sent by PM. Mike
  19. 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: 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. Mike
  20. 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. Mike
  21. 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. Mike
  22. 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: 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". 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. Mike
×
×
  • Create New...