"Did he fire sixty-five or only sixty-four? Well, to tell you the truth, I've kinda lost track myself in all this excitement. But being this is a 30mm Minengeschoß, the most powerful round for a 109 and will take your wing clean off, you've gotta ask yourself a question: 'Do I feel lucky?' Well, do ya, punk?"
... okay, I'm out, but my twin 13-mils aren't just for show either!
The prototype ammo-counter: Here
G'day e'ryone! Long time no see! I know most have never heard of me, but for those who do, hey look who's back!
Sooooo... get back to the point, my topic today is: the "if-else" loop, or in FunkyTrees term, the a?b:c Ternary selection operator.
So what did I do with it? It's common for the selector to be used to give out two different values based on whether the condition set for a is fulfilled or not, but then I started thinking: "wait, can I simply set one of the values to the variable itself? Surely if rotators can do that then I can do it in FT" after a particular discussion with @Kendog84 about data storage. And "do it in FT" I did: my first test was a simple x1 | repeat(Time, 10) > 9.9 ? Time : x1 - and it worked flawlessly: x1 would set itself to the in-game time every ten seconds, and hold it for the next 9.9 seconds before the cycle repeats again. Then I quickly realized something else: the same cycle can be used for guns, and I've built one prototype AA gun using a similar setup! Plus, there's just that je ne sais quoi of having half a dozen HMGs thumping and thudding in flawless unison - something the vulgar ways of letting the game decide which gun fires first would never hope to achieve. So, instead of having the guns themselves fire based on their own roundsPerSecond or timeBetweenBursts values, I would have the guns ready themselves first, and then their FT-coded AG would set them off at the same time - this, coincidentally, also happens to be a simplified version on how gun synchronizers work on WWI and WWII aircrafts: when the trigger on the stick is pulled, the synchronizer will try to pull the trigger on the corresponding MG/autocannon every time it rotates into place - if the gun is chambered, BANG!, but if not, the the gun would simply be dry-firing and nothing would happen.
An issue quickly reared its ugly head, of course: if the FireGuns button is pressed when the game suddenly decides there are no active guns anymore (most commonly seen on in-game plane crashes when the trigger is still pressed), the game would "assume" that the FireGuns button is always pressed until the next time the button is actually pressed and released. To combat this, a placeholder gun (the minigun in the center) was installed with zero damage and impactForce, deactivated part collision to prevent its projectile from interacting with the plane, a burstCount of 1 so it would only fire once per cycle, a bullet lifetime of 0 to prevent its bullet from flying anywhere, a bulletScale of 0,0,0 to further ensure the bullet would not be rendered graphically, an arbitrarily large roundsPerSecond to prevent the gun from making any sound the only time it's fired, and finally an equally arbitrarily large timeBetweenBursts to make sure the next firing cycle never comes. This gun would be set to the same AG with all other guns (sans the timing function), and its role is simple: by making sure there's always a "gun" active when every other gun would be rapidly activating and deactivating, the bug's simply sidestepped.
fig.1: short bursts, notice the middle left value "cycling" and the lower left value increasing with each round fired
fig.2: single shot, notice the middle left value cycles at the same rate regardless the whether the FireGuns button is tapped and released quickly or if the button is held down
Now let's get onto the autoloaders. As many War Thunder players can attest to, many AFVs (tanks, assault guns, tank destroyers, etc.) equipped with autoloaders do not simply have every shell loaded in the magazine where the autoloader's drawing from, and once the autoloader is emptied, the reload rate drops dramatically as the crew need to reload the autoloader magazine from another rack before the autoloader can finish loading the shell into the breech. Some vehicles not equipped with autoloaders also have a similar - although significantly less noticeable - quirk where the reload rate reduces slightly once the ready-rack is depleted and the crew now need to reload the gun from a less convenient rack... or refill the ready-rack first before reloading from the ready-rack.
This was replicated by combining the principles of the previous if-else loop (switched to ammo-based as cannons have fixed ammo count but have a rather wonky relationship with time) with a previous prototype of mine where the input was time- instead of ammo- based, ultimately resulting in the new code that allowed every firing of the gun to increase a determining value by one, with the value slowly dropping to zero at a pre-determined rate. To my understanding, the aforementioned codes, when combined with the pre-existing FiringDelay of the cannons, could somewhat adequately simulate the two distinct reload rates with and without the autoloader - or with and without a shell in the ready-rack, for that matter.
fig.3: burst fire, notice the rate of fire with the "autoloader" loaded is 20 rounds per second while the "reload" time is one second for ease of demonstration
fig.4: single shot, notice the time it would take for the autoloader/ready-rack to replenish for a much reduced sustained rate of fire.
Addendum: A clip-based design that only start reloading after the sixth shot was fired.
@Zaineman Yeah, exactly what I'm trying to reference, only I'm using the ammo load of a Bf-109, and apparently I'm out of Motorkanone rounds.
Clint Eastwood rocks "Dirty Harry"
@Grob0s0VBRa Yeah, gotcha. Because when I hear "wind-up" the first thing that came up in my mind was something akin to the wave motion gun or similar weapons of that nature (super-heavy spinals that have to be kept charging for a while before unleashing a devastating torrent of pain), so please forgive me if I misunderstood for a bit.
@ThomasRoderick Em,
smoothon its own only gives a delay before the cannon could shoot.The code i used gives a delay between shots.
So after the first shot,all cannons deactivate for a brief period of time, and that amount of time gets lower the longer you fire.
By wind-up i meant a gradually rising ROF, yep.
Oh and there was no variables at that time.
Anyways, it's kinda really old thing.
@ThomasRoderick ok
@XtarsAgency On a second thought... I'm pretty sure with the traditional "boquet o' cannons" (aka. one cannon with actual
firingDelayand every other cannon with none) you should be able to do a "good enough" job for it... I'm currently working on a clip/mag based system that would only start reloading after a set number of shots are fired, but the delay between each gun have to be larger than 0.02 secs for the system to work properly... and that's assuming high physics.@ThomasRoderick yes, i have tried one with *cannons but it doesnt work unless its in slow motion
@Grob0s0VBRa Also, if I really need to make a weapon with a lengthy charge-up period before firing... I would probably use a combination of
smooth(a, b)anda ? b : cfunctions. Much more simplistic that way.@Grob0s0VBRa ... grobs, why the hell does your cannon require a wind-up period? And to be perfectly honest, if I were you and am trying to simulate a rotary cannon, I would use the
currentAngleon the rotator powering the barrel assembly to time the cannon hidden somewhere in the barrel shroud... and if the gun was some sort of single-barrel weapon that attains a higher ROF the longer it's fired (eg. revolver cannons and gast guns), I'd just use a variable."Make us One, Isaac."
*ahem*
It Is A Good Day To Have Sandwich.
Also, nice discovery.
Oh, wait...
(1 - smooth(clamp01(-rate(ammo(Canon))), clamp01(-rate(ammo(Canon)))*pow(10, 4)+ (0.5 +clamp(21.5 -(21.5*smooth(clamp01(-FireWeapons),0.09+ floor(smooth(clamp01(1-FireWeapons),0.25)))),0,21.5)) )) = 1Found this around 2 years old code in one of the saved concepts.
It simulates a wind up for cannon pieces when used in activation group, so you set 0.01 firing delay and insert code into a multiple cannons with same name.
Cannons were on a rotator piece so i guess i made something like GAU-8 and haven't used it, yet.
Plus, recently experimented with hover vehicles and made an subassembly which kinda acts as a "artificial"
AltitudeAglsensor based on this, it holds it's position according to the main cockpit or specific Flight Computer.To simplify: 1 subassembly allowed to make all-terrain hover vehicle with relatively low true
AltitudeAgland decent speed.By all-terrain i mean it covers whole Maywar with ease, wanna test it on other islands.
Bah, what if it would be useful for bigger, multi-legged walkers.
p.s. *KeanuIntensifies*, well, lol
@XtarsAgency
... and here I thought it's the concept that counts?
If you want to use a gun-based system, just use 13 miniguns, all with xml'ed
bulletScale,muzzleVelocity,tracerColor,damage,lifetimeand whatnot, just remember to keeptimeBetweenBurststhe same for all guns andburstCountto1..
..
... That said, I myself would probably use a more complex system involving cannon-based intervalometers and detacher/pylon based launchers to lob bombs and rockets on various trajectories to better stimulate the line of explosions.
@Kendog84
Okay... how to explain...
First, my entire experiment is about "how to make sure the stored value only change when I want it to, nothing more and nothing less", and to be perfectly honest, if you just want something to not change after the first input then a simple
if-elsefunction works a lot better.And second, what
repeat(a, b)does... is to divideabyband give out the remainder of the division as the output. I first saw the function being used by @Soldier289 on the IJN Kongō, in which the turrets used such a function to never travel beyond the hardstops while remaining unerringly controllable with just pitch and yaw inputs.So if you mean "can I simply set the
ain therepeat(a, b)function to some arbitrarily large number and call it a day", the answer is "why should you", but if you mean "can theaget too large for the game to register anymore", I guess so? Although I'd assume the game would bug/lag out or the numbers would loop back to negative by then.@ThomasRoderick oops I forgot lol. Brain no worky
Is it possible to assign infinite number to the repeat function, so the stored value never changes based on time?
I'll have to learn how loop/repeat function works first (which I have a vague understanding of it. I think) to really understand what's going on here, though. Not familiar with it yet
@Kendog84 Thanks!
@ThomasRoderick okay, but how do i scale it larger? Because i need to complete my tank "conquer" which is basically a recreation of what you saw
@ThomasRoderick we?....that would be the voices in my head im actually schizophrenic 💀💀💀
yeah sadly it is true, the lowest you can go is -1 firing delay, less than this bugs out the cannon
also cant wait to see your clip based weapon
@XtarsAgency After watching that video.... I have to say it's less of a "cascade" and more of a shotgun blast of 13 shots: one powerful shot in the middle, and six shots of varied velocities on either side of the central shot. That, coincidentally, was also very similar to the concept behind @Spefyjerbf's Variable Repeater concept... but not so much with real-life weapons.
@Sadboye12 Who's "we"?
Also, keep in mind that cannons can never truely "fire together" per se as there's always a delay between shots, no matter how minor, and if one gun's damaged/jammed the firing sequence would not adjust for the missing gun. However, if you meant "wing guns and miniguns" then... @AtlasAviation has been doing that "combined trace" for a few years now with just miniguns, no coding required. I'm currently working on a clip/mag fed cannon that can only start reloading after the entire "clip" was fired, though.
also welcome back chief, we missed you
this is amazing!
imagine what else you can make with this, the first thing that came to me is having multiple cannons and make them overlap with each other and fire together, the cannons will have different tracer colors, with this you can have a beautiful combinations, but you have to make sure atleast one of them should have longer trace, it helps with the gradient!
@spefyjerbf
... and here I thought you solved it half a year before I even had my account?
help my brain cells are having a hard time processing this and if i continue further i will begin to lose them so i must go now sorry bye
I definitely see some good improvements. Perhaps the most notable to me, at least, was sidestepping the disappearance of the fireguns button, since I had not thought of a solution to that problem (which I had experienced a good amount). The rest of the functionalities look good for designing more combat options, which is always a fun endeavor. Hopefully my response is adequate, since my brain is soup these days lol
@ThomasRoderick nice, but i was wondering how to do bursts that is set to shoot not perfectly forward but into a sort of cascading. The example is like mindustry's conquer, if you see the video of it firing its cannons you will know what i mean
Like this one