The Groups Sharing Corner

[JG7_X-Man]

On 7/9/2020 at 4:07 PM, =SqSq=Civilprotection said:

I have another module which I think is polished enough for posting here. This time I have a proxy based respawning flak system:

 

Dude! You just saved me hours of work! Thank you!

[=SqSq=Civilprotection]

@JG7_X-Man I hope you get a lot of use out of it!

[=SqSq=Civilprotection]

Hello again, I have some more things to share. I have a couple of spawns for people to take a look at.

 

Scramble Field:

 

This is the more simple of the two modules. This is an airplane spawn which is proximity activated. On mission start, the airfield is locked. When a plane from a selected coalition flies within 10km of the field, the spawn activates. When planes of the activating coalition flies out of proximity, the spawn becomes locked again. I typically place the spawn directly adjacent to an airfield runway, and planes spawning are set to have their engines running already. I tend to only place interceptors in these fields (p-38, 109 K4, Spit mk. IX w/ 150 octane, etc.) Often I remove the majority of the fuel from planes spawning at the scramble field to make the most of their rate of climb. I would recommend to anyone who uses this module to include a handful of planes only (4-6 planes), and give said planes a relatively low replenish time. Those are just my best results personally.

 

As for the colors-

 

Green: Mission start logic, locking the field at the start of the mission.

Blue: This is the proxy system, and is similar to that within other modules I have posted.

Aqua: is responsible for activating the airfield when an enemy flies within range.

Red: is responsible for deactivating the airfield when an enemy flies out of range.

Yellow: The airfield itself.

 

I don't know how much demand there is for a module such as this, but let me explain why I made it. I have never liked server rules that dictate you cannot attack players on the ground (although I understand the reasoning behind those rules). I wish that there was more of a trend to include player airfields among legitimate mission targets. The Scramble Spawn, in conjunction with my integrated air defense system (posted previous), are aimed to be a more organic deterrent to attacking airfields than an externally enforced rule. If nothing else, it is a good example of how I set up my mission logic.

 

The next module is significantly more complicated, but works largely in a similar way. Hopefully I can post enough pictures, but without further ado, "TankSpawnSimplex."

There is a lot going here, so I'm going to try showcase the most significant sub-assemblies lest I run over the max file size.

 

So this is a tank spawn, if the name didn't give it away. Ownership of the spawn is controlled by a central flag located at the mouth of the spawn. When a coalition that does not control the spawn closes to within 300m the spawn locks until they leave, are removed, or capture the spawn for themselves. I made three versions of this module: Complex, SuperComplex, and Simplex. Simplex is the only one I feel comfortable posting at this time, and incidentally, it is the easiest to talk about.

 

Colors-

Blue: static object logic which changes the alliance of the static objects according to the coalition that controls the flag.

Aqua: The source outputs from the central flag.

Yellow: The complex logic controlling the proximity shutdown and ownership of the spawn.

 

This is the central flag logic, and is the source of all of the input signals.

 

colors-

Aqua: inside are the flag, the "German Out," and "Russian Out." The output timers are linked to the various input timers that are the source for the other sub-assemblies.

Navy: German output linked with German input

Maroon: Russian output linked with Russian input

 

This is the Main logic module. It is almost completely symmetric, and consists of the spawn, a German half, and a Russian half. For brevity, I will only discuss the Russian half.

 

It's a mess admittedly, but some of it should look familiar by now.

 

colors-

Aqua: This is pretty much the same proxy system that I have been using in all of my proxy modules.

Green: This is the proxy governor. Depending on who owns captures the flag, it disables or activates the proxy system as a whole.

Yellow: These are the inputs that take signals from the Central flag, and pass them along through the rest of the system. When a German signal is sent, the German input disables Russia's proxy system. When a Russian signal is sent it activates and primes the Russian proxy system.

Red: Changes the owner of the spawn to Russia as dictated by the direct output of the flag. 

Fuchsia underline: Because Russia starts with ownership of the flag, their proxy system must be started on mission start. This is the only additional element that Russia has over Germany.

 

Last bit (and the easiest). These are all the static objects. The command behavior changes their allegiance depending on who owns the flag- simple.

 

Congratulations! You've made it to the end!

It's a lot to take in I know, but hopefully I made it a little easier than it would have otherwise been. I'm uploading both groups in the same .zip Enjoy!

Spawns.zip

As always, questions, problems, praise; send it all my way

Cheers!

[Hamaha15]

Egg-Timers for mission builders

 

Hello, a quick one: two simple stopwatches which may be useful for mission builders when timing is required. No sophisticated rocket science, however, you can save working time if you use them instead of creating new ones from scratch. One runs from 0 to 60 seconds and the other one from 0 to 31 minutes.

 

Cheers

 

Timer.zip

Edited July 29, 2020 by Hamaha15

[TP_Jacko]

On 7/28/2020 at 5:53 PM, Hamaha15 said:

Egg-Timers for mission builders

 

Hello, a quick one: two simple stopwatches which may be useful for mission builders when timing is required. No sophisticated rocket science, however, you can save working time if you use them instead of creating new ones from scratch. One runs from 0 to 60 seconds and the other one from 0 to 31 minutes.

 

Cheers

 

Timer.zip 6.23 kB · 4 downloads

That soubds neat idea will taje a look

[Real_NBD]

Hello,
I'd like some feedback on a group I've been working on. It's a historically "accurate" german heavy flak battery with spawn/despawn logic at 10km or so.

 

6 subgroups, 1 for spawn logic, 4 for gun platoons and 1 for the command post. Important targets (guns, ammo dumps, vehicles) are german, other destructibles neutral. Has a few explosive effects as well. 

 

Spawn logic has the guns and vehicles spawn when an allied aircraft enters 10km of them and despawn when they leave. Searchlights turn on after sunset. Gunners are a mix of high and medium AI as I felt this is the most appropriate for heavy flak (it's useless otherwise).

 

Each heavy gun platoon has 2 heavy flak guns, and one of them has a command post attached to it. There are 2 light 20mm flak squads that would be deployed in the main threat direction to cover from wild weasels or ground threats, and to top it off a command platoon with some logistics attached to it.

 

This is a type of unit that would be deployed on the rear echelon at operational level, for example an industrial site or a logistics center could have 3-10 of these batteries protecting it. As the war progressed, the exact composition of the battery would have changed (both due to combat/resources and organizational changes) so this is just a single possible configuration. In actuality the gun platoons should be geographically quite separate (500-1500m) from each other and everything should be more dispersed than here, but hey, it's something.

 

The motivation behind this group is the abysmally unhistoric deployment of AAA units in the current online servers (not that SP is much better either...). I'd like to do other units for both sides later on but let's start here. BTW, is there a way to make the camo nets and dugouts less visible? I thought their purpose was to conceal, not advertise. They look atrocius in-game at the moment 

 

 

HeavyAABattery_German.7zip

Edited September 1, 2020 by NoBigDreams

[Real_NBD]

Part 2 of historically reasonable units,

 

A Soviet light AA regiment circa 1942. Made out of 3 batteries, each with 4 61K guns and many machineguns. A small logistics and command element is included with one of the batteries.

 

This type of unit was the mainstay of Soviet frontline anti-aircraft firepower, and it was deployed everywhere for the whole of the war with every possible other unit in all imaginable configurations. Finding original sources on the actual organization and tactical use of different units seems to be difficult, so any help is appreciated. I'm quite confident though that this group is a reasonable estimation. I'm certain these units were often split into separate batteries, which would then be subjugated to different units, such as armor and artillery. On 1 famous occasion one of these units, "manned" mostly by volunteer women, defended an airfield at Stalingrad against an overwhelming German motorized force, and was all but destroyed after causing massive losses to the attackers.

 

Gameplay-wise, I changed to static vehicles and gave the main ammo dugout some nice explosive effects. All units spawn/despawn in a staggered fashion with 6km or so Axis aircraft detection range.

 

No idea if anyone finds these interesting or useful but I'm going to do at least the most common AAA units of the war, hoping for feedback  (and waiting for the 40mm Bofors gun ) 

 

LightAARegiment_61K_Rus.7zip

Edited September 8, 2020 by NoBigDreams

[Hamaha15]

Thanks.

 

An US study on Soviet AAA organisation, doctrine and development from WW II through the Cold War era can be found here:

 

https://apps.dtic.mil/dtic/tr/fulltext/u2/a166753.pdf

 

The study covers in detail the air defense of Moscow in 1941 and draws the setup of AAA units during the Stalingrad siege.

 

Cheers

[Real_NBD]

Going on with spending my free time on creating random historical units in GB;

 

I ran into TM 30-430: Handbook on USSR Military Forces: Chapter III, Field Organization from US War department, 1946. I knew these handbooks existed for Ze Germans but for the Soviets it's equally comprehensive! Inspired by this and some fine Russian wheat products, I made a Soviet medium tank regiment, circa early 1944. These units were AFAIK the most common armored battalion-sized unit of the war, and they operated both independently and as parts of mechanized brigades.

 

The group is split into 4 Tank companies, of which 2 are deployed in a "loose" defensive formation (500x500m), 1 in "tight" formation (250x250m) and 1 in reserve/maintenance (250x250m). Attached to 1 company is the HQ and maintenance company (500x500m), and 1 medium AAA battery (72K) is protecting the regiment. Most vehicles are static, though I went ahead and made some mobile so they swap positions (should be easy enough to adjust/remove this if anyone wants to use these for anything)

 

I couldn't possibly include all trucks, MG:s and all equipment that this kind of unit should have while staying within my arbitrary geographical bounds, but the main stuff should be there, including the 2 kitchens 

MedTankRegiment_Rus.7zip

Edited September 15, 2020 by NoBigDreams

[=SqSq=Civilprotection]

@NoBigDreams This is some very interesting research. I'm curious to see how you plan on working it into the game.

[Real_NBD]

Next up, a light non-motorized AAA battery from the blue side.

 

3 platoons of single barrel weapons and one with 4 barrel devices. Searchlights, accommodation and some details for each. These would be deployed on targets that ain't so mobile, like logistics and command centers, heavy artillery positions, airfields etc etc. 

 

Platoons are deployed in 500x500m, 1000x500m and 1x1km blocks. It should be noted that even the 1x1km spacing is too close to be effective. I'm sure the guns were sometimes next to each other like this but realistically they should be spaced as much as their range allows. Oh well...

 

Its very interesting to note that a single German light battery has almost equal firepower to a Soviet AAA battalion!

 

On 9/16/2020 at 10:05 PM, =SqSq=Civilprotection said:

@NoBigDreams This is some very interesting research. I'm curious to see how you plan on working it into the game.

Well I have no idea what I'm going to do with these but I hope some MP admins or mission makers find these helpful or at least get some inspiration to make their ground units more historical, realistic or at least tactically reasonable 

I've just made these as an excuse to study history and practice using the mission editor 

LightAAABattery_Ger.7zip

[=SqSq=Civilprotection]

In light of the latest major update (4.501), I have seen a lot of complaints by bomber-jocks that the new ease of visibility has turned, or will turn the game meta toward massive fighter battles over fighter&bomber strategic bombing. I just want to say that while I welcome the new changes to spotting, I understand this new frustration. It seems to me that there are two problems compounded together: 1) that it is now too easy to find and intercept bombers which makes those missions suicide missions, and 2) that it is too difficult to organize sizable bomber flights with fighter escort. I would never suggest that we return to the pre-patch spotting, but there are definitely ways in which multiplayer mission makers can address that second issue-- the ease of inter team communication.

 

The challenge is to encourage random players who do not know each other to work together. VOIP is essential. Discord and Teamspeak are excellent community and coordination tools. However, they can only reach as far as the pilots who are actively using them. SRS is a fantastic new addition which can reach every player in the server... as long as every player remembered to launch the program before joining the server. In game text chat absolutely can reach every player, but not everyone is following the chat or even has it enabled, so it's easy to miss vital information. The last method of team communication I see frequently are the text overlay updates triggered by specific events-- 'X objective has been attacked, move to defend it.' But such notifications don't exactly help to coordinate a team response.

 

There is one avenue of communication which I see seldom used; the map screen. The map screen is the only tool in the game that can display current information, and is frequently checked by all pilots. While perhaps it cannot convey as complex information as that over VOIP or text, it can communicate symbolic information to the whole team and it is the best solution to tie together large bomber formations and escort.

 

Broadly players need to be able to see on the map when a friendly bomber force is collecting at an airfield. So, the first thing I would like to share is a logic assembly for a 'parking indicator.'

 

Each spawn point for an airplane as a "pressure plate" to see if a friendly plane is occupying the space. The red arrow indicates the direction that the airfield is facing, while each of the colored boxes indicates the location of the 'pressure plates." If a plane is occupying the space, a symbol appears on the map. If the space is empty, or the plane moves out of parking, the symbol is hidden/removed. pretty simple right?

 

Lets take a close look at how the module works:

The red section is the heart of the system. Two 'Check Zone' triggers overlap and are constantly searching to see if a plane from a specified coalition enters or exits the zone. Activation logic is in blue, and deactivation logic is in yellow. What actually shows up on the map is in purple-- deactivated by default, it becomes visible when a plane enters the zone (spawns), and becomes invisible when the plane roles out of parking. The position of the symbol on the map can be moved literally anywhere, though I would recommend keeping it within a reasonable proximity to its companion airfield. I won't be uploading this file because it's an old system that I made when I was first getting into the editor (I could make something much nicer now), and because of the other alternate option.

 

Option 2: Use a spotter. It's so simple guys-- throw a fake vehicle just behind the the spawn so that it doesn't interfere with spawning aircraft. Then, make it indestructible, and give it the 'spotter' ability (spherical) with a radius that encompasses all of the parking positions. Any friendly player looking at the spawn will be able to see that "oh, there are three bombers rallying. I think I'll join them as a bomber," or "that's a pretty large formation about to take off. I think i'll fly escort for them," etc. etc.

 

What frustrates me is that this is such a simple helper which could have been implemented at anytime since the release of BoX but has been overlooked.

 

Thank you for coming to my TedTalk. Cheers o7

[Real_NBD]

Next up, a German artillery regiment. Includes 3 105mm batteries and 1 150mm battery with 12 guns each, with varying amounts of LMG:s and logistical and command elements attached. Each battery is in a different configuration, geographically 1000x500m or 500x500m, dug-in and ready to fire. There was one of these units for each infantry division in the Wehrmacht, but I'm sure it was often split into batteries and deployed where fire support was required the most.

 

It's quite interesting to note how this unit is entirely horse-drawn, something that is quite hard to imagine today 

ArtyRegt_Ger.7zip

Edited September 27, 2020 by SCG_NoBigDreams

[Beebop]

On 5/31/2020 at 4:36 PM, Hamaha15 said:

Eager beaver - building the dams

 

Hello, dams added to border the Eder-, Hennesee-, Moehne- and Sorpe-reservoirs. Using the FMB inventory the result isn't fully accurate but a credible approximation. Now let's wait for the Mosquitoes...

 

Save the downloaded Group-files to your ...\data\template folder and import them into your mission by the File/Import From File... menu. This way all items will be positioned correctly.

 

Enjoy

 

Dams_Eder_Hennesee_Moehne_Sorpe.zip 4.03 kB · 39 downloads

 

 

Are these dams destructible?  I've had not luck so far.  Even when I make then Linked Entitles and send an OnDamaged/OnKilled Message I get nothing even after a direct hit with an 1800lb bomb.  There is also no visible damage.  Are "Grounds" objects immune to damage?

[Sketch]

Yes, as far as I know, ground objects do not take damage.

[SYN_Vander]

20 minutes ago, Beebop said:

Are these dams destructible?  I've had not luck so far.  Even when I make then Linked Entitles and send an OnDamaged/OnKilled Message I get nothing even after a direct hit with an 1800lb bomb.  There is also no visible damage.  Are "Grounds" objects immune to damage?

 

"Grounds" objects have no damage model. Also a number of "Buildings"  objects have no damage model, often historic buildings.

Edited October 9, 2020 by SYN_Vander

[Sketch]

Can confirm. Ground objects don't take damage. 

 

 

 

Here's the test mission if you so desire.

 

Ground Objects Mission Test.zip

 

Edited October 9, 2020 by Sketch

[Beebop]

DRAT! 

I thought so but then I still have lots to learn about using the ME so I thought I'd ask.  It would be so satisfying to "breach" one of these dams.

First, thanks Sketch for the video. the logic, and mission file. 

I guess I could take each top layer (they are 7-8 layers deep) and use the logic Sketch thoughtfully provided to at least get a "success" message.  I don't see any benefit in attaching each lower layer to the logic as they don't destroy so a visual breach is impossible.

The canal locks from the Moscow map also have no damage model or visual destructibility so this logic could help there as well.

I imagine damaged modelsfor al the "Grounds" objects would just add to an overloadable* mission.

 

*overloadable;

transitive Beebop verb -

To so load an IL-2 Sturmovik mission with actionable objects the game slows to a slideshow or outright crashes.  Not recommended.

 

 

Thanks for responding.

Edited October 9, 2020 by Beebop

[Gambit21]

Also we annoyingly can’t spawn and delete static objects. Otherwise we could fake a damn dam breach with some effects and a fake block etc.

 

Also Beebop, linked entities pose no problems with regards to loading missions etc. I use many of these for various reasons including entire damaged villages.

 

[Sketch]

Here's another video for you @Beebop... It's all about illusions.

 

 

 

 

[Gambit21]

Nice job once again @Sketch

 

In Hell Hawks I used Fake Block/Command Damage “Complete” for a cluster of secondary explosions for certain objects.

 

Explosions

 

The ammo explosion “normal” is the same size and added after the HH build. I’ve been asking for these for a few years now.

 

Now a question for you. Twice now I’ve tested and reported that the “large” effect was the same size as “normal” - has this been rectified? I’m after a nice big 1000lb size explosion effect for the next project. 

 

 

 

 

 

Edited October 9, 2020 by Gambit21

[Beebop]

1 hour ago, Gambit21 said:

Also Beebop, linked entities pose no problems with regards to loading missions etc.

OK.  What is the cause then for the "Server Overload, contact the administrator" message I get when I've used a lot of Linked Entities in Multiplayer?  I thought it was having a lot of "LE"'s.

[Gambit21]

I’m speaking of single player (always) I’ll leave MP to someone who knows better.

[Sketch]

@Beebop - There are lots of tricks to getting better performance on multiplayer (and single player). A lot of the tricks involve activating and deactivating heavy assets like AAA, bombers, moving entities and more through checkzones (and sometimes complex triggers). You want your tick delay (on dServer) to be less than 7 or so. Any higher and players will feel the server delay and at higher than 10 tick delay you'll start getting server overload messages.

 

 

@Gambit21 - I think the explosions are bigger for the big ammo explosion. There are noticeable secondary explosions that happen with the bigger ammo explosion effect. However, I don't think it's as big as you want it to be. hah 

 

 

Here's nearly all the effects in the effects group of the mission editor:

 

 

Mission files:

 

Testing New Effects.zip

Edited October 9, 2020 by Sketch

[Gambit21]

@Sketch

 

Very nice - I love how fast you crank out these videos.

 

Yeah you’re right they’re a bit different, but at 350 mph more less the same impact to the player. Great demo. I set up basically the same thing and sent to Sneaksie a few times and also politely appealed to Han again just recently for BIG please. They have the effect already attached to the larger bombs, so just asking for the same one.

 

What I want is the “Oh &%#&!!” effect when strafing an ammo dump or munitions train car etc etc for Normandy...fireball/smoke filling your wind screen. A bit of drama - BOOM!!! instead of ‘poof’

[Beebop]

Thanks everyone!  I now have satisfying explosions when the dam is "Breached".  Thanks both Sketch and Gambit for their informative and entertaining videos and priceless assistance.

 

One more question, which I'll bet can't be done, but then you never know.....

I know through reading the manual that there are ways to make things spawn and despawn. 

Is there any way to make the ground objects that make up the dam disappear after the blast?

I know it won't look realistic having a big center block of the dam not there but it clearly says to the player(s) that the dam is breached, not just a message telling them so such as;

"By April it will warm up and the dam will magically disappear".  (infamous paraphrase)

I'm betting the answer is 'No' but again, if you don't ask.....

 

Either way thanks a bunch guys for all the help and the knowledge!  ???

(and my brain enlargement)

[Sketch]

Can't make ground objects or blocks activate or deactivate. You can still cause an illusion, and most pilots will believe your illusion if you sell it well.

[Alonzo]

Couple of thoughts:

• Once the dam is destroyed, you could leave it smoking, or maybe some buildings either side are destroyed and smoking.
• If you want to get really fancy, you could require players to actually fly down the lake by using some near-ground spherical check zones. The real dam busters needed to bounce their bombs, this could provide a way to fake that. One fairly large "beginning of lake" check zone could enable the next, smaller and lower one, and so on, and the final check zone somewhere near the dam could enable all the damage logic. Maybe have a 2-3 minute reset for all the CZs.

[Beebop]

6 hours ago, Alonzo said:

If you want to get really fancy, you could require players to actually fly down the lake by using some near-ground spherical check zones.

Excellent idea.  Right now I have two AA positions at each end of the dam. 

 

 

If you fly ~250-500 meters you are guaranteed to be shot down.  If you fly in the deck of the lake and skip bomb you have a slightly better chance.  Attack planes in the group (IL-2's) are tasked with eliminating the AAA but their life expectancy is in doubt.  If I continue having the defending AA tapping into too much of The Force or they get lax on the job, the spherical Check Zones sound like an excellent option.  I may well add them in anyway.

It will also help me gain a better understanding of Check Zones, something I have used very seldom so far.

Thanks!

[Tirantfoc]

On 7/9/2020 at 10:07 PM, =SqSq=Civilprotection said:

I have another module which I think is polished enough for posting here. This time I have a proxy based respawning flak system:

This flak module starts inactive, once a plane flies within a set range, the gun spawns. When the plane flies out of range, the gun is deactivated. When a plane flies back into range, then the gun is reactivated (not respawned). On death, there is a logic chain to destroy, delete, and prime the gun for respawn after a set amount of time. This is a partial combination of systems I have posted here before, and a good deal of it should look familiar.

 

I have organized the module into three zones for ease of use. Blue is nearly identical to my respawning vehicle module (here), and likewise functions almost identically.

 

Blue: On spawn, the gun receives orders for formation, waypoint, and attack area. The attack area MCU dictates what the gun should be shooting at (Airplanes, High Priority by default). The Waypoint allows the mission maker to dictate what the gun does not shoot. Priority set to "low," The gun will shoot at everything in range (Planes, Vehicles, Parachutes). Priority set to "high," The gun wont shoot at anything ever, except for what has been specified in the attack area MCU. The formation MCU is mostly vestigial, and can probably be safely deleted. On death , the gun receives "complete" damage, is then deleted, and finally sends a signal to set up the initial "check zone" MCU in preparation to spawn again. Timers should be adjusted for the desired length of time between respawns.

 

Red: This is the mission start logic. On mission start, the check zone MCU is activated. If a plane is detected, it activates the spawn, and deactivates itself.

 

Green: This is the proxy system that activates/deactivates the gun when planes fly in and out of range.

 

Yellow: I've crossed out these subtitle MCUs. Although useful for testing (you should use them) they can (and should) be safely deleted once satisfied with the functionality of the module as a whole.

 

That should cover all of the module functionality. Anyway, take a look for yourself:

ProxyFlakRespawn1.3.zip 3.63 kB · 17 downloads

As always, if there are any questions, feel free to reach out. Cheers!

 

 

Good afternoon,
Excuse me if my question is obvious, I am starting to use the editor and still have many doubts about how to use it correctly.
I have pasted your group on a German airfield and I can't get it to appear. There is no spawn.
Things I have done following your instructions and my knowledge:
1 Mission Begin in 3 sec.
2 Check Zone Allied and Entente True
3 The two Proximity Allied and Entente True
4 Vehicle German
Obviously I am doing something wrong. Could you tell me the correct way to use it?
Thank you very much for your work.

 

 

[=SqSq=Civilprotection]

@LF_Tirantfoc, I will help you as best I can. Can you upload your mission file so that I can check your setup?

[=SqSq=Civilprotection]

Hey all.

 

Tank Crew has been getting a lot of attention recently, and I've been tinkering with modules based around tanking in multiplayer. I have a couple of super exciting sub-assemblies that I want to share with the community, but I need help testing them and working out the wrinkles. If anyone is interested in helping me test some of these systems, please send a message my way (tankers and pilots are both welcome)

 

I hope to have the time soon to post these modules to the forums soon. If used right, I think they really have potential to shake up the multiplayer scene.

 

Cheers!

[Thad]

On 9/16/2020 at 3:05 PM, =SqSq=Civilprotection said:

@NoBigDreams This is some very interesting research. I'm curious to see how you plan on working it into the game.

 

Salutations,

 

I suspect that actually fielding such numbers of units in a mission would cause heavy CPU loads (lag). Not to mention adding a like sized enemy force to contend with. Attempting to do so will probably prove very problematic. Also, the map used could cause even more lag.

 

Below is the size of a fictional battalion I used, as a reference, for my Tiger At The Gate missions. It displays maximum numbers (not historical). The missions ran well on the small Lapino map. The Russians had roughly the same numbers. Artillery units and machine guns positions were included for the Russians.

 

Another consideration one has to take into account is the quality and effectiveness of the historical German/Russian armor as presented in IL2. Equal numbers will not likely present a balanced or rewarding battle. Experience with the editor and playtesting will reveal to you what I mean.

 

I am in no way wanting to discourage historical sized units, just showing what I have experienced in my mission creations.

 

Edited November 29, 2020 by Thad

[batmacumba]

On 3/6/2019 at 12:07 AM, JimTM said:

 

I don't have the math background to really do an effective job at explaining my point of view. Guess we'll have to wait for a probability guru to chime in.

 

S!

 

 

 

Hey folks!

 

I'm very late to this party and very new to the ME, but I wanted to offer my simple proof that Jim's timers are correct. Here it goes:

 

 

I also went a little further and wrote a Python script that simulates the behaviour of the timers, if I understood them correctly. Here is an example of the result of the script:

 

Running 1000000 tests...

number of times t1 fired: 250106

number of times t2 fired: 250034

number of times t3 fired: 250112

number of times t4 fired: 249748

 

I've attached it if anyone wants to test it out. Thanks!

 

randomtimers_script.py.zip

[Thad]

Jim is correct? ?

[JimTM]

13 hours ago, Thad said:

Jim is correct? ?

 

Coconut actually. He posted the original design. 

[Thad]

1 hour ago, JimTM said:

 

Coconut actually. He posted the original design. 

 

Oh, that sounds more acceptable. ?

[JG7_X-Man]

On 12/17/2020 at 4:56 PM, =TLP=batmacumba said:

 

Hey folks!

 

I'm very late to this party and very new to the ME, but I wanted to offer my simple proof that Jim's timers are correct. Here it goes:

 

 

I also went a little further and wrote a Python script that simulates the behaviour of the timers, if I understood them correctly. Here is an example of the result of the script:

 

Running 1000000 tests...

number of times t1 fired: 250106

number of times t2 fired: 250034

number of times t3 fired: 250112

number of times t4 fired: 249748

 

I've attached it if anyone wants to test it out. Thanks!

 

randomtimers_script.py.zip 398 B · 2 downloads

LOL if the guy didn't understand my "Four guys at a bar analogy" I am not sure he will get this 

Good work by the way!

[=SqSq=Civilprotection]

Hello all!

 

I wanted to make a post about my Hex-based moving frontline system which I have been building on and off for many months.

 

Everything in the video is in real time.

https://drive.google.com/file/d/1Ec1_cMg5XpkxK2Raq4_2LppzmZ5baFEU/view?usp=sharing

 

Every hex is identical, and there is no particular order in which players must capture the hexagons. The system even allows for encirclement. I think this module can open the door for so many different types of gameplay. The two I would be most excited about are tanks and paratrooper missions in multiplayer.

 

I am continuing to work on multiplayer demos, and I run my own server from time to time. I want to repeat my request for testers if anyone is interested, or curious, or... well, mostly those two things. So DM me if you fall into one or both of the above,

 

Cheers!

Edited December 20, 2020 by =SqSq=Civilprotection

[IRRE_Genius]

On 12/20/2020 at 11:01 PM, =SqSq=Civilprotection said:

Hello all!

 

I wanted to make a post about my Hex-based moving frontline system which I have been building on and off for many months.

 

Everything in the video is in real time.

https://drive.google.com/file/d/1Ec1_cMg5XpkxK2Raq4_2LppzmZ5baFEU/view?usp=sharing

 

Every hex is identical, and there is no particular order in which players must capture the hexagons. The system even allows for encirclement. I think this module can open the door for so many different types of gameplay. The two I would be most excited about are tanks and paratrooper missions in multiplayer.

 

I am continuing to work on multiplayer demos, and I run my own server from time to time. I want to repeat my request for testers if anyone is interested, or curious, or... well, mostly those two things. So DM me if you fall into one or both of the above,

 

Cheers!

 

Very Nice Works !

 

- which condition was use to capture or loose a zone ?

- Wath is the impact on the SPS / tick delay ?

 

Thanks