Is there a script to cause units to not drop power zones?

Started by Courtesy, June 16, 2014, 02:57:20 PM

Previous topic - Next topic

Courtesy

I've got a map that is just the right difficulty if power zones do not exist. Is there a way to disable power zones from occuring on a map?

J

Create your own emitter using crpl :)
In pass the map 3 we had a lot of them so you can steal the script from there.
You might also try changing the unit attributes for emitters but I'm not sure if that works (something like '[coords] 1 GetUnitsInRange pop ->UID <-UID CONST_LEAVEPZ false SetUnitAttribute', check the wiki for exact arguments and order).

kwinse

The documentation explicitly states CONST_CREATEPZ only works for CRPL Cores.

:awake
Self "main" "NONE" SetImage
Self CONST_CREATEPZ 0 SetUnitAttribute
Self CONST_COUNTSFORVICTORY 0 SetUnitAttribute

:destroyed
CurrentCoords 0 0 GetAllUnitsInRange
0 do
->u
<-u GetUnitType "POWERZONE" eq if
<-u 0 Destroy
endif
loop


Seems to work, but I've never used it without a persistent core that also checks to remove powerzones at those coords the next frame.

Courtesy

So... wait.
I would need to create a special emmitter on all the emitters currently in my map  ??? Seems like it would take quite a bit... especially if I don't know what I'm doing (which I don't).

Was the thing kwinse posted a  CRPL unit that would automatically destroy power zones when they were created, or the thing I'd need to add to the emitter CRPL I need to create?

J

This should be the script you need. Setting 'mode' to 0 (from within the game) should cause your emitter not to spawn anything when destroyed. For mode you can use anything between 0 and 10, however for some might need to adjust other variables.

kwinse

That is a CRPL script. You can only run CRPL by making a script and attaching it to a CRPL core. You can't attach scripts to any other unit.

My code is a script to (attempt to) automatically remove all PZes the frame they're created, because the core the script's attached to is destroyed at the same time. In theory all you have to do is create a core, attach my script to it, then move it to the same coordinates as the emitter (or whatever else you'd rather not create a PZ). Even if it has an image it should automatically hide itself.

Courtesy


Annonymus

It should be enough to create a single script that checks for powerzones on the entire map every frame and, if there are any, removes them.
Unless there are PZs on the map which should be there from the beginning in which case you'd have to create some exceptions which might be a bit more complicated.
If a topic started by me is in the wrong place feel free to move it at anytime.

kwinse

Yeah that does work, but it still allows a PZ to be rendered for a frame. Or else I was doing something wrong.

Courtesy

Quote from: Annonymus on June 18, 2014, 03:18:51 PM
It should be enough to create a single script that checks for powerzones on the entire map every frame and, if there are any, removes them.
Unless there are PZs on the map which should be there from the beginning in which case you'd have to create some exceptions which might be a bit more complicated.
That seems like it would involve more processing power than what Kwinse gave me. Kwinse's code also already allows me to make exceptions for certain zones.

Annonymus

Quote from: Courtesy on June 18, 2014, 03:55:37 PM
Quote from: Annonymus on June 18, 2014, 03:18:51 PM
It should be enough to create a single script that checks for powerzones on the entire map every frame and, if there are any, removes them.
Unless there are PZs on the map which should be there from the beginning in which case you'd have to create some exceptions which might be a bit more complicated.
That seems like it would involve more processing power than what Kwinse gave me. Kwinse's code also already allows me to make exceptions for certain zones.
Actually, I think it needs less but the main advantage is that you only need one core and not one for every emitter.
About the PZ still being rendered for 1 frame, that depends on the order of operations, if the CRPL scripts get executed before everything of the "original" game then, yes it will be rendered for a single frame, if CRPL gets executed AFTER the game it should be deleted in the same frame it appeared and therefore not be shown at all.
If a topic started by me is in the wrong place feel free to move it at anytime.

kwinse

Well that depends then, is a script running every frame, looping over every unit on the map less resource intensive than having a bunch of cores not doing anything until destroyed?

Plus using the :destroyed function is more consistent in regards to the timing.

Crimson King

One core for the entire map when there is only one or two PZ creating items that the map creator doesn't want creating a PZ is a waste of processing power when it is more efficient to place individual cores in the locations and those cores only listen to the location they are placed.

There should be no need to listen to the entire map just to see if a PZ is created unless a player wants all PZs removed. Even then it is more efficient to have the core that checks the entire map get all enemy units that create PZs and place a core with the no PZ script at the same coords or build a list of those units and only listen to those units.

J

I still think the most effecient way is to simply not create the power zones at all. The Get[...]InRange commands are very slow and shouldn't be executed every frame. I gave you a script which can be used as emitter (it can even drop totems, resource packs and techs). Any built-in enemy unit can be made with crpl, only the spore tower is a bit harder than others (and I would recommend using the built-in spore tower instead).

Virgil, please give all enemy units an option to not drop power zones or a dropdown menu for other things that can be dropped when destroyed. It's getting way too complicated with crpl :P

kwinse

My main sticking point with CRPL-emulated units is that they don't look as nice as the built-in ones. For example, watch an emitter and see how dynamic it is.

Though if you want users to see that it's not a regular unit, then the emulation's your friend of course.