Slime Salad

TMC wrote:

The Wobbler wrote:Not sure if this has been asked for already, but could we have an option to set the speed of Walk In Place NPCs?

Yes, you have, and so have other people. Maybe someone should just add a global setting.
(A global setting is not a backcompat problem... however it will hopefully be obsolete within weeks)

I was just about to take the hint and implement this ;)

...but then I realized that a global option to customize walk animation speed is a different thing than a global option to customize just walk-in-place animation speed without affecting animation speed of other walk types.

While the former is pretty easy to do and doesn't cause any backcompat challenges, the latter is a bit more complicated, and might add challenges (though probably not serious ones)

Hmm, yes, it actually won't be as easy as I expected to implement that, and it'll be a waste of time. Should just wait for the animation system. Which I really want to resume... tomorrow?

Am I right in thinking padding is the same for all children (?)

Yes.
Radial layout would be much trickier; I don't know how to do that.
The packing layout I was planning to implement is something like this:
http://fd.fabiensanglard.net/quake2/ope ... esktop.m4v
(This is how dynamic lightmaps are packed onto a single texture in Quake 2 OpenGL.)

Optimal rectangle packing is *cool* but I can't imagine how it is a useful feature for slices. What sort of game would you need this feature for?

From what I read, the most common application for 2d rectangle packing is for texture packing and sprite atlas packing for video acceleration-- except, slices would be completely useless for that, it would have to happen at a lower level, like in the gfx backend.

(<s>and am I mistaken that SDL2+OpenGL acceleration already does it under-the-hood?</s> EDIT: Yes, I was mistaken, no it does not)

The impetus I had to implement Layout slices is for the graphics ThingBrowser, to replace the grid currently used. E.g. for picking an enemy sprite: they come in different sizes, so you want to pack them onto the screen rather than use the size of the largest sprite. This will become especially important when the sprite size limit is removed.

Unfortunately, it doesn't look that easy to replace the ThingBrowser grid slice, or I would implement it immediately to demonstrate.

More generally, packing of slices could be useful whenever you want to display a bunch of slices which are different sizes. Eg. a graphical inventory.

Ah, I can picture that inventory now. I know what you mean.

I can't remember the name of a game that uses that sort of inventory, but I know I have played a few. I remember manually shuffling items around to make them fit better.

As for layout slice and thing browser, hopefully it will be possible to use it for some browsers that it makes sense for (like Sprite browser after variable Sprite sizes are implemented) while leaving most other browsers grid slice based.

Resident Evil 4's inventory has the concept

FyreWulff wrote:Resident Evil 4's inventory has the concept

Yeah, I love their graphical inventory. I accounts for item weight in an instantly recognizable way. The inventory doesn't even have need for an explanation. It's instantly obvious what's going on.

regarding a radial layout. You could do it like 'points' of a 'star' (or polygon) perhaps?

Optimal rectangle packing is *cool* but I can't imagine how it is a useful feature for slices. What sort of game would you need this feature for?

It could take over some of the roles of 'grid' slices which displays contents statically.
You might consider it as 'dynamically arranging' contents.
It's useful when you don't know what the contents will be like, or when the contents vary a lot in size and/or number
(As opposed to grid slices, for example)

It might be useful to conserve space on screen. Although now we can change the window size, so it's not that big a deal.

Slices are meant to be able to compute the positions of their children efficiently, since they recompute them every frame. I think radial layout or anything else not likely to be needed for creating slice collections should be instead implemented as a script. That would work much better; then it doesn't matter how slow it is to position the slices.

I don't think a packing layout slice is useful for an inventory system where you manually manage space and placement, because it doesn't allow you to customise placement, aside from the order in which the slices are placed. I would really like to let you assign graphics to items, then you can have a graphical inventory. Grid and layout would both be reasonable ways to display them.

Aside: it would be nice to just have a set of simple options for how the inventory should be displayed, eg grid/layout and image/image+text/text without needing to know how to edit slice collections. But how can we have such options while also letting you customise the inventory slice collection directly? Maybe it's still possible for those options to work by manipulating the slice collection using lookup codes. Like, toggling the visibilty of the slice marked 'item name', if it exists.

Bob the Hamster wrote:As for layout slice and thing browser, hopefully it will be possible to use it for some browsers that it makes sense for (like Sprite browser after variable Sprite sizes are implemented) while leaving most other browsers grid slice based.

I doubt there's any good reason to use a grid in some and a layout in others. If all the children of a layout slice are same size, then it'll lay them out in a grid (you'll probably want to set it to justify, then it'll behave very much like a grid slice), without needing to manually calculate the rows/columns of the grid.

One nice option might be to make several standard layouts for the item screen, and let the user pick between them, or let them pick "manual" which would just be done with the slice editor using one of the standard layout collections as a starting point

As cool as the mouse features are, is there a way to toggle them being on or not in the editor? It would help me out a lot.

Why's that?

(There isn't)

I usually line up the cursor where I want it in the editor and switch to the code screen to look at the cursor for scripting purposes and I've done it that way for years. I also accidentally clicked a ton of stuff on accident that I thought were on before the yellow icons appeared when things were selected (which helped me not think I accidentally had stuff selected). It's just the map editing makes it so much more time consuming from how I am used to working. I'm not a fan of mouse based development since I do everything very slow and cautiously and like to hop from screen to screen. Is it a big deal to make the toggle functionality?

Code screen? Do you mean a script editor window?

Are you talking just about the map editor? There is actually an option in the Map Editor Settings to disable moving the cursor with the mouse - I knew some people wouldn't want that. It's called "Cursor follows mouse". You can still right click to move the cursor to the mouse position, and all mouse controls still work.

Ahhh, this must be new as I've never gone to this menu (or maybe it's been there and I never noticed it). I'd still like to disable it altogether, but this does get rid of my initial issue and I can deal with this better. Thanks.