100 replies to this topic

[Linkus]

Let's talk gauges. Life and magic are one of the hardest things to set up on a subscreen due to the mess that is the interface for them, and it's only made worse when you want something larger than the standard 8x8 life bar or magic gauge, or something vertical.

 

So what to do about it? Let's reinvent it for the next RC!

 

My biggest suggestion is that we get rid of all the magic and hearts being several separate things on the element list and merge them into one flexible element simply called Gauge. From here what the gauge represents is up to the user - It can track health, magic, a number of an item, or a scripted value. The user can also choose how this is visualized - A bar with or without caps and container (basically a 16x16 bar/container midsection stretched out to the defined max length minus cap lengths), a set of repeating tiles with framesets that change on that value (along with adjustable overlaps), and the option to permanently fix the bar or tile repeat length and have a number use the  "current/max" layout with the bar or tiles updating as appropriate when increasing or decreasing the current or max value. This also includes max horizontal size, a toggleable "show active" section as a way to make where the current status of a bar is more visible with a special tile or set of tiles, and a preview mode in the interface itself as it can problematic to work with so many options and numbers and not know what it may look like when you hit OK on the Properties interface.

 

In other words, the current gauge systems should be retired and only managed for compatibility, and a better and more comprehensive gauge system is really needed.

[strike]

How about not bringing in new things to a basically stable version of Zelda Classic to screw it over? This is way past the time for such things. I would like extra things too, I think everyone would, but it's respecting the developers.

-Strike

Edited by strike, 03 September 2014 - 03:16 PM.

[Saffith]

Yeah, making any significant changes to the subscreen is going to be a huge undertaking. And the whole dialog system should be redone first, because the subscreen dialogs are the most unmanageable of all by far, and that's really saying something.

[Linkus]

would a puedoscript designed to outline the gauge mechanics help in any form?

[kurt91]

How difficult is it to add a scripting feature? This isn't a request, but last night I was wondering how difficult it would be to add in something like

 

Screen->PlayMusic(TrackNumber, StartPoint)

 

so that we had more that we could do with things like MIDI files.

[DragonDePlatino]

I completely agree with Linkus. Of all the things I had to go through with designing tilesets, setting up heart gauges is the most painstaking.To do something as simple as changing the palette of all the individual hearts I'd have to manually go through the 32 heart pieces, click "Not Last", "Last", "Cap" and "After Cap", and change the palettes of each one.

 

Doing all this is 7 clicks a heart container, so to change the palettes of all 32 heart containers that's 224 clicks. And with 4 passive subscreens with 32 heart containers each...that's 896 clicks. And oops! I set them all to the wrong palette so I have to redo those 896 clicks. It's an incredibly boring process I usually reserve for when I have something interesting to watch. Oh, and that's not even getting into magic gauges. :I

Edited by DragonDePlatino, 03 September 2014 - 05:58 PM.

[Saffith]

would a puedoscript designed to outline the gauge mechanics help in any form?

Not at the moment. We have to get the backend sorted out before anything else.
 

How difficult is it to add a scripting feature? This isn't a request, but last night I was wondering how difficult it would be to add in something like
 
Screen->PlayMusic(TrackNumber, StartPoint)
 
so that we had more that we could do with things like MIDI files.

It varies. Exposing something to ZScript isn't hard, but the implementation can be. That one specifically should be pretty simple.
But it would break compatibility with 2.50.0, which we're trying to avoid here.
 

Doing all this is 7 clicks a heart container, so to change the palettes of all 32 heart containers that's 224 clicks. And with 4 passive subscreens with 32 heart containers each...that's 896 clicks. And oops! I set them all to the wrong palette so I have to redo those 896 clicks. It's an incredibly boring process I usually reserve for when I have something interesting to watch. Oh, and that's not even getting into magic gauges. :I

You can set one up and duplicate it, you know. Still takes a while, but there's no reason to do them all from scratch.

[DragonDePlatino]

You can set one up and duplicate it, you know. Still takes a while, but there's no reason to do them all from scratch.

Yes, but if I start with one life gauge piece and duplicate it to create my 32 pieces, I still have to go back through and manually align each one. Tileset designers don't have to do this for the individual letters of a text object or the individual pieces of the triforce, so why is it necessary for life gauge pieces? Linkus' idea of a "Gauge" object is much more streamlined.

Edited by DragonDePlatino, 03 September 2014 - 06:24 PM.

[Saffith]

There's only so much I can realistically do, but I can probably at least make it so that if you select multiple gauge pieces and edit properties, the changes (besides position and heart container number) are applied to all of them. That shouldn't be hard to add in.

[DragonDePlatino]

OK...being realistic here, that sounds like it'd be the next best thing. And I'm guessing you will accomplish this by allowing editing the properties of multiple shift-clicked objects? That would be very convenient!

 

Either that, or the ability to right click something and have "Copy Properties" in the context menu. And then if you right-clicked another object of the same type, there would be "Paste Properties" in the context menu. Kind of like how Microsoft Word allows you to copy and paste the formatting of text without changing the text itself.

Edited by DragonDePlatino, 03 September 2014 - 10:20 PM.

[kurt91]

That one specifically should be pretty simple. But it would break compatibility with 2.50.0, which we're trying to avoid here.

A handful of scripts that I've seen are set up to ignore a specific portion if the corresponding argument is left blank or an incompatible number. When you add something like that, can't you do something similar where if there is nothing used as "StartPoint", or if it's an incompatible number, it's considered to be set to zero, leaving all prior versions still compatible since music can currently only be started at the beginning?

 

Also, regarding the gauge issues, would it be possible to have some sort of auto-setup feature, like how some programs have a setup Wizard? You put in the number of desired components and answer the questions as they're asked in layman's terms, and then it plops down the corresponding results onto the subscreen. You could then move each component around the subscreen just like you can currently, since it's just helping set up the parts instead of making a whole new type of object. It could even have like a simple gauge mode, if you're making ones like the default HP/Magic gauges, or a complex one if you need unique graphics per part, like if I wanted a gauge with a twist in it like in Kingdom Hearts.

 

If that's too ambitious an addition to a later 2.51 version, maybe for 3.0 since you guys said that you plan on rewriting most of it anyways?

Edited by kurt91, 03 September 2014 - 10:08 PM.

[Saffith]

Either that, or the ability to right click something and have "Copy Properties" in the context menu. And then if you right-clicked another object of the same type, there would be "Paste Properties" in the context menu.

They pretty much work the same way, so I did both.
 

When you add something like that, can't you do something similar where if there is nothing used as "StartPoint", or if it's an incompatible number, it's considered to be set to zero, leaving all prior versions still compatible since music can currently only be started at the beginning?

No. Ignoring an argument is different than not being aware of it. An unexpected argument wouldn't get popped off the stack, and that could cause major problems.
 

Also, regarding the gauge issues, would it be possible to have some sort of auto-setup feature, like how some programs have a setup Wizard?

Possibly. I'll see what I can do.




Any more word on performance issues? Any consistent causes besides traps spawning? Was build 1677 better?

[Frocks7Snee]

So... Are the downloads for this still wonky? Chrome says its evil and wont let me download it >_>

[Ben]

Is it possible to make dialogs be movable in large mode? Sometimes they obscure just that one enemy ID or warp coordinate that you couldn't remember for some reason.

[Saffith]

So... Are the downloads for this still wonky? Chrome says its evil and wont let me download it >_>

Can't you override it? There's nothing wrong with it, Chrome's just being stupid.

Is it possible to make dialogs be movable in large mode? Sometimes they obscure just that one enemy ID or warp coordinate that you couldn't remember for some reason.

That isn't really feasible with the current dialog system. A window isn't aware of its contents at all; it would have to be implemented separately for every dialog.