CRPL related questions

[eduran]

As to the CRPL... what did I do wrong?

Nothing, actually. I copied the code to a new project without any changes and the slip emitter shows up at 10/10. Check if you manually set childX on the core to a different value. If that's not it, make sure you are really using the code you pasted here and that you compiled it (that one never gets old for me: fix a bug, forget to compile, bug still exists, go off on a wild-goose chase to find cause of the no-longer-existing bug ;D)

[Flabort]

 ???
Well, I copied the one I pasted to the forum into a new project too, laid out terrain, and just compiled and attached the scripts to a core. No dice. It showed up at 1/10. Also tried to set one to 85/62 afterwards... it showed up at 1/62.

So it's not that I didn't compile this time. Still, thank you for checking, that would have made my week.

[eduran]

Found the reason why it worked for me: I got the name of the child script wrong, so it was never attached to the slip emitter. That script is causing the problem. Remove the quotation marks from all CONST_SOMETHING and you should be good.

[Flabort]

...quotes around the CONSTs.  ::) I should have known, thank you so much. It works perfectly now.  ;D

[jakeflee]

is there a way to make a button on the screen i don't see a draw pixel like functions only camera and image functions but i don't want to use an image function->

[Clean0nion]

is there a way to make a button on the screen i don't see a draw pixel like functions only camera and image functions but i don't want to use an image function->

You can't put a custom image on the screen without using an image function.

[jakeflee]

dam ok

[eduran]

Say you have two scripts, parent and child. Parent is attached to a CRPL core, creates a new core and attaches child to that new core. Obviously parent will execute before child on the first frame, because child only exists if parent was executed at least once. But what happens now? Will parent always execute first or can the order switch around?

[Clean0nion]

Say you have two scripts, parent and child. Parent is attached to a CRPL core, creates a new core and attaches child to that new core. Obviously parent will execute before child on the first frame, because child only exists if parent was executed at least once. But what happens now? Will parent always execute first or can the order switch around?

I suppose it depends entirely on the length of the script.

[Relli]

Say you have two scripts, parent and child. Parent is attached to a CRPL core, creates a new core and attaches child to that new core. Obviously parent will execute before child on the first frame, because child only exists if parent was executed at least once. But what happens now? Will parent always execute first or can the order switch around?

I would have to assume that they happen simultaneously. If they in some way rely on each other frame-by-frame, like one changing the details of the other, then I couldn't say for certain when the change would take effect. Though you might be able to set up a trace log thing that would show you for certain.

[eduran]

To add some context to why I am even asking:
I created a custom unit, the Creeper Tunnel. For the player it looks like two cores (with custom images) connected by a line. This line is an image added to one of the cores, stretched and rotated to connect the two. The core that has the line attached checks the position of both cores and does the strechtching and rotating. Works like a charm.
Then I allowed the cores to move around. At that point I noticed that the line was slightly trailing one of the cores (the one that didn't draw the line). Instead of connecting to the center it connected to where its center was the last frame. Using

Code Select Expand

GetUnitAttribute(<-otherCoreUID CONST_PIXELCOORDX/Y) actually returns x/y values corresponding to otherCore's position during the previous frame. If I run that command on both cores and trace the result, they are different.
At least they were until I deleted both cores, placed them again and added the scripts in a different order (core without line first, core with line second). Doing that, the script works as intended. Adding the scripts in reverse order causes the 'bug' I described. Looks like a text-book race condition.

I guess what I need to know is: is it 'save' to make a map like this, finalize and upload it? Will it run on everyone's machines if I've got the order right on mine? Or can the same bug pop up randomly on other computers/times of day/phases of the moon?

[Grauniad]

One of the reasons I'm against these Omnibus threads is that Virgil doesn't always look at later posts in a thread. People here have a tendency to drag topics off-line and then continue them ad-infinitum. If you want to ask a question that Virgil is best positioned to answer, then start your own thread with a topic title that pertains to the question.

My take is that it may depend on a number of factors and I just don't know, apart from that the order of execution has never been explicitly defined.

[knucracker]

The execution order of units is the order of this Unity API:
FindGameObjectsWithTag

And that is basically undefined.  This means you can't rely on the order of execution with a given frame.  Save/Load could also perturb the order along with unit creation and destruction.
Now I could probably make the execution order be defined.  The order would always be latter units execute later than earlier units (creation order).  This would introduce a small performance loss, though, and of course would only show up in future builds.

[knucracker]

Actually... let's try this for the next build.  Unit updating per frame will be done from oldest to youngest.  This is based off of the unit UID.  Basically the unit UID is an int and this int only ever goes up as units are created.  Updating happens on a sorted list of these units per frame.

There should be a very slight performance degradation that should be worse the more units that are on a map.  But I doubt it will ever be noticed as it will be a tee-tiny fraction of what is going on in the game.

So try the upcoming 165 build and see if everything seems ok with this...

[eduran]

Wow, that was fast. I did some quick tests and everything seems to work as you described. With 1.64 I am sometimes able to change the execution order by saving/reloading and by just having stuff happen (not sure what exactly caused it). In 1.65 it is unperturbed by anything I tried to mess it up. Now I just hope that doesn't ruin the frame rate on lower end machines.

One of the reasons I'm against these Omnibus threads is that Virgil doesn't always look at later posts in a thread. People here have a tendency to drag topics off-line and then continue them ad-infinitum. If you want to ask a question that Virgil is best positioned to answer, then start your own thread with a topic title that pertains to the question.

Yes, sorry about that. I didn't have much time when I first posted the question and just threw it in here. Making a separate thread would have been better.