Will we see more connection and packet CPRL functions?

[pawel345]

There was one a thread about what things would be cool to be added to CRPL. I through to bump it as it got forgotten in time and space but it was more of a discussion what is and isn't possible using CRPL I started a new one.

What can't be done right now:
Connections:

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.

So basically it would be nice if you could set not only connectable but also can make connections(like a relay or collector), as well as define their length. And maybe packet speed also it that wouldn't mess up the pathfinding algorithm.

Another thing that would give mapmakers incredible possibilities are carmozonium? walls(pink ones from CW1) especially if implemented as a CPRL function for target cell (so that other properties like image and normal wall behaviour are up to mapmaker)

Packets:
CPRL cores sending all kind of packets. Also CPRL cores eating all kinds of packets. And generating/using raw energy/aether.


So my question is will we ever see any of those things implemented? And if yes a long(someday/maybe) or short(If there are no important bugs/things to do) time scale?

[knucracker]

When a crpl core moves and is set to Connectable it should dynamically connect and disconnect.  It is a bug that it doesn't and I have just fixed this bug.

Crazonium... maybe but not today.

Packets... most likely not in a general case.  There is a lot of work that goes into sourcing energy/ammo packets.  The problem is you have a graph.  Nodes in that graph want packets.  They request packets from the nearest (along the graph) source, which has the energy to fulfill the request.  As the number of sources increases the time it takes to make this calculation on a large graph is substantial.

Now ore packets, those I could add without much trouble.  They always get created at a source and then go to one of the three CN's, or a guppy

[pawel345]

I get that maybe ammo and AC can get tricky too bad, no custom AC guppies :P

But what about aether and energy generation(reactor like?, or simply increase of "internal" production as in this CPRL core increases energy production of CN1)?

[knucracker]

Ore and Aether packets.... I could add APIs to make them.  So you could make a 'Converter' that takes ammo packets and gives you aether or ore as a result.  But note that this can already be kinda done.  You could make a converter core that loads up on ammo then creates an aether, ore, or even energy pack next to itself.  You could make a converter core that sucks up AC and does the same.  The graphic for this converter core could even reserve space next to itself for the pack to appear (with a siphon already on top).

To take one case specifically that seems strange, take the case of a converter core that say loads up on 100 ammo then it creates an energy pack next to itself that you can use.  That energy pack might contain 200 energy.  Sounds interesting and a way to get free energy, so long as you wait a little bit.  However, you might make it so that the process of creating this energy packet does something harmful.  Maybe it creates 10 little blobs of green mist that float off.  Anything they come into contact with gets damaged.  Eventually they fade out, so it isn't permanent.  But you might want to put these dirty converters away from your main base.

In other words, there is already a way to put ore, aether, and energy on the map... you just do so in the condensed form (the packs).

As for energy production tweaks...  yeah, maybe.  But making energy packs still comes fairly close to accomplishing the same thing in a much more visual way.

[pawel345]

I hadn't through of that. But is there a way to put completed player structures on the map? Then indeed that could be the way to do this :D

[Clean0nion]

When a crpl core moves and is set to Connectable it should dynamically connect and disconnect.  It is a bug that it doesn't and I have just fixed this bug.

Crazonium... maybe but not today.

Packets... most likely not in a general case.  There is a lot of work that goes into sourcing energy/ammo packets.  The problem is you have a graph.  Nodes in that graph want packets.  They request packets from the nearest (along the graph) source, which has the energy to fulfill the request.  As the number of sources increases the time it takes to make this calculation on a large graph is substantial.

Now ore packets, those I could add without much trouble.  They always get created at a source and then go to one of the three CN's, or a guppy

I tried making this in CRPL the other day. I ended up going over the operations per frame limit. Made the game just a little bit laggy.

[eduran]

In other words, there is already a way to put ore, aether, and energy on the map... you just do so in the condensed form (the packs).

Creating the packs is easy, but how can you specify resource type and amount? I assume SetScriptVar is the way to go, but what are the variable names?

[knucracker]

Wow... I could have sworn I had exposed names for setting the pack types and amounts.  I'll add those in right fast so everything I said above will be possible.

--edit--
In the upcoming build the vars are
AMT  [Max amount of resource the pack holds.  Will increase MAX_AMT if AMT > MAX_AMT]
MAX_AMT [Current amount of resource the pack holds]
RESOURCETYPE {"ENERGY", "ORE", "AETHER"} [The type of resource]

[knucracker]

So this will work in tonight's build:

Code Select Expand


RandCoords ->ry ->rx
CreateUnit("ResourcePack" <-rx <-ry) ->rp

RandInt(0 3) ->randInt
if (<-randInt eq(0))
"ENERGY" ->rt
else if (<-randInt eq(1))
"ORE" ->rt
else
"AETHER" ->rt
endif endif

RandInt(50 1000) ->amt

SetScriptVar(<-rp 0 "ResourceType" <-rt)
SetScriptVar(<-rp 0 "Amt" <-amt)

CreateUnit("Siphon" <-rx <-ry)

Delay(30)


[Clean0nion]

You may consider this and the new constants added to the wiki. I've made sure that it's clear it's added in 1.66.

[pawel345]

Wow... I could have sworn I had exposed names for setting the pack types and amounts.  I'll add those in right fast so everything I said above will be possible.

--edit--
In the upcoming build the vars are
AMT  [Max amount of resource the pack holds.  Will increase MAX_AMT if AMT > MAX_AMT]
MAX_AMT [Current amount of resource the pack holds]
RESOURCETYPE {"ENERGY", "ORE", "AETHER"} [The type of resource]

Wait... So AMT is the max amount and MAX_AMT is the current amount? What's the reason for such a bizarre naming?

[Annonymus]

Wow... I could have sworn I had exposed names for setting the pack types and amounts.  I'll add those in right fast so everything I said above will be possible.

--edit--
In the upcoming build the vars are
AMT  [Max amount of resource the pack holds.  Will increase MAX_AMT if AMT > MAX_AMT]
MAX_AMT [Current amount of resource the pack holds]
RESOURCETYPE {"ENERGY", "ORE", "AETHER"} [The type of resource]

Wait... So AMT is the max amount and MAX_AMT is the current amount? What's the reason for such a bizarre naming?

I believe that was a misspelling because of the "Will increase MAX_AMT if AMT > MAX_AMT" part...

What about CRPL towers requesting AC/Aether? I know you can make the tower absorb AC but it already has to be there, so it's impossible to do a tower that "steals" your ac like it's possible with energy. I suppose for the aether one you'd need to do some things to deal with the forge, but if you make a priority list, like "if there is an active forge send the aether to the forge, else send it to the newest CRPL tower that requests aether" that would open space for things like an aether-ore converter, in a map where you have to balance between using aether for upgrades or use it to fight against the creeper.

The ressource-crystal thing doesn't work because you can't create built buildings, this means as soon as the tower using it gets submerged in creeper you have to re-build the siphon by hand, or at least send the packets to build it (and connect it to your network).

[knucracker]

Yeah, I just mixed up the descriptions between AMT and MAXAMT.  Everything is fine in the game.
Btw, the name is MAXAMT not MAX_AMT... I messed that up to in the previous post.

As for requesting AC, there is CONST_REQUESTACPACKETS.  In theory you can make a tower that when connected to a network will request AC.  I can't say I've tested it...
As for requesting Aether... that can't be done.  Aether only ever goes to the forge. Those packets are just hard wired to do that.

Correct, resource packs require siphons.  If a pack gets covered in Creeper any siphon will no doubt get destroyed (unless you monitor it and keep it's health high... I've never thought of that....).  Anyway, you  can create units in the built state in the upcoming build by setting their CONST_ISBUILDING attribute.  So for the simple case of a converter tower that creates a resource pack, it can also create a prebuilt siphon on top of the pack.

The following code seems to work in the upcoming build for tonight.  Note that the pack can sit in a pile of creeper and never die.  Now it shows 99% health and has a nearly full health bar, though.  This is because it updates after the script that created it per game loop.  In theory if you created a hidden crpl tower after creating the siphon, and let that tower monitor the siphon's health... that would prevent the health bar from showing up (because younger units update later in the game loop).  This is a cosmetic problem, though, and probably not work the extra complexity to address.

One last game play note about a siphon that can live in Creeper.  Since CN's can sit in  Creeper for a while you can go commando with your CN and land it next to one of these creeper hardened siphons.  That allows collection of ore/aether even while the whole thing is surrounded by Creeper.  So if you do this kind of thing factor that into your mission game play considerations.

Code Select Expand


once
CreateUnit("ResourcePack" 10 10) ->rp
SetScriptVar(<-rp 0 "ResourceType" "ORE")
SetScriptVar(<-rp 0 "Amt" 100)
SetScriptVar(<-rp 0 "MaxAmt" 100)

CreateUnit("Siphon" 10 10) ->siphon
SetUnitAttribute(<-siphon CONST_ISBUILDING FALSE)
SetUnitAttribute(<-siphon CONST_HEALTH 999)
endonce

SetUnitAttribute(<-siphon CONST_HEALTH 9999)


[DanTheGoodMan]

Now it shows 99% health and has a nearly full health bar, though.  This is because it updates after the script that created it per game loop.  In theory if you created a hidden crpl tower after creating the siphon, and let that tower monitor the siphon's health... that would prevent the health bar from showing up (because younger units update later in the game loop).  This is a cosmetic problem, though, and probably not work the extra complexity to address.

At least in v1.53, I'm able to hide the health bars on the siphon.

Code Select Expand


SetUnitAttribute(<-siphon CONST_SHOWHEALTHBAR FALSE)


[pawel345]

Ok I have a new question. Since we might get AC guppies soon, I wanted to ask if it's possible to CRPL create a guppy/strafer/bomber away form their pad. Or to give them an order using CRPL. Since If it where possible one could send AC packets by creating a full AC guppy landed somewhere.
But that would require access to player unit variables...