Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

I'm not sure how it all works behind the scenes, or maybe my suggestion wasn't super clear as I can easily imagine editing still working as the loop is running: If the PC is already beyond the edit point, it simply continues following the path as normal - it would only encounter an issue next loop. (This would theoretically work better than the current design, because if I try to edit my early path while the PC is running a later section of it,  e.g. by adding a left then right movement, it breaks at the moment.) If it's before the edit point, it can pause when reaching the broken end like it does now at the end of the whole set (if you don't have autoloop enabled).

I imagine you'd have to do something like have each instruction essentially remember which tile it was originally placed on (or maybe the PC's tile when the action was invoked for interactions). There are *perhaps* some niche situations where you might want to shift the entire latter portion of the instruction queue in some direction, but especially with the current map design consisting mostly of 1-wide width corridors and very few open spaces, it's hard to see that making more sense most of the time.

Yeah I misunderstood your suggestion, my bad. Actually, that was the earlier version of queue essentialy, however when it doesnt recompute the further actions it was really hard to see which actions are actually orphaned and which are not, hence I made this version. Hmm maybe if I went with coloring the orphaned queue red it might work out, cause you're right that even tho we lose the ability to edit further route, it IS a niche use and its more important to make queue more user-friendly. Added it to known issues to try it out, but it'll take a while before next 0.3 patch, want to add more content

(1 edit)

Ended up adding a hotfix, couldn't help myself ^^