Upstream rebased

[BuckarooBanzay]

rebased version of #7

[OgelGames]

I'm not sure the movestones should have a recipe yet, when I tested them they were quite buggy... (which is why they are in #2)

[cheapie]

I'm not sure the movestones should have a recipe yet, when I tested them they were quite buggy... (which is why they are in #2)

If there are still remaining bugs in those then I'd like to hear what they are.

[OgelGames]

I'll have another look at them today, but one of the major bugs that I found last time I tested was when they crash into each other, they seemed to execute moves they were not programmed to do.

[cheapie]

when they crash into each other, they seemed to execute moves they were not programmed to do.

Some of this may have to do with them pushing each other out of position (it's possible to have two of them "fighting" each other such that neither can reach its target). I'm not sure if this really counts as a "bug" per se, nor am I entirely sure how best to resolve it - perhaps I just need to make them quit trying to move if they get pushed by another digilines movestone?

[OgelGames]

I did some testing again, and it seems to be more like they repeat moves sometimes, I'm not quite sure exactly... 😕

2021-02-22.14-50-10_3.mp4

[cheapie]

With the setup you have there, several of them are receiving more than one command as they slide along the stack of existing movestones, and at the moment the destination chosen by the "relmove" command is based on the existing target position. Would basing it off of the existing actual position instead more closely match what you expected?

[OgelGames]

Ah, that explains it... Maybe they should not accept new commands until they finish the current one, or maybe just not be conductive?

[S-S-X]

Removed commit 04b90d9 Add craft recipe for movestone so this can be possibly merged @OgelGames? Can look at movestones later, possibly dropping recipe or adding option to disable it until it is good.

edit. seem like it is now mostly docs or movestone stuff which now cannot be crafted so merging this.

[cheapie]

Ah, that explains it... Maybe they should not accept new commands until they finish the current one, or maybe just not be conductive?

I'd like to maintain them as conductors (helpful when running lines/arrays of the things) and also preserve the ability for the LuaC to "change its mind" about the target position, so the way I see it there are a few options at least as far as upstream is concerned:

• Keep the existing behavior (not great as it evidently confuses users)
• Accept absmove but not relmove commands when already in motion (might be even more confusing)
• Handle relmove commands while in motion by treating the current (not target) position as the start
• Handle relmove commands while in motion by treating the starting (not target) position as the start of the new command too

Any thoughts on which one of these is best? I'm sort of leaning towards one of the latter two but more or less indifferent as to which.

[OgelGames]

I think the 3rd option is probably the best, as it fits better with the relative movement concept.

[cheapie]

I think the 3rd option is probably the best, as it fits better with the relative movement concept.

Sounds good to me, then - might be a day or two until I have time to work on digistuff again, but when I do I'll go for that one.