Analysis of a CRPL script

[lurkily]

And . . . . I'm not sure what's going on.  The cells that transfer creeper seem to absorb HUGE amounts, but seem to output very little.  I'm going to put this away, and come back to it in the morning.

[knucracker]

The new build is up with a fixed GetCreeper...

What you are doing should be a problem.  SetCreeper is "live" meaning it should change the contents of the cell immediately upon execution.  What you really need to do is to calculate the average once, before you do any SetCreeper call.  Then use that value for each call.

This teeters (actually, it goes over) the line for needing something else for variable management.  I have left out any heap calls, or registers, since I wanted to see how long it would be before someone hit the need.  To make this work right now, you have to do this.  Hold on, it's ugly....  (I can just hear Grauniad laughing maniacally after reading the following):

Code Select Expand


CurrentCoords GetCreeper 55 31 GetCreeper add 2 div
dup
55 swap 35 swap SetCreeper
CurrentX swap CurrentY swap SetCreeper


[knucracker]

Also, I understand the math of what you are trying to do (set two cells to the average value of the two cells), but I'm not grasping why you are wanting to do this.  Are you trying to make sure two pools stay at the same level (over time)?

[lurkily]

Wow.  That verges on a hack.  That's the problem I expected, pretty much. 

Basically, I'm experimenting with creating what is basically a micro-rift that passes Creeper/AC.

[knucracker]

Ahhhhh....
Yes, you face 'the problem'.  If the microrift flows in both directions, it gets a little complicated.  The average might work... will have to think about it.  A one way rift is easier, btw, and you could create two towers that each teleport only one way.  In that case, they only teleport if the destination is less than the current location.

The newly posted build seems to work fine with the above code I posted.  That code just calculates the average once, duplicates it (since it will be needed twice) then swaps it into position so it is the correct argument for each SetCreeper call.

What would have made this much cleaner was local variable support.  I just haven't decided on the exact syntax for that and if I want it to be a free form variable name or more like a register.  For instance

Code Select Expand


CurrentCoords GetCreeper 55 31 GetCreeper add 2 div Write0
55 35 Read0 SetCreeper
CurrentCoords Read0 SetCreeper

This is one super simple way to support local variables.  There are just 8 or so Read/Write functions and you can use them to store and recall things for the current script invocation.

The other way is to allow some arbitrary string to follow Read (separated by a space or an underscore).  That would be the variable name and you could have many of them....

[lurkily]

Yes, one-way is infinitely easier.

Updated my build.

It doesn't behave as expected for me.  I put in a delay of 60 on the script, too.  It DOES transit creeper, yes.  But I've got an emitter cells away, depth of 50, delay of 1 frame.  EDIT:Trapped on a small island with that emitter, too.

One cell away from the CRPL tower, depth is always 15 or 17.  ON the tower, it's hovering around  4.15.  At the destination, 1.15.

Somehow, it's digging a hole in 50-depth creeper, all the way down to 4-5, and only outputting miniscule amounts.

[knucracker]

Let me see your code, or a save game, and I'll take a look.  The average technique seems to work for me as a bidirectional gateway.

Another technique would be to subtract the source and the destination creeper values and then take some fraction of that difference and subtract it from one cell and add it to another.  That would work the same way as the Creeper sim works internally.  It would basically link two remote cells as if they were next to each other.  Creeper would always flow from the greatest to the least, but take some time to do so.

[lurkily]

I may have found the problem.  The output log shows build 83, not 83a.  I may have left the same .zip file open, and when I opened the new file, and had two windows open on that far monitor, I may have re-installed the old build.  I'll add to this post when I try re-installing.


That seems to have corrected it.  Another problem is that I was looking so hard to understand your dups and swaps that I forgot to check the numbers.  Creeper would transmit to 55,35, but the average function was a copy of the first one I posted, which was 55,31, and I didn't catch that and clean it up.

So it was averaging cells in two places, but the transit terminus was slightly offset.  I still think the flaw in SetCreeper was responsible, though.

Eventually, I plan to design an entire region that conducts creeper fast much like digitalis - but instantly.  That way each cell of the region takes the average value, for very fast flanking moves.  Evap will limit spread to some degree, so digitalis would be needed to limit that.

That will probably need to wait for variable support, though, or else things are going to get very complicated.  (I personally wouldn't need named variables, though it makes some things less complex.)

After that all we need is a way to construct fields, and attach them to these towers.

EDIT: Sorry to have you here analyzing this script when your time's much better-occupied working on the game. 

[knucracker]

Don't apologize... this sort of thing is why I posted the build and it's what I'm looking for.  Watching what people do with CRPL (if anything) is very important input in determining whether I keep it or not as player exposed functionality. 

CRPL represents a huge degree of power in the hands of a maps maker.  With that power they could make a truly beautiful experience or a horrible nightmare.  What I don't want is 10000 tricksters all making joke maps.  If the complexity of the language is high enough to keep away the casual idiot, but accessible enough to let through an interested player... then I might thread the needle and keep it.

[teknotiss]

Don't apologize... this sort of thing is why I posted the build and it's what I'm looking for.  Watching what people do with CRPL (if anything) is very important input in determining whether I keep it or not as player exposed functionality. 

CRPL represents a huge degree of power in the hands of a maps maker.  With that power they could make a truly beautiful experience or a horrible nightmare.  What I don't want is 10000 tricksters all making joke maps.  If the complexity of the language is high enough to keep away the casual idiot, but accessible enough to let through an interested player... then I might thread the needle and keep it.

just in my own experience of code monkeys, some of the nastiest tricksters have been expert coders. i spent a lot of my college career fixing the hacks/deletions (of non-computer students course work) from the jokers/evil-fiends in my class.
i've barely started looking at the possibilties of CRPL and i can see that you could end up with lots of barely winnable maps and nearly unkillable bosses. but given the scope of the code there isn't much option for limiting that behaviour, except through map mods i suppose.

[TrickyDragon]

in terms of these towers, they can be OP, but i think we would do better to put the restraints on maps through modding rather than the limit of the unit function.   There will be bad maps, and there will be great ones......