<div dir="ltr"><div>Multithreading (script fibers) is a prereq for implementing slice animation/reaction script hooks (that is, running a HS script instead of running an animation... script... terminology needs some work), because animations need to run inside battles and menus, should run at the same time that an animation/reaction would have been run (immediately at the point the reaction is triggered? **) eg when the sprite slice is updated/processed.</div><div><div>(Plus script OO might also be a prereq if those scripts are actually class methods? I don't know.)</div></div><div><br></div><div>However there's no need to implement script hooks to begin with; that can be added later. General slice animations and animation ops other than some basic sprite ones can also be added later, though I want to settle on an extensible file format (what I currently have for .rgfx, but don't actually use yet, isn't general enough).<br></div><div><br></div><div>** In Godot, signals and method calls are often deferred (put on a queue to be run at "idle time") out of necessity. I wasted a lot of time trying to get initialisers to run in the desired order. You can pass a flag when registering a signal handler that you want the call to be deferred. I had something similar in mind: if you attach a plotscript to any sort of trigger (not just animations), you get the current behaviour. But we could have other script types, say "object scripts" or "npc scripts", which behave differently when triggered. They could run immediately and not suspend any plotscripts. Plotscripts would be the unique script trigger type you use for cutscenes, since only one cutscene plays at once, and they pause inside menus.<br></div><div>Incidentally, Godot's script interpreter is (optionally) multithreaded, which really shows that the devs are insane enough to want it all. You have to do your own synchronisation to get thread safety, such as using deferred calls across threads, or it will crash since it seems locking isn't always done, for speed.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Mar 2020 at 22:52, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>I was skeptical about animations moving slices, but in this mail you have convinced me.<div dir="auto"><br></div><div dir="auto">I see no problems with any of these suggestions.</div><div dir="auto"><br></div>Does implementing all this require script mutilthreading to be implemented first? Is that a prerequisite?</div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto">James Paige<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020, 1:47 AM Ralph Versteegen <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>My work on animations and other features is held up quite a bit by design decisions being interdependent on many other features which haven't yet been designed/agreed upon. I've tried writing up this stuff several times before, but I never reach the end of that writeup, so I'm just going to split it out over a number of emails, full of loose ends, get feedback, and try to incrementally converge to a plan. The title outlines the scope (all about slices and OO).<br></div><div><br></div><div>Learning Godot has been hugely helpful, providing new ideas, validating ones I had, or suggesting where to diverge from or improve upon Godot. (For example, nodes in the scene tree have an integer-valued "z index" which is exactly the same as the slice "z index" I proposed once, and it turns out to be wonderfully useful indeed).</div><br><div><br></div><div>=Slice Animations=<br></div><div>One thing I was very unsure about was whether to allow sprite animations to move the sprite slice's position or just offset where the sprite is drawn relative to the Sprite slice position, and handle slice movement by some other animation system, or just have no movement at all and keep animtions simple. I now think that moving the sprite slice is a very important feature (eg we ought to aim to allow this without scripts: <a href="https://cdn.discordapp.com/attachments/275093304322818049/688893625110626311/treasurevalley0022.gif" rel="noreferrer" target="_blank">https://cdn.discordapp.com/attachments/275093304322818049/688893625110626311/treasurevalley0022.gif</a>  )</div><div>In fact I think that sprite animations should actually be slice animations.</div><div>Yes, a slice animation system is more complex than a sprite animation system, but a powerful animation system with a good UI which requires no scripting is *vastly* easier than requiring users to learn HS and write scripts.<br></div><div><br></div><div>Allow any slice to have animations, which are automatic changes to the slice's attributes.  For example a rect that shifts between different colours, or a container slice that slides on- and off-screen. A sprite animation will then be a slice animation that also has additional animation operators to change sprite-specific data, and we would other other slice type-specific ops too.<br></div><div><br></div><div>=Animation ops=</div><div><div></div><div>Many but not all slice attributes would be mutable with slice animations. The ops could be (de)serialised as RELOAD nodes overlapping how Slices are (de)serialised.</div><div><br></div></div><div>Sprite animations will have a simple "play this frame group, X ticks per frame" option.<br></div><div>Aside from that, I had a series of "set state, wait" animation operators in mind. But we should also have complex operators like "interpolate attribute X from value A to value B over T ticks, with <a href="https://easings.net/en" rel="noreferrer" target="_blank">easing function E</a>. (I guess initial value A isn't needed, though it would help the animation editor to know the initial state) These are only available for "continuous" (though still currently integer-valued) attributes like position, padding, palette index (because palettes contain ramps).</div><div><br></div><div>As soon as you talk about slices, you have slice trees. Animations ought to be able to tell child slices to do something, and maybe even to spawn children. Sometimes directly modifying child attributes from the parent's animation is far easier than using an animation on the child. Particularly for moving children (e.g. synchronising movements and the gif linked above).<br></div><div><br></div><div><div>=Slice reactions/hooks=</div><div>Non-sprite slice animations may sound limited, but "animation" is a codeword for "script created in an editor instead of written in HS". I want to allow animations to be script hooks, so you can attach a script instead of defining an animation. Think of a slice as an instance of a class, and animations and "reactions" are methods or hooks called upon a signal.<br></div><div><br></div><div>Hand-waving, reactions are just animations, but when you play an animation it stops and replaces the existing one, while when you play (trigger) a reaction it doesn't. Reactions probably could still contain wait commands. Maybe the only difference between the two is that reactions end in "return" while animations end in "loop" or "goto idle"?</div><div><br></div><div>There's plenty possible hooks for a slice to have. They could react to generic events like being created, mouse-over, selection, activation (click/use). (Basically I want to get rid of the hard-coded plankmenu reactions in the Items menu and elsewhere.) But also we already have these SliceContext types: so far just NPCSliceContext and HeroSliceContext. I'd like to be able to treat slices that have one of these *as* an NPC or hero for some purposes. These slices could receive NPC/hero specific signals like "use", "each-step", "turn", "pushed" and signals triggered by entering/exiting/stepping in zones (e.g. to change the walkabout palette in shadows). Examples in battles are more interesting.<br></div><div><br></div><div>I hear some animation systems are organised around "states" and "transitions". Consider transitions like moving from standing to running - what if you want a special animation for that (probably a couple existing frames with different ticks-per-frame)? I wonder how reactions could be used for that.</div></div><div><br></div><div><br></div></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" rel="noreferrer" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div>