Slime Salad

As for a suggestion:

Can we have tiles that are only displayed when tags are on/off, much like NPCs? "Write Map Block" is temporary, and a bit of a pain to have to load a script every time a map is entered or a battle ends.

I can see issues with my suggestion, however. Where is the tag conditional attached to the tile? Per tileset, or per map? What about passability? Bitset settings to keep old passability or assign a new one? Which layer?

Perhaps something similar to how NPCs are handled by maps - a "special tile" class with it's own bitsets & conditions.

You can actually already do something like this, using the animating maptile slot on one of your tilesets.

I used this in Wandering Hamster to make the banners and throne in Broaste's Castle change after you beat Broaste.



You have the starting tile of the animation be the default tile.

Then you have a tag check to make sure that the animation only happens when the tag is set.

Then you have the animation switch the tile to another tile, and make sure there are no "wait" steps on the original tile.

In the example in the screenshot, I used a wait 500 but I think this method should still work correctly without flickering even if you use a wait 1

Ingenious, thanks. That'll work perfectly

It would be very nice to have something more flexible than that, but I can't decide what.
When tileset animations get improved I guess we can try to make the existing trick more convenient.
But what's lacking is the ability to make local rather than global changes to a map, such as causing a new building to appear.

But for a start, we should allow hiding a map layer based on a tag condition.

I think the menu problem is something I've noticed - it's a recent bug, right?

Seems to be recent yes. I can fix it with a "max lines to display" for now.

Bob, your animation trick works, but not for passability. I like the idea of a layer that is disabled/enabled by tags.

I'm very crappy with slices, but is there a way to attach part of a tileset to an NPC the same way the ole' "embiggen NPC" script works using hero sprites?

Disabling map layers with a tag still wouldn't affect the wallmap.

No, you can't access tileset graphics with slices.

The easiest script-free solution to your problem might be to use some invisible NPCs in addition to the tileset animation.
You can also use a script that loops over every tile of the map and changes the walls for those tiles which have the tag-toggled animated tile on them (or based on a zone which marks which walls to change)

Please consider adding a visual indicator of the distribution of children of panel slices.

Sorely needed

When editing NPCs, is the ID number shown on the screen anywhere?
I would think something like that might be displayed near the sprite preview.

Apologies for the long post ahead of time. I've reached the point in my life where I'm starting to ramble on more and more like an old man npc, so excuse my longwindedness.

I'm re-emphasizing the request for expanded character equipment management, but am bringing some of my own thoughts on potential future implementations on how this could effectively be handled. Let's start with the current way the OHR handles character Equipment...

Weapon
Equipment Type 1
Equipment Type 2
Equipment Type 3
Equipment Type 4

As it stands right now we've effectively got 5 slots to play around with - but let's ignore that top one and set it aside for another day and instead concentrate on the four below it - the "armor" slots. By default the OHR calls these "Head, Body, Arms, Legs" but in truth we can rename these in whatever fashion we want them to be. This works for the vast majority of OHR titles too, and most people aren't going to deviate too far from this. As a comparison, this is essentially the equipment system that Final Fantasy 4 & 5 uses - most characters have a primary weapon hand, a secondary one which is usually a shield (or nothing!) a head slot, an armor slot, and a hand slot for things like rings and gauntlets. The game may deviate a little in the icons for each one of these slots but by and large the icons are there mostly to indicate what types of equipment each individual character can wear. Let's start off with an arbitrary example of Bob the Hamster wearing some armor:

Fancy Hat
Fuzzy Coat
Gloves
Boots


But say you wanted to add additional equipment slots? Say you wanted to include things like "Neck, Tail, Wings, Feet" in addition to the four provided slots? You COULD just lump in these with currently existing equipment slots just the same way that pendants, earrings, glasses, and hats could all thematically be lumped into a "Head" slot. But suppose you didn't want to arbitrarily lump different equipment types into a single category? My first recommendation is to allow the user the ability to arbitrarily add (or remove!) equipment slots. Say I want either eight equipment slots, or one, or even none at all, or any number in between! That should be something a developer should be able to specify when designing their game.

But even with expanding or diminishing the number of equipment slots a player is able to fool around with, there's still a few options left that I'd like to explore. As has been pointed out in the past, some people have expressed an interest in making games where the characters should be able to wear multiple items of perhaps the same type. Let's go with the example of Bob the Hamster wearing multiple magic hats at the same time. Right now you can't do that, and you'd probably have some in-universe explanation for having multiple magic items not working on the same slot, but whatever.

Let's begin by dismissing the current concept of equipment TYPES as ultimately arbitrary. We don't really care that Dragoon Armor and Genji Armor or whatever are "armor", but if they're listed as "Armor" then you can only have one of them on at a time. What we're going to do next is going to expand your horizons to places you haven't conceived of yet. So let's call the current individual equipment slots "Specific Selection" - only equipment sharing an what is essentially the same type can be worn in that slot only. You can only wear one armor. You can only wear one magic ring. You can only wear one hat. But I want Bob to wear 4 hats...

Fancy Hat
Fancy Hat
Weird Hat
Beer Hat

Let's deal with the multiple hats situation and call an equipment slot that lets you wear whatever you like in it "Nonspecific Selection". The user should be able to access this slot and then go through the available equipment list and choose which items in the game could potentially be worn in that slot. If I designate several slots as Nonspecific, then I can wear multiple hats! BUT WAIT you say, this could lead to a situation where you're wearing the same hat! What if you DON'T want to be able to wear the SAME hat?

So what you need are multiple options going on all at once, and they get complicated and confusing, but I'll spell them out -

An option that lets you wear only specific items - say, hats. This is essentially the default OHR equipment function right now.
An option that lets you wear whatever you specify AND allows you to wear duplicates - potentially everything can be worn in that slot.
An option that lets you wear whatever you specify BUT prevents you from wearing duplicates - you can't wear two of the same exact hat, but you can wear multiple hats.
An option that lets you wear whatever you specify AND prevents you from wearing the same TYPE in your other inventory slots - you can wear whatever you want but you can only have one hat at a time.

The next one is WEIRD and may only be useful in specific circumstances, but I'm including it for reasons -

An option that lets you wear whatever you specify AND allows you to wear duplicates in your other inventory slots AND prevents you from wearing duplicate select TYPEs - you can wear multiple of the exact same hats but you can only wear one coat at a time.

There's other combinations, but they get more and more confusing the deeper down the hamster hole we go, so I'll leave it here for now and see where this takes off.

I've been away from the scene for a while.

Has Battlescripting happened yet? I've got a few ideas for boss fights that need more than just Transmogrification to work well (for example, a Shieldmage who merges every enemy in the formation's HP into a grand pool that you have to wear through, at which time they all die at once, but they still get their individual attacks)

Battlescripting has no been broken yet. I believe it is still in the development stage.

Request:
Could we please have, for rectangular slices, being able to have translucency(fuzziness) varying across the slice as a gradient?

This could be used to simulate graphical effects on-screen to create the illusion of depth, such as shadows.

It could also allow rectangular slices to be layered for complex gradients

Could panel slices also be given some option to blend both of their children together, using a similar thing (fuzzy translucency)


Also, how about a way of re-ordering child slices quickly, like "reverse order of siblings" or being able to rank child slices based on some information (such as date/time, number of children, number of descendants, used in script, slice type, lookup code, size/area, position, etc.,

(Actually, this ties into my request for being able to flag data in other places in the engine)


EDIT:

I notice in the ploscript dict, there is the entry for "put slice screen" and the following commands where it comments that the script will not work when the slice is filling its parent. Can we have this fixed to automatically undo "fill parent" if the command(s) is/are used.
Or is this already included but no updated in the dictionary?


EDIT:
For sprite drawing, how about horizontal/vertical rotation with CTRL+Left/Right, and Vertical flipping with CTRL + Up/Down?

Fenrir-Lunaris wrote:Let's deal with the multiple hats situation and call an equipment slot that lets you wear whatever you like in it "Nonspecific Selection". The user should be able to access this slot and then go through the available equipment list and choose which items in the game could potentially be worn in that slot.

Yes, we need a flexible equipment system.
It's interesting that your suggestion is to allow attaching complicated options to the equip slots about what can be put in them. My suggestion for equipment was instead to leave the slots alone (other than letting you set how many there are) and put the complicated rules for where items can be equipped on the items themselves.
Putting the complexity in the slots could be simpler overall.

Firstly, I think we definitely need to be able to mark equipment as equippable in multiple slots. I was actually just about to implement that. Well, at least I thought "definitely" until I read your post, which could be taken as a counter-proposal to doing so.

I don't know what your use-cases are, but I'd really like to know whether it's totally covered by my suggestion, which goes further:

Let each item be equippable in zero or more ways (I'll call them equiptypes because naming stuff is hard).
Each equiptype specifies which slots it can be equipped in, which heroes can equip it, what the stat gains and elemental resists are, for weapons what attacks and graphics to use, and which tags to set, and can also have tag conditions for being applicable.
This means multiple equiptypes could be applicable to a single hero + slot; if so, the first is used.

Multiple equiptypes on an item allows things like:
-can change what equipment does with tags (and auto unequip if no longer allowed, I suppose)
-change equip effects based on where it's equipped
-can allow different heroes to get different stat gains, eg heavy weapons being more effective for stronger heroes
-many other things, such as allowing different heroes to hold or use weapons differently (change attacks or graphics)

The problems with this approach are:
-maybe it's too complicated? I don't see how it could simpler but still cover usecases. However, maybe there could be simpler alternatives to it, such as putting options on the equip slots.
-we can't show info from multiple equiptypes in shops, not without adding menus
-it's going to be a bit of a nuisance to access this data with script commands

Also, (this is a totally separate feature but would also be a per-equiptype option): when equipped, disable equip slot X. I have a feeling this is where you were going. For example, wielding a sword in two hands, the off-hand slot is disabled. You could have a second equiptype for the sword which uses just one hand, but with lower damage, but I don't know how the Equip menu would actually handle that. Maybe if multiple equiptypes apply to the selected slot, you could be asked which to use? I guess you would need to provide a description like "Two-handed" for each equiptype.


But after you and someone else (Surlaw I think?) talked about it, I think that it would be good to also be able to have multiple copies of the same equip slot. For example you could have 4 'ring' slots. Although you could just have four different slots with the same name and always allow rings to be equipped in all four slots, having an explicit copy count has benefits:
-there could be the "don't allow duplicates" option you want on the equip slot. Although, we could just add a per-item or global option to disallow duplicates, rather than a per-slot option.
-you don't have to manually ensure all equip is equippable in all copies of a slot
-you can easily change the number of copies of a slot later
-we could add an option to say how many copies of each equip slot each hero has. So an octopus hero gets zero Armor slots but lots of Hand slots.
(I haven't thought about hw multiple weapon slots would work, but that would probably be nice too)

Virtuous Sword wrote:I notice in the ploscript dict, there is the entry for "put slice screen" and the following commands where it comments that the script will not work when the slice is filling its parent. Can we have this fixed to automatically undo "fill parent" if the command(s) is/are used.

"fill parent" breaks a bunch of stuff like that. I would love to break back-compatibility and change the way it works.

Yes I'd like to add gradients and textured backgrounds to boxes, because lots of RPGs have them. Translucency gradients are a neat idea too.

Your request about reordering arbitrarily: use a script to set a sort order on each slice and then use the sortchildren command.

The tile editor already has keys for rotating and flipping, but for some reason the sprite editor doesn't use the same keys, and is missing vertical flip. Not sure which keys to use. I'd rather reserve ctrl+arrows for panning the sprite, once we can zoom in.

Please consider adding a visual indicator of the distribution of children of panel slices.

Realised it would only take 3 min, so I added this.

Yeah, more complex stuff regarding equipment allowances would be great. Would more plotscript commands pertaining to items/equipment [being able to check/set various stuff regarding allowable equipment or who can equip certain items, for instance] be coming along with this?

(I edited the post above slightly, most significantly to mention per-hero slot copy counts, eg for number of limbs)

Yes, I've been arguing for years not to add any item script commands until after we've implemented a new equip system, to avoid back-compat headaches.
I've likewise argued against changing to the new items file format James planned because it didn't change the equipment system at all except to allow multiple slots per item. (James never commented on most of my suggestions.) Though actually that was a bad excuse, because RELOAD is flexible enough to allow switching to multiple equiptypes later with little pain. Always dragging my heels!