CRPL is really cool, but there are things I either can't figure out how to do or can't be done. So after messing around with it for a bit, here's some things I think would be cool if they were added as a command.
1) A unit attribute that allows the CRPL tower to be selected and moved, like any other player unit. (and thus a move speed attribute)
2) A unit attribute that allows the CRPL tower to take damage when submerged in creeper.
3) A menu allowing for players to build copies of a type of crpl tower during a mission(maybe a sub-menu of the Titans?)
These together would allow for completely custom player units, for one.
4) A unit attribute that allows the CRPL tower to be targeted by a beam(there's one for snipers, so...)
5) Negative value for digitalis... "Anti-Digitalis". Does not hurt player units when it's on top, but otherwise behaves similarly to normal Digitalis.
6) Runners that target emitters/runnerbases/exclusion/spore towers. Basically player runners.
These two would be managed by CRPL towers(or maybe anti-digitalis by anti-emitters)
7) Command to dispatch packets to CN.
8) Ditto for aether/ore/anticreeper. (Energy-to-AC converters anyone?)
9) a Shoot command, or something, that allows the CRPL to copy alread-programmed behaviors(so for example, Shoot(1) would fire a mortar shell, or Shoot(2) would fire a blob of AC)(Maybe with other arguments as well, like it can act as a sprayer but spray different amounts of AC... or even creeper)
Add to the list~
1)I guess you can script it :P
2) you can script it
3) I guess you can script it :P
5)I guess you can script it :P
6)you can script it
7)+1 to that
9)you can script it but +1 as it would make one's life easier
Yeah I know I can script 2, but it seems a TON easier to just have a once (blah) SetUnitAttribute endonce and letting the game engine handle it than checking for overlap with creeper then deducting health.
Also, I am interested in knowing, how would you script 1) and 3)?
Oh, and
10) Request Aether, like a forge, possibly(take priority over forge or otherwise...?) ?
11) Edit PowerZone behavior of CRPL towers.(GetZone condition or something)
I am no expert, but the CRPL cores can get commands form keyboard and mouse so i guess it is possible
Quote from: Crazycolorz5 on October 12, 2013, 05:26:41 PM
1) A unit attribute that allows the CRPL tower to be selected and moved, like any other player unit. (and thus a move speed attribute)
It's already possible, I just did it.
<-ready if
0 GetMouseButtonDown if
GetMouseCell 3 QueueMove
false TraceStack ->ready
endif
endif
<-ready not if
GetMouseCell ->my ->mx
CurrentCoords ->sy ->sx
<-mx <-sx eq <-my <-sy eq and if
0 GetMouseButtonDown if
true TraceStack ->ready
endif
endif
endifThe code is not perfect and needs some changes in order to be practical, but it does the trick.
Also, removing scripts from CRPL towers would be neat. (Adding them is already possible)
Couldn't you just make a new tower with all the script's except the one you want to "delete" ?
I probably could. The problem is that if I have a large and complicated script with a lot of varibles I need to replace every single of those varibles, and that's going to take some serious work to do it right.
Quote from: JH on October 15, 2013, 06:01:08 AM
Also, removing scripts from CRPL towers would be neat. (Adding them is already possible)
already possible. Try pushing the "delete" button.
I'm talking about adding and deleting scripts when the map is running and without using the editor.
Quote from: JH on October 16, 2013, 03:38:16 AM
I'm talking about adding and deleting scripts when the map is running and without using the editor.
$DisableScript:0
if(<-DisableScript)
#your code
endif
This should do the trick, with the added benefit of being able to re-enable the script in its former state.
Quote from: eduran on October 16, 2013, 03:56:13 AM
Quote from: JH on October 16, 2013, 03:38:16 AM
I'm talking about adding and deleting scripts when the map is running and without using the editor.
$DisableScript:0
if(<-DisableScript)
#your code
endif
This should do the trick, with the added benefit of being able to re-enable the script in its former state.
Ahh, good idea. Thanks.
Quote from: JH on October 15, 2013, 06:01:08 AM
Quote from: Crazycolorz5 on October 12, 2013, 05:26:41 PM
1) A unit attribute that allows the CRPL tower to be selected and moved, like any other player unit. (and thus a move speed attribute)
It's already possible, I just did it.
<-ready if
0 GetMouseButtonDown if
GetMouseCell 3 QueueMove
false TraceStack ->ready
endif
endif
<-ready not if
GetMouseCell ->my ->mx
CurrentCoords ->sy ->sx
<-mx <-sx eq <-my <-sy eq and if
0 GetMouseButtonDown if
true TraceStack ->ready
endif
endif
endif
The code is not perfect and needs some changes in order to be practical, but it does the trick.
Also, removing scripts from CRPL towers would be neat. (Adding them is already possible)
Well, yeah, that moves the towers upon selection, but I meant more integration with the in-game system for moving units, i.e. you get the cursor-selecty-thing, you get the green-shadow-thing that shoes you where it will move, and misc info on the bottom bar.
Quote from: Crazycolorz5 on October 12, 2013, 05:26:41 PM
1) A unit attribute that allows the CRPL tower to be selected and moved, like any other player unit. (and thus a move speed attribute)
I'd like this too, but for the purpose of being able to Deactivate, Disable and Stop Resupply to CRPL towers. Heck, even artifacts of odin have that capability.
It should be possible to poll whether a unit is activated, enabled or being resupplied. It would also be nice to be able to set that as well.
...and ultimately I'd like to be able to create custom interface panes for CRPL towers so we can add checkboxes or other controls like the ones that the spayer, strafer, bomber, bertha, etc. (actually just about everything has checkboxes, doesn't it?) have. Maybe even add buttons to create something like the forge interface.
Is this a good place to put my own suggestions? It's certainly a good thread title. But otherwise I'll start a new thread for that stuff.
About the first one, I've created such script with movement, deselection and everything, and when i get the time I'll probably release a tutorial around it and some more neat stuff! :)
Quote from: Crazycolorz5 on October 12, 2013, 05:26:41 PM
7) Command to dispatch packets to CN.
8) Ditto for aether/ore/anticreeper. (Energy-to-AC converters anyone?)
You can script that.
Proof
(http://i.imgur.com/rhBY91k.png)
A cool thing I thought about was a sling shot type of spore one that can have say waypoints would be interesting if someone could make that happen. I can see it now, a spore goes way out into the void to come around the back side of the base LOL
Silverite: You can make that happen, but those spores will be CRPLCores instead of regular spores, and as such will have to be taken down with snipers instead of beams:
$GRANULARITY:20
$SPEED:2
$PAYLOAD:10
@flyInAnArc(MapWidth mul(randFloat mul(1.2) sub(0.1))
MapHeight mul(randFloat mul(1.2) sub(0.1))
randUnitCoords)
SetCreeperNoLower(CurrentCoords <-PAYLOAD)
Destroy(Self 3)
:flyInAnArc
# curveMidX curveMidY endX endY :
# Technically, it's a quadratic spline.
->endY ->endX ->curveMidY ->curveMidX
# Calculate spline midpoint
<-curveMidX mul(4) sub(currentX) sub(<-endX) div(2) ->splineMidX
<-curveMidY mul(4) sub(currentY) sub(<-endY) div(2) ->splineMidY
<-GRANULARITY 0 do
I div(asFloat(<-GRANULARITY)) ->t
currentX mul(1 sub(<-t) dup mul)
add(<-splineMidX mul(<-t) mul(1 sub(<-t)))
add(<-endX mul(<-t dup mul))
->waypointX
currentY mul(1 sub(<-t) dup mul)
add(<-splineMidY mul(<-t) mul(1 sub(<-t)))
add(<-endY mul(<-t dup mul))
->waypointY
QueueMove(<-waypointX <-waypointY <-SPEED)
loop
while GetQueuedMoveCount neq0 repeat
delay(1)
endwhile
:FireArcSpore
# speed payload image scale : uid
->scale ->image ->payload ->speed
CreateUnit("CRPLCORE" CurrentCoords) ->spore
SetUnitAttribute(<-spore CONST_SNIPERTARGET true)
SetUnitAttribute(<-spore CONST_NULLIFIERDAMAGES false)
SetUnitAttribute(<-spore CONST_CREATEPZ false)
SetUnitAttribute(<-spore CONST_COUNTSFORVICTORY false)
SetUnitAttribute(<-spore CONST_TAKEMAPSPACE false)
SetUnitAttribute(<-spore CONST_DESTROYMODE 1)
SetImage(<-spore "main" <-image)
SetImagePositionZ(<-spore "main" 0.01)
SetImageScale(<-spore "main" <-scale dup)
SetImageRotation(<-spore "main" randFloat mul(2) mul(PI))
AddScriptToUnit(<-spore "arcspore.crpl")
SetScriptVar(<-spore "arcspore.crpl" "SPEED" <-speed)
SetScriptVar(<-spore "arcspore.crpl" "PAYLOAD" <-payload)
<-spore
Note that I didn't test this code, but it should be fine.
You should be able to script most of it, but I am not the best scripter, I am currently just testing around with things :P
While we're on the subject of CRPL player unit support -- have you tried moving a CRPL Core that's connected to the player network? It hangs on to its original connections and doesn't make new ones, like a moving player unit would. It hangs on to its connections regardless of distance.
You can cycle CONST_CONNECTABLE on and off to work around this a bit, but that has other side effects, including killing any incoming packets.
There's a lot involving connections that you can't do with CRPL. In particular I would love to see a way to set connections from a CRPL core. I had an idea for recreating the Beacon tower by having it force a connection between any units in its range and the three Command Nodes. If you could also alpha-out the connection lines, it would look like packets were floating directly to each unit. But that requires fairly specific commands to be introduced. It's also impossible plot-wise, since rift space was closed. But hey, it'd be neat all the same.
Looking at the wiki/docs, one thing that strikes me as missing is information about energy.
* How much is generated per second?
* What is the production of this collector? (This could be ill-defined, e.g. if generation is determined only in terms of soylent, overlap would pose some problems.)
* What is the production of this reactor? (Taking upgrades into account.)
* What is the total soylent area on the map?
Most of these could probably be scripted in an ugly and inefficient way, but since the game needs this information anyway, I suppose that it's easier if there were built-in support.
(Context: I was thinking of a custom map where building reactors would be limited to collectors generating the majority of the energy. The SetBuildLimit command deals with one half, but I need to be able to access energy generation information for the other.)
Instead of writing CRPL for that, you could just throw some tech packets around the map that allow you to build a few reactors each.
GetNearest
Arguments | Result | Notation |
X,Y,Unit Name | Unit ID | x1 y1 s1 - u1 |
Returns the coordinates of the nearest unit of a specified type.
Putting "Unit" as the Unit Name returns the nearest unit.
Unit names must be one of the follow strings. Names are NOT case sensitive.
Spoiler
UNIT
CRPLCORE
COLLECTOR
RELAY
REACTOR
OREMINE
SIPHON
TERP
GUPPY
PULSECANNON
MORTAR
STRAFER
BOMBER
SPRAYER
NULLIFIER
SHIELD
BEAM
SNIPER
FORGE
BERTHA
POWERZONE
OREDEPOSIT
RESOURCEPACK
SHIELDKEY
TECHARTIFACT
MESSAGEARTIFACT
THOR
CRPLCORE
RESOURCEPACK
TOTEM
EMITTER
SPORETOWER
RUNNERNEST
AETOWER
INHIBITOR
Edit: Grayzzur (http://knucklecracker.com/forums/index.php?action=profile;u=4535) was awesome enough to write this code that returns the UID of the emitter closest to the CRPL unit. It can also easily be modified to return the UID of something other than the emitter.
:GetNearestEmitter
-1 ->NearestEmitter
9999 ->NearestDistance
MapWidth 2 div ->cx
MapHeight 2 div ->cy
MapWidth MapHeight max 1 add ->range
<-cx <-cy <-range TRUE GetAllUnitsInRange 0 do
->eID
<-eID GetUnitType "EMITTER" eq if
<-eID CONST_COORDX GetUnitAttribute ->sx
<-eID CONST_COORDY GetUnitAttribute ->sy
CurrentCoords <-sx <-sy Distance ->sd
<-sd <-NearestDistance lt if
<-eID ->NearestEmitter
<-sd ->NearestDistance
endif
endif
loop
<-NearestEmitter
return