Customise HP/Heart, MP/Block, and make MAGICDRAINRATE a float.

[ZoriaRPG]

Like it says on the tin.

[Tamamo]

ZoriaRPG
Meh, How about we just create custom container pieces and be done with it.
You'll have to explain the latter. But most likely the internal engine is such a clusterfuck it would be better to just rewrite the counters altogether anyways once we implement Angelscript in a year or two.

[ZoriaRPG]

ZoriaRPG
Meh, How about we just create custom container pieces and be done with it.
You'll have to explain the latter. But most likely the internal engine is such a clusterfuck it would be better to just rewrite the counters altogether anyways once we implement Angelscript in a year or two.

How would container pieces be meaningful?

The point, is that if a user wants hearts, displayed on the screen, measured in 1HP each, or 100HP each; and likewise with magic (again, displayed on the screen), measuredin custom amounts per 'block', that it should work. In fact, the reason that magic blocks are measured in 32s, not 16s, is because the default magic cost is in 2s, not 1s. That's affected by Game->Generic[GEN_MAGICDRAINRATE].

MAGICDRAINRATE is the 'half magic' thing. Magic costs are divided by this, to determine final costs for item editor magic rates. As it's a truncated value, it is only possible to reduce magic costs, not increase them; which is how 'half magic' works: It sets the rate of this index in Game->Generic[] to '2', thus dividing costs by '2' before applying them. If we stop truncating it, the the user could set values in this array to 0.5, which would allow them to double, or quadruple the cost of MP-based items by setting Game->Generic[GEN_MAGICDRAINRATE] = 0.5. (So, cost = cost / 0.5).

The reason that it is truncated now, is because decimal values for most of the other components of the array make no sense... but this one index does.

Giving the user the ability to assign the value of a heart, or a magic block, shouldn't break anything. Likewise, removing truncation on that array, shouldn't either, unless the user sets values illegally. Technically this could allow HCs to grant two hearts, by user option, as well, and would allow setting the number of HP at continue more precisely. (CONTINUEHEARTS is in x * 16, so setting it to 10.25 would allow 164 HP as a starting amount.)

If the user could change the value of hearts, then CONTINUEHEARTS would likewise be more valuable if it accepts a decimal value. All of this is pretty much linked together, which is why I posted it together. :)

Has nothing to do with counters.

[Tamamo]

Container Pieces would allow people to create scripted meters without having to resort to drawing which currently doesn't update when the subscreen is active. For example having 3 meters one for Health, Magic, and another for shield durability similar to Skyward Sword.

Not to mention you could make them what ever value you wanted and use the same concept to replace the built in Life and Magic Container Pieces.

[ZoriaRPG]

Oh, you mean counter blocks, not container pieces, as in HCP or MPC items. Sure, that'd be possible, but if we just allow setting points per block (piece) as a variable, then why would we need to grant a separate interface to them?

I wouldn't mind adding the other script types that were intended for 2.5... Screen scripts, which I presume were meant to be subscreens, are defined, but they were never completed, or even begun.

[Tamamo]

Oh, you mean counter blocks, not container pieces, as in HCP or MPC items. Sure, that'd be possible, but if we just allow setting points per block (piece) as a variable, then why would we need to grant a separate interface to them?

I wouldn't mind adding the other script types that were intended for 2.5... Screen scripts, which I presume were meant to be subscreens, are defined, but they were never completed, or even begun.

Error: A counter block is what nes style subscreens use to show keys rupees and bombs + Super Bombs if enabled.
A new interface for all of ZQuests gui will be implemented inventually so we can eventually discard Allegro. (The GUI is one of the big reasons it cannot be easily done)

[ZoriaRPG]

Error: A counter block is what nes style subscreens use to show keys rupees and bombs + Super Bombs if enabled.
A new interface for all of ZQuests gui will be implemented inventually so we can eventually discard Allegro. (The GUI is one of the big reasons it cannot be easily done)



Right, 'Gauge Piece'. Still not a 'Container Piece', which was where I was confused by your initial reply... So, we were both wrong, and I still think you are missing the point.

At present, the value of hearts, displayed in these gauges, is in increments of 16. Likewise, magic is in increments of 32. Those are fixed values, not something that the user can edit. There's no requirement to change how subscreens work, to allow the user to define these. We'd just change all code references to read one ZASM register, that defaults to 16, for HP, and another register that defaults to 32, for MP: Then, allow the user to change these values.

This would grant a user the direct ability to change how much HP a single block of health or magic is worth, without any editing of subscreen object properties.Likewise, for the ZQ interface, the base values can be located in the Init Data->Misc tab, so that a user could change them, without scripting them. Allegro limitations do not apply.

This most matters for games that need a finer display, for these bars, such as a 'Castlevania' style health system, or a Z2 style health system, where the bar has a tiny red line for every 2HP. It doesn;t mean anything to me personally though. I usually script status bar displays directly via draw instructions. [/sick]

I also suspect that you are the only one who's thinking of making a new interface from scratch. Saffith wanted to migrate to ag5. Gleeok pretty much didn't care, last I knew.

I'd just assume fix what's broken in Allegro, as writing, and migrating the ZC basecode to a new interface is a 5-year mission for a full crew. Plus, time for fixing every compatibility bug/issue in every quest in the galaxy; and ensuring that it still runs on ancient hardware, all the way back to flipping Vista and Windows ME, or ...98 for ix86. What is our minimum OS requirement again? [/afraid]

[Tamamo]

MS Dos

[ZoriaRPG]

MS Dos


Really?! I thought that PC-DOS support ended with 2.10.

[Tamamo]

Really?! I thought that PC-DOS support ended with 2.10.

DOS support ended in 2000 actually. We're using VR now. I was being sarcastic

[ZoriaRPG]

DOS support ended in 2000 actually. We're using VR now. I was being sarcastic


Thank goodness. I know of no way to support all the libraries in DOS. I also don't want to extend support further back than is reasonable. I feel 'XP or newer' would be fitting, but technically we can still support ME or newer.

[Tamamo]

Wait people still use Windows ME?

[ZoriaRPG]

Wait people still use Windows ME?


Dear me, I sure hope they don't. It was an awful bag of sick. I'm not sure if supporting it is really any different to supporting XP though. Then again, I barely remember anything about ME: I used Win 2000 Enterprise when all that rubbish was rolling off the line.

Pretty much w2K, XP, and Win7 are the only decent MS OSes since Dos 5 + Windows 3--and I was big into OS/2 at that time.

I should note, that I was very impressed by the authorof Shovel Knight. Making a version in 80386 assembly, that runs on a 386SX-16 (maybe -25) in DOS is rather incredible.