#4616 : [PACV] Hoover that AC out
#[PACV] Hoover that AC out [4616]
silver estuaryBOT
#4616 : [PACV] Hoover that AC out
ruby blaze
Thanks Argonwolf on helping with the scripts. This start is even more difficult than the earlier one, but again when the beam power increases suddenly it's super powerful. The AI has no time to respond when the balance shifts to powerful beam.
wicked scroll
Thanks Argonwolf on helping with the scripts. This start is even more difficult ...
Thank you for using the new key bind, it's nice to not toggle the vacuum every time I wanna move the map. I thought this map was fun, it does get really easy toward the end as you mentioned. If you want any other balance or functionality changes just hit me up, I like tinkering with 4rpl code as a hobby.
On an unrelated note, I wonder who has it in for you that immediately tags every one of your maps with "bad"? As quickly as it happens and on every single map, it's starting to seem personal lol.
ruby blaze
Maybe Michael Jackson is stalking me?
and I think the "easy to finish" comes from how the autopilot AI. The normal PAC map it has time to react to new emitters and such, but on the hoover map when the beam gets powerful you start pushing the map faster than the AI can react. Both moving units from the old frontline to new frontline, or building new units, takes longer than the beam creating new creep.
Quick thinking, the easiest way would be to limit the beam. For example make the power increase scale to max 1000. So usual increase is 5 units per destroyed unit, change that to be 5 * (1000-currentpower)/1000 so the closer you get 1000 the less it increases. Still most likely would be easy to finish unless the AI is told to be faster to react or even predict when there'll be breaches
inner falcon
Thank you for using the new key bind, it's nice to not toggle the vacuum every t...
Yep and I bet it's only a matter of time before it gets marked as "broken" as well, even though dozens of people have completed it... I just don't get it 😒
quick frost
Yep and I bet it's only a matter of time before it gets marked as "broken" as we...
i mean so far it seems brocken too me. i cant beam down or up which is really odd
(even if i press the f key)
quick frost
rebind the key 4 times now and now it works yay
wicked scroll
and I think the "easy to finish" comes from how the autopilot AI. The normal PAC...
Would you like me to tweak the script(s) to give diminishing returns on storage gains from killing units?
ruby blaze
i mean so far it seems brocken too me. i cant beam down or up which is really od...
strange. I didn't need any rebind or such, just played and using f to beam up and down. Does the text box show you the beam direction?
ruby blaze
Would you like me to tweak the script(s) to give diminishing returns on storage ...
I might make more in the future so I think some point when you have spare time, that'd be awesome. Maybe set the limit as variable so it's easy to tune for the map needs.
wicked scroll
Can do. If it's alright with you I may use either a square root function or the harmonic series, either of which will provide diminishing returns without converging on a limit. In other words, there would be no maximum storage value, but each subsequent unit kill would still provide less than the previous.
ruby blaze
that might work too, and if it seems too powerful/weak I could always tweak the nominal increase value to adjust how it increases
wicked scroll
that might work too, and if it seems too powerful/weak I could always tweak the ...
Here's the updated script. I chose to use the harmonic series as the falloff model since it nicely fits the additive nature of the rewards in the script. It has 2 public variables you can change in the script settings:
BaseKillValue: This is the starting value of a unit kill; defaults to 5.
KillsPerStep: This is how many unit kills have to occur before one full step to the next value in the harmonic series is reached. So if this is set to 10, after 10 kills the kill value will be half what it started at, then 10 more kills will reduce it to a third of its original value, then a fourth, etc. (This doesn't mean you have to get this many kills before getting more creeper capacity; it will increase fractionally with each kill). This one defaults to 50, which is a decent baseline and can be tuned to suit your map (It can be a fraction, such as 50.5, letting you tune it very precisely).
BASICALLY, the smaller the KillsPerStep value is, the faster the reward for each kill decreases. It also has to be greater than zero, but the code checks this to prevent errors.
I'm bad at explaining stuff so if you have any questions just ask.
somber dirge
ooh, thanks for scaling down the multiplier gain with the same scaling, that's probably the bigger offender over time. Can't wait to see what harder maps you end up making without the OP endgame vacuum tpatana
somber dirge
Here's the updated script. I chose to use the harmonic series as the falloff mod...
hey, I think I see some problems in the code here. It looks like you're iterating using unitN in each step, but this appears to be a persistent value so if I get a 13th "original unit" kill I'll get an increase of 13 / KillsPerStep instead of 1 / KillsPerStep
Unless I'm missing something, you also don't seem to be using a non-constant variable for KillsPerStep so its just acting as a constant divider on the kills instead of the harmonic approach you mentioned wanting.
If anything I'm saying here isn't clear please feel free to ping me, I can be bad at explaining things sometimes. And if you want any help with restructuring things to fix these if they are problems let me know and I'll gladly help
0 ->storInc
while <-diff gt0
repeat
<-storInc <-KillsPerStep <-KillsPerStep <-unitN add div add ->storInc
<-diff 1 sub ->diff
<-unitN 1 add ->unitN
endwhile
SendMsg("transport_cursor_increase_storage" <-boostmaxstorageperunit <-storInc *)
SendMsg("transport_cursor_increase_beam_down_multiplier" <-boostmultperunit <-storInc *)
#### End addition ###########################
#SendMsg("transport_cursor_increase_storage" <-boostmaxstorageperunit <-diff *)
#SendMsg("transport_cursor_increase_beam_down_multiplier" <-boostmultperunit <-diff *)
<-unitN 1 add ->unitN
That's where it gets incremented, so it does count each subsequent kill.
<-storInc <-KillsPerStep <KillsPerStep <-unitN add div add ->storInc
So let's say S = storInc, K = KillsPerStep and N = unitN; a more readable version of that line would be:
S = S + K/(K+N)
The K exists to "dilute" the diminishing returns; if it were set to 1, you'd just have 1/1+N, which is the standard harmonic series (1/1, 1/2, 1/3, 1/4 etc...). Setting it higher (50 by default) causes it to fall off much more slowly (50/50, 50/51, 50/52 etc...) to the point where you have to get N kills (50/(50+50) = 50/100 = 1/2) to advance to the next full "step" in the harmonic series, hence the naming convention.
I tested the code and it appeared to function as intended, but if you encounter any bugs I'd greatly appreciate a report so I can fix them.
somber dirge
ah, yeah, dang, its been a long time since I've read RPN and for some reason flipped the arguments on the division. I thought it was this
wicked scroll
No worries, I like having scrutinizing eyes on my code because it makes it harder for bugs to escape.
quick frost
now that the rebinding worked this map is really fun
dapper scaffold
To be frank, I genuinely can't see how you're meant to start this map. I can of course claim the immediate breeder terrain, cut off the immediate east and west attackers, I can even occasionally temporarily steal the breeder terrain north of the start - but the map swiftly floods with AC, the AI starts moving in far too many units whilst I'm struggling to try and either secure my closest breeder terrain, flip one of the westerly breeder terrains, or try knocking out the inhibitors on the nearby emitter or blobber
The map seems to lack any clarity on how to start, and given it rapidly floods with AC it doesn't give much room to experiment before you just need to restart as your increased beaming storage does not in any way keep up with the AI flooding in turrets and the map becoming a thick AC soup
Stalling tactics, like rapidly beaming down-and-up small volumes of creeper on a turret or inhibitor to try and bleed its health whilst 'dodging' the shots fired don't work of course when the AC flood presents a natural and uncontestable deadline
ruby blaze
In general, the strategies for maps like this have 2 important elements:
1: Cut off energy for the enemy troops. If there's clear line of energy flowing and it has only one (or maybe two) route, kill the tower/pylon on that route and the impacted area becomes free for all
2: Emitters and other elements. Kill the nullifier for few of the units, and when enemy starts re-building nullifier kill it before completion (for easier killing). Depending on map, often spores are best because of the eggs are very powerful
dapper scaffold
I appreciate that, and whilst I can cut off the energy for the immediate enemies by the spawn, the nullifiers are rather too well defended with ERNed turrets and the AI is already bringing in replacement turrets (and the AC flood) whilst I'm still trying to force any weak point to my advantage
lilac storm
You can get a really strong start by using frame advance for the first ~2 seconds. You can place 1-2 frames worth of creeper (can't remember if 1 frame is enough to destroy tower before evaporating) under ~25 towers without retaliation and get your creeper cursor power close to 150 before 10 seconds. That will give you a lot faster of a start to clear out the emitter/blob nest/spore launcher.
Overkill to do on most cursor maps, but it is very effective.
dapper scaffold
'Frame advance', I'm guessing from context you mean rapidly unpausing and repausing for a single game tick to drop just the tiniest bit of creep? More beam storage is nice, but I find I'm more struggling for sheer creeper volume to supply any beam
lilac storm
'n' is the default key while paused to advance a single frame. The increased beam storage also adds a multiplier to dropped creeper; 150 seems to correspond to a multiplier of about 1.5x.
If you run low on creeper you can constantly pick up and drop creeper in a corner, the multiplier stacks the creeper up.
dapper scaffold
Aaaah. I didn't know of that hotkey, thank you. And right, okay. I'd tried to counter-flood the AC wave by dropping in the southeast corner where the % gain was highest, but it would certainly be easier with a 1.5x modifier stacked on that. I'll try that, thank you
dapper scaffold
Right, frame advancing definitely made that possible, letting me rapidly hit 150 storage cap as you said and then letting me drop a thin broad sheet of creep around a nullifier's area to saturate all the turret fire and tick away at inhibitor health, and as soon as that gave me the first emitter that let me storm the rest.
If frame advancing is the expected/necessary route to do the map, it'd probably be beneficial to clearly explain the mechanic in the intro message - I admit I'm not a map-maker or pro, but I'm a fairly frequent enjoyer of PAC and FPS etc maps and I'd not encountered the topic of frame advancing to take advantage of cursor map's ability to instantaneously drop creep at a cursor destination
ruby blaze
I never use frame advance, so none of my maps it's needed. I think Hypno is the only one where that might be needed.