[Ohrrpgce] SVN: james/12833 Slice based battle UI is now enabled by default.

James Paige Bob at hamsterrepublic.com
Fri Feb 25 19:28:45 PST 2022


On Fri, Feb 25, 2022 at 9:10 PM Ralph Versteegen <teeemcee at gmail.com> wrote:

> Awesome.
> I do want to make the slice editor more friendly -- it's for editing
> graphical things, it ought to be really intuitive! Very recently I started
> adding mouse support for moving and sizing slices.
>
> Yes, let's not make it editable until it's stable.
>

Yes, I'll be saving that step for later, when we are happy with how it
works. I have some plans for how to make it friendly. We can also have
multiple build-in UI elements, not just the default ones. For example, I'm
imagining that you could pick from several different  hp area styles, or
several different targetting cursor styles, and then use your favorite as a
starting point to customize in the slice editor. I also have some ideas for
completely new optional ui elements, like enemy hp meters

>
>
> I think we should add a "menu item" UI colour for text slices which, when
> it appears in a menu item, appears as the appropriate colour (selected,
> disabled, etc). This is the reason for SliceContext being named that way: I
> intended that menu item (plank) slices for example would tell how to do
> contextual expansion of UI colours, embed codes, and more.
>

I didn't remember about SliceContexts :D I'm fuzzy on how this will work,
but it sounds like a great idea


> I'm a bit surprised that you create the slices with code, which is going
> to be thrown away later, rather than loading a .slices collection, but
> maybe it's easier to reference against the existing code this way.
>

Yes, it was easier for me to convert the old static battle ui code in this
way. I do want these to be slice files later though.
I also could not remember if the slices in the data subdirectory gets
distributed with game or not. I know it is included with custom, but I
couldn't remember about game



> I hadn't thought of putting the targeting cursor in the same collection.
> What about enemy HP meters, and other slice "decorations" users might want
> on enemies? I guess we could put a template slice in the collection that's
> cloned for each enemy (and also one for heroes) so that they can customise
> it there, rather than needing separate collections for that. I was thinking
> of eventually allowing an enemy's slices to be editable from the enemy
> editor, for multipart enemies, but I suppose any slices shared between all
> enemies, such as HP meter slices, wouldn't appear there. (Unless, say, you
> wanted only bosses to have HP meters, then you could put the HP meter
> slices in the slice collections for those specific enemies.)
>

Yes, so the targetting slice area will be a template slice which will get
cloned for each target being currently selected. It will auto position and
size itself to match the target's size. The classic default collection will
just have the cursor as a child slice, but other styles might include an
enemy HP bar, or a status icon area

It will also be possible to include this same kind of template slice that
positions an instance of itself over all enemies or heroes at all times, if
that would suit the game's style better than only showing enemy hp at
targetting time.
Also, there really won't just be one ui collection, there will be a bunch
of them, with multiple default options to choose from for each, in addition
to the "classic" default.



>
> Regarding the status icons, I see two options. Either the slices for each
> icon are created by code, parented to a certain container in a certain
> order, as you have it, or the icon slices preexist in the collection and
> their visibility just gets toggled, which allows far more flexibility for
> how they're displayed, but on the other hand doesn't allow adding arbitrary
> icons unless it's by fallback creation of new slices. I think there was
> also a plan was to let people define their own statuses in future, with
> custom icons? Well, it could just be necessary for them to add them to the
> slice collection.
>

Yes, wondering how I should do that is actually what launched me into
working on the ui slicification in the first place :D
I haven't settled in my mind yet how I want to allow custom statuses, but I
am definitely thinking of it.


>
> For example, what if you want the icons to appear above the hero sprite
> rather than next to their HP meter? Oh... so that's why you allow multiple
> "hero info areas"?
>

Yes, that might even be possible quite soon. I do also want to make use of
LayoutSlice for the slice icon area, which will make it easier to do
multiple rows in a generic way as an alternative to the current linear
grid-based method, but I see that layouSlices are not enabled in the slice
collection editor just yet.


> I see you go to some trouble to avoid overwriting scripted changes to the
> icon slices if they already exist, but they still get deleted when the
> status disappears, rather than hidden. (Layout slices can skip invisible
> children, while grid slices can only skip template slices. Incidentally,
> status icons were a main usecase I was thinking of when I created layout
> slices, but I see you're waiting on them being user-visible.)
>

Yep, I wrote the previous reply before reading the whole paragraph. I think
that is a bad habit of mine :D

Although all that being said, I don't see a problem with deleting the
status icon when the status ceases. That seems logical to me.


>
>
>
>
> On Thu, 24 Feb 2022 at 17:28, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> The natural future step will be to work on enabling customization using
>> the slice collection editor.
>>
>> The slice collection editor is honestly pretty advanced, and not all
>> users will be comfortable, so I hope to make it nice and easy to
>> export/import a customized battle ui slice collection so they can be shared
>> with others. Perhaps we can even include a few different ui layouts in the
>> import folder.
>>
>> Also there will be other possible ui features to add. Maybe portraits in
>> battle? meters for other stats? I dunno. There are lots of possibilities,
>> but not everything has to happen at once.
>>
>> I also plan to convert the targeting cursor and the message window using
>> a similar structure. I guess I really need to get all those other default
>> UI elements converted to slices FIRST before I enable editing of custom
>> battle ui, because I don't want a situation where people are customizing
>> the part of the UI that is sliceified, but then the old unsliceified UI
>> elements vanish when I convert them because they don't have those in their
>> custom layouts
>>
>> One step at a time :)
>>
>> ---
>> James
>>
>>
>> On Wed, Feb 23, 2022 at 11:18 PM <subversion at hamsterrepublic.com> wrote:
>>
>>> james
>>> 2022-02-23 20:18:46 -0800 (Wed, 23 Feb 2022)
>>> 157
>>> Slice based battle UI is now enabled by default.
>>>
>>> The old code isn't removed yet, and you can still (temporarily)
>>> compare old and new ui with Shift/Ctrl + F9
>>> ---
>>> U   wip/bmod.rbas
>>> U   wip/whatsnew.txt
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20220225/917cca96/attachment-0001.html>


More information about the Ohrrpgce mailing list