OHRRPGCE feature requests/suggestions

I love the simultaneous network editing idea, as far-fetched as it seems.

If I implement a version of 'Test Game' with Custom running on one computer and the game on another, it means I'm warming up ;) ...I just need to figure out what that would be useful for!

The network is the computer!

D&D

---

<TheGiz> oh hai doggy, oh no that's the straw that broke tjhe came baclsb

stencil slices sound really cool. Maybe sometime in the future perhaps?
I think it sounds like an eventual necessity because currently all slices are boxes!

I, personally, think they are a good idea.
What if you want slices to be visible within a slice and not outside of it?

I would like to see a "visual effect slice" type that has some sort of pre-set visual effects, such as blurring, fading in/out, jiggling, flashing, changing colour, rotating, scaling, animation, or maybe some of the death animations?
Again, it would be handy to be able to set the timer, in ticks, through the slice editor.

I see that this is already possible for sprite slices and that you can run the animation backwards too! but I would like to see the effects being run also in different directions such as upwards or to the side, and also applied to other slice types.
I would also like to see the list of animations extended, perhaps.

Would it be easy to change "dissolve sprite" into "dissolve slice" and have an extra argument for the direction of dissolution?

EDIT
I would like the engine to be able to handle simple animation/scrolling like this in the future:
https://68.media.tumblr.com/5a0efee314a36a29a36002d9183d4546/tumblr_opbd9wkCGs1u77u56o1_500.gif

EDIT
I would also like to apply filters to slice to desaturate them, turn them into different colours etc., and that could be useful in creating drop shadow effects, blur, image trails and other things too

I'm not totally familiar with how git does automatic merging. Would it be able to merge .hss files automatically? Even that would make collaborating on a game via GitHub pretty nice.

---

My pronouns are they/them
Ps. I love my wife

Yes, version control systems like git can merge text files easily. As long as you and your collaborator haven't edited the same lines, the changes are simply combined. I'm still amazed that this optimistic strategy never seems to lead to problems.

I have used git for several collaboration games where I wasn't the only one editing scripts. Still only one person at once can edit the game itself, though. (Note that you definitely should unlump your game to an .rpgdir. Then you can actually manually merge changes to a .rpgdir as a whole, as long as you're not working on the same parts of a game.)


Easy, you can do this by setting "Clip Children: Yes" on a slice.

Most of your other requests are covered by sprite slices playing animations.

I do want to add some arguments to modify some of the dissolve animations, but don't expect much.
Dissolve animations will never be available for other slice types.

Many of your other requests such as rotating, scaling, tinting, blurring would require converting the engine to use hardware accelerated graphics.

Fair enough.

Could we get a visual indicator of the slice trees branches?

Something like a line running down the backbone of each level, it would help to distinguish parentage layers a little more.

They don't really have to be connected in an actual tree, just a straight vertical line running down the backbone of the branch would be useful perhaps when you want to see your slices at a glance.

EDIT: For example, 2 parallel lines (straight, wavy, zigzag) could denote a branch, and 2 concentric rings could denote a "node" or something like that?
I would like to see more opportunities to visually distinguish things in the various editors.

EDIT:

This only works for box shapes? Am I missing something?
What if one wants to put a portrait within a circle (for instance) or have an image bisected (etc.,) by a diagonal line?

I meant rectangular clipping; non-rectangular clipping would be the stencils I was just talking about!

Visualising the tree of parent relations spatially is an interesting idea, so I tried it out really quickly. Thelines connect the anchor point for each slice. Not sure how useful it will be but could just assign it to some key.

Maybe this is not at all what you meant.

Not quite, but it is really cool and maybe it will be useful in the future?

Perhaps selected slices and their children could be highlighted and the links could be a different colour too?

I am in favour of alternate views and layouts for the slice editor in general, but it looks a bit cluttered. I think that full unbroken lines are a bit too much. I rather like the "little white ants" border thingy that slices currently have.

How come there is not a "line slice"? I would like to see the possibility of diagonal shapes for slices in the future.

Request: Can we have a description field for heroes that shows up in the status screen?

I'm still not sure it's worth adding; maybe a way to highlight all the ancestors of the slice under the mouse would be more useful and achieve most of the same thing.

I certainly agree the editor is cluttered.

It's silly, but the reason I personally haven't added a line slice yet is because creating a slice with negative width or height would be the most obvious way to let the line go in any direction, but the slice editor doesn't let you create negative width/height slices (although you can do it by script, where it's used for storing data). I'm not sure the slice editor should; what goes wrong if you use negative width/height? I would have to test it.

I had similar thoughts about lineslices and negative sizes

But it just now occurred to me, maybe that is the wrong approach to line slices?

What if a lineslice actually drew the line from it's anchor point to its parent's anchor point?

Even though that is drastically different than other slice types, I think it would be really versitile and easy to use

EDIT: I am already thinking about how I would script a "Balloon Seller" NPC using that type of lineslice :)

I went and played around with the slice editor, but am still struggling to figure out what that means.
By "parent anchor point" I guess you mean the "align" setting on the line slice, offset by its X and Y position?
Meanwhile the "anchor" settings on a slices are affected by its own size, so width and height could play the role of X and Y.
But if line slice positions are computed in the same way as all other slices (and I would hate to make an exception to that), then these two points are the same? Or you don't want to add the X,Y value to the align/parent anchor point?

A similar proposal would be to draw the line from its anchor point to the opposite corner.

Both sound like they tie position to the line direction, which would seem to imply that you would be sometimes forced to use a container as a parent to make the line do what you want, which would be rather awful.

I just tried out negative widths in the slice editor. I notice the size/position of rectangles and ellipses are off by one pixel. Wrapping text slices don't wrap. Scroll slices are misdrawn. Panel slices become very confusing, with the % and pixel measures acting in opposite directions. The order of the panel and grid slice children is reversed. Positive padding moves a child outward rather than inward. Children set to fill inherit negative size.
I think that negative sizes are OK at long as we fix these problems by using the absolute value of the width and height and swapping the direction of anchor points if the size is negative, so that the right edge is always the right edge as seen on-screen, and positive padding moves inward. Panel slices can do the same, but I think the reverse ordering of children is good.
Children set to fill inheriting negative size may be useful if they are line slices.

Another question leading to an alternative: what if you want lines thicker than one pixel? Clearly that should be a setting. But what if you want multiple line slices end to end? If you want the ends to join up properly then either you need to draw discs at the line ends, or you need to draw all the lines together, as a polyline object. Should we have polyline slices? If we did, then the slice would have a list of control points, so negative width/height would be unnecessary.

Or, an alternative direction: what if we want to add slices to draw curves (eg bezier curves)? That's certainly useful to have a slice for. Curves are generalisations of lines so we might as well have a single slice type for both. (But who said a line has to be straight? We could call it a line instead of a curve). Curves again have control points, so we wouldn't need negative sizes.

I thought about it, and realised that children inheriting negative size when you negate the size of a parent, but not having everything else flipped, is way too inconsistent.

Imagine you literally draw a tree using a tree of line slices, and then you negate the size of the root node. Suppose negative size is inherited and all the slices are set to fill (using panel/grid slices or padding for sizing). Would you get the mirror image?
If any of the slices use non-zero X or Y, because X and Y directions aren't flipped, positions are incorrect.
If left-right directions of anchor points don't get flipped, as I proposed, then using anything other than panel or grid slices means the branches aren't inverted.
Of course, every slices has to fill its parent, so that anchor points are ignored.
On the other hand, if negative sizes aren't inherited, then the tree still draws exactly the same, shifted left/up but not mirrored.
Conclusion: we can't really support mirroring a slice collection by making negative size inherit, so we shouldn't even try; it's not useful.

If we seriously wanted to allow mirroring a slice tree, like you could do with a scene graph (say, you want to show the mirror image of a whole textbox), then we need a new slice property (similar to 'fill parent') or slice type for applying transformations (project matrices) to a slice tree. Meanwhile we can make negative sizes act however we want.

...

You see, this is we don't have line slices.

Yeah, I was probably wrong to say it should point to its parent's anchor.

Rather than think of this from a slice-data perspective, it might be better to think about how I would use it in a game, and then think about what the slice would need to do to implement that.

Back to the idea of having a baloon slice attached to an NPC slice with a line.



Here is a possible idea about how I might want to use a line slice.

Parent it somewhere purely for sort-order, then connect the ends of it to special line anchors relative to other slices, and then forget about it, only moving the other slices.

What would this method mean for the LineSlice's position and size?

I guess it means that they would be handled by magic that only takes effect after the line has been fully attached, and that it would be perfectly compatible with a simple LineSlice that just draws a line from one corner to the other-- And it would be perfectly compatible with such a LineSlice no matter whether or not we decided that we wanted to support negative sizes for lineslices.

A LineSlice attachment feature would probably work nicely in the Slice Collection editor too, where the endpoint attachments are just special LineSlice details with their own magic editor. It could let you browse from a list of slices (with itself default-selected for quick access to parent or children) and it could let you mouse-point-click on slices to pick them too, and then it would have a second stage for picking the anchor corner of the target slice and a third stage for setting the offset.

The biggest complication I can see to this whole thing is that the LineSlice would need to know the final screen position and size of the other slices it is anchored to when it updates itself, and since it could be connected to distant cousins in another part of the slice tree, it might lag a tick behind the correct location unless some work is done to prevent that, which would include pre-computing unrelated slices, and checking to avoid recursive line-loops

More complicated than it is worth?... Maybe! I'm still thinking out loud here ;)

Ah, a fancier version of the ability to attach a slice to another that isn't its parent! Yes, these attach points are extra functionality that can be added afterwards. It does seem like something you'd want pretty often when drawing a line or curve.

Attaching and stretching between two slices would only be useful for line (and polyline, curve) slices, but single-slice attachment could be useful in general... I'm still not sure if we should expose it. I've been wondering for years. It seems to be pretty rare that I encounter a problem for which it would be the solution.

To avoid position lag I would calculate the position of all slices and draw them in separate passes. Put any slices that are attached to another slice that isn't their parent in a queue, to be updated after all the regular slices. It would be possible to ensure the attach slices are processed in the right order, by doing a simple depth-first search for other attach slices they depend on. Loops can be broken by tracking which have been processed already such as just putting a bit in the Slice UDT (but will lead to position lag or even positions that never settle down!). That seems pretty easy.

However it does seem like it would be a lot easier to just script this than to add it to the engine.
For example, the slices that are attached to would have to be specified using slice handles, not pointers. If you could set attachments in the slice editor then the editor would need to set handles and they would need to be rewritten when the collection is loaded in-game.

If occurs to me that polylines and curves are just the same thing with a different interpolation algorithm.