Slime Salad

Pepsi Ranger wrote:Yes, built-in textboxes need many more conditionals, especially with tags. They need more than just two. Maybe tags can be added/subtracted via +/- keys? ...

Yes, that's the plan.

Over the years we've (mostly James) have already done heaps of cleanup of textboxes; as soon as we switch to a new file format (have you heard that before?) we can start adding new features. I would put textbox improvements high up the priority list, but suspect James will get to it before I do.

But, I suppose textboxes in general are in such dire need of an update that adding new conditions are just the tip of the iceberg. I'm actually trying to decide if I want to convert all of my 4000+ textboxes to slices

On the other hand I don't think it's too hard to customise textboxes with scripts. If you need longer textboxes, you could split them over multiple consecutive built-in textboxes by adding some special token like [MORE] to the end. Wendigo added the "textbox text" command recently which makes this easier. You can modify the slices easily... though you will generally encounter the same problem seen *everywhere*, which is changes by scripts being delayed by a tick. I really need to work on that.

I ran out like eight years ago.

Really sorry about that. I know that originally I stubbornly said that it would be a better idea to just increase the tileset size instead of the number of map layers, but increasing the tileset size is a big project (actually, now that we have a new graphics file format, it's much closer to happening), so it was a completely silly argument. It was rooted largely in perfectionism, but I've since started to learn to be pragmatic. Anyway, I did agree to implement it already long ago, it's just one of those thousand things I hadn't gotten around to (bad priorities).

Anyway, it's done. The limit is 16 layers now.

As for menu item colours, I made a start a few months ago. I think I mentioned before I got stuck because I wasn't sure what settings to actually add, and you made some recommendations. I settled on something... I can't quite remember what though! I do still want to finish it soon (but I've got a lot of other half-finished stuff to do "soon", so please bear with me).

Globals in battles... here's me being a perfectionist again: I should first figure out whether the ideas for generalised tags ... wait, no I shouldn't.

On that note, if we turned custom texts and fonts into slices, we could have a much easier word art system available, where words can "wave" on an invisible line curve, for example. Great idea!

I think this is called rendering text along a path, in other programs? Script it.

I'd really just like to see a development plan established so that new features and to-be-squashed bugs can have a projected timeline toward completion.

In other words, what are we implementing now? What will we implement or change next? What about after that?

You can see some of the things that I have half-finished here: https://bitbucket.org/rbv/ohrrpgce/branches/
But there's a bunch missing, and some of those branches have a lot of unrelated stuff, or undescribed changes.

Well, I have actually decided on the order in which I'll add some major features. (I'm not adding anything else to this list, because it'll all happen at my whim; I'll be working on heaps of smaller things in-between too.)

Soon (stuff that's already half-finished):
-fix gamepads
-file browser improvements
-backdrop colour-replace tool
-non-320x200 support in gfx_directx
-a bunch of other less-interesting things I have half finished, because there's way too many of them

After:
-animations and spritesets
-local state
-internal GUI stuff (maybe resulting in "menu" or "selectable" slice types)

Release after that:
-new script interpreter
-script fibres (multitasking)
-battlescripting

Release after that:
-textboxes/text markup, fonts

I've considered putting up a polling thread to ask what features or bugfixes people actually want, because honestly I mainly find this thread useful when multiple people request the same thing, so that I know it's actually worth adding. Or if someone needs a feature rather than wanting it.

Virtuous Sword wrote:Is there a way to pause battle already? In-game, this would be a nice option to have, as well for debug. if it doesn't exist already.

It could be bound to PAUSE key perhaps? Or a key combination? Dunno lo

PAUSE key? That would make too much sense. Whoever would expect that when you press this here completely forgotten PAUSE key, with but one sole purpose to its existence -- oh... it does already pause battle.
(No really, nobody expects the PAUSE key)

Advancing frame-by-frame to debug animations and interactions sounds like something that I will find quite useful as I work on animations.

TMC wrote:Anyway, it's done. The limit is 16 layers now.

This changes everything! Come to me, my lovely, lovely little tile animations! Come as well ground and wall tile variations! *insert maniacal cackling here*

Heh, seriously though, thanks for the additional layers, it'll allow me to do all sorts of additional cool stuff

It's good you summarized my post; it was too long.

The main hold-up for larger tilesets would actually be figuring out a better tile animation system.

Maybe it's time to split them out as special tile strips you draw tiles for and then place ?

It made sense before how they were implemented, nowadays they probably shouldn't have to live inside the tileset itself and have an arbitrary frame limit because of it. then you could also use that to draw arbitrarily placed animating tiles on the map with slices (forgive me if this mechanism exists in engine already, i've never worked with slices)

this way you could also make animation cues more sensible, like "animate to end then loop" or "oscillate animation" instead of "animate 1 over, 1 over, 1 over, back 3" since the tilestrip would be of arbitrary length.

16 layers rules, thanks!

Yay, now I can add in those extra layers when I go back to working on Powerstick Man XE eight years from now.

Just kidding. This makes my day seeing this addition. Thanks. Now I can go super design crazy.

It's funny how much I realize the engine still needs for improvement when you post things like "fix gamepads," "non-320x200 support in gfx_directx," etc. as your list of soon to-dos because I would have to agree that these are great things to finish ASAP as they are things essential for keeping the OHR relevant to other indie performers, yet I really want textbox improvements, which are also essential.

I'm sure I've said it before, but I'll say it again: I do not envy your position. There's a reason that TMC appreciation thread exists.

TMC wrote:On the other hand I don't think it's too hard to customise textboxes with scripts. If you need longer textboxes, you could split them over multiple consecutive built-in textboxes by adding some special token like [MORE] to the end. Wendigo added the "textbox text" command recently which makes this easier. You can modify the slices easily... though you will generally encounter the same problem seen *everywhere*, which is changes by scripts being delayed by a tick. I really need to work on that.

The [MORE] command sounds great for story needs. I'd have to check out the "textbox text" command in those cases. What I mainly want to do with textboxes is to allow for "storefront" type descriptions of items, where the box describes the essential attributes of the item being viewed and considered, complete with variables and strings attached to fit in a single box to show statistical information, even if that box takes up the whole screen. Or, create a "skinny" box that fills up one side of the screen, but can scroll through the text, or anything that lets me customize the look and length of the box beyond 40 characters and eight lines while still keeping all of the metadata and other attributes that textboxes have. Filling the screen with a single textbox would also be ideal for cases where I want to show a wide range of statistics on a single page, using the built-in string support that textboxes currently have, rather than constructing a text slice from scratch and having to update it via script each instance it's displayed. I could still do it that way, but textboxes natively do it easier. Cramming loads of statistics or important attributes devoted to a single item becomes a challenge when I've got eight lines to work with.

I should also note that the textbox customization will be vitally important when custom resolutions are permitted because I've finally settled on a preferred screen size for fitting all of the essential window slices for displaying information in real time during gameplay (referring to shop window displays in Entrepreneur, if that's not immediately obvious), and the current default textbox would look too small and isolated on the screen at that size (448x280).

But yeah, thanks for the extra layers!

>16 layers
>NPC pathfinding

Very excited, this is just what I needed.

guo wrote:>16 layers
>NPC pathfinding

Very excited, this is just what I needed.

Oh yeah, that does sound like exactly what Bale needs, doesn't it. That's exciting.

This is somewhat of an obscure request, but for graphics/sprite drawing, can we swap which side the canvas/palette appears on command?

The reason I am asking is because having the canvas to one side engages one eye (the one which is closer) more than the other (eye), leading to the corresponding hemisphere of the brain being activated more.

I know that seems a bit trite, but I often separate work as either being logical or creative, and try to engage the corresponding hemisphere appropriately (there are also exercise you can do, and using one hand rather than the other has a similar effect)

I doubt anyone really cares, but it does (marginally) affect me and the way I approach my process. I find my artistic processes stem from subconscious and primal activity, which has its own wonts and needs, and prefers things just so and without regard for reason.

If it makes any difference, I am sure that many people would like to have this feature for other reasons too, not least of all, some practical reason to do with the layout of their desktop, monitor, sitting position etc., and the ease of drawing brought about by having the palette closer to one eye rather than the other


On a tangent, having some kind of motion on one side or another effectively engages the brain, and helps bring attention to parts of the screen. I would like to see more (small!) animations in CUSTOM (not in such a way as to detract from the screen of course, just to give a visual indication that something is happening, working, etc.,) such as loading icons, or small graphics relevant to the menu or editor you are currently in.
Having a visual icon/animation instantly creates an association with that screen, rather than having text which needs to be deciphered.
In many ways, visual stimuli is much more immediate in being recognised and processed by the brain.
I think it'd be nifty if on screens where drawing is taking place, there could be a little icon of a pen, canvas, etc., working unobtrusively or something.
Maybe in the future? On another note, I cannot wait for extended animations, and potentially being able to preview animations from within the drawing facilities :p looking forward to it!

Text import needs to (or should) implement word wrapping on import, now that textboxes can internally accept it when writing in the editor. This will make creating templates for textboxes in various word processors easier.

could we have more than 100 string IDs please?

I often get the idea of saving strings as a history (log) that can be recalled by a player, but that would use a lot of strings.
I also don't like re-writing/saving over strings in case I need that string again later.

Maybe i am being finnicky but 100 really is not that much and I get put off using strings in case I run out.
What if I want to generate unique strings and keep them? I quickly run out of free strings!

Also, loading a script with an invalid string number doesn't give a warning, but the game will happily throw up an error. Should hamsterspeak(?) notify about this?

Store the strings as text slices. I agree though.

Newbie Newtype wrote:Store the strings as text slices. I agree though.

that... is a good idea... but would it not be more difficult to do operations on text slices compared to strings? And converting back and forth betwen slice and string?

request: can we increase the size of weapon graphics? By about 10 pixels?
I tend to use them in a hack-y way to display the attacker as well as the weapon.
For example, I would like to display the arm of the user holding the weapon so that weapon graphics appear to be used in unique ways depending on what kind of weapon it is, rather than having the same arm motion and only changing the weapon sprite.
(e.g. stab for knife, swing for sword, dragging for heavy weapons)
I also would like to use it to make characters appear to be doing special attacks and using different styles.
I can (just about) do this for unarmed fighters (arms appear to be striking in different ways. legs stay the same though) but weapons are difficult (unless I scale my hero sprites down to about 10-20 pixels)

As well as that, I use weapon graphics with "effects" on them (such as flaming sword, electric sword, etc.,) and combine them with attacks to create complicated graphics (such as making a heroes hand glow with the appropriate elemental power while doing magic tied to the attack using "weapon picture", or using disjointed hand position to make it appear to move around the screen, such as an elemental aura rising from the feet of a hero)

(I could post an example or proof-of-concept)

"Weapon sprites" have the potential to be quite versatile, and I would like to be able to use them for more than just that.
I actually want to see the much larger (50x50) but I'm scared of being told that's stupid.
Alternatively, could we perhaps use "any" sprite for weapon graphics?

I imagine this would be annoying to correct the menu in all the places a preview of a weapon sprite is shown.

On a tangent: could we have the ability to copy/paste/stitch together large sprites to make a "background" sprite? I do all (all) of my spriting in CUSTOM and this is the one sprite type that cannot be created (unless you use the tile editor, but it doesn't support copy/paste from sprites)
Or could we perhaps have the ability to draw on several tiles at once, for large multi-tile graphics, or the ability to move to a different tile from within the tile-editor (such as combination of Arrow Key + ???) and I feel this would work well with the current preview that shows surrounding tiles.
edit : does this already exist ?? ? *sweat*

Just a simple one: Can you add bitsets to enemies to make them immune to attacks that affect the status registers?

I haven't read the thread, so maybe it's been brought up, and I realize it's probably very very complicated but: Make in-game maps cooler than they are now.