Zelda Classic 2.53.0 ( Beta 10 )

Quote:

---

Originally Posted by DarkDragon

Thanks guys for working together on sorting this stuff out. I haven't been keeping up at all with the changes to these files.

ZoriaRPG, please don't forget to send patches for master as well as 2.50.x (also for the door fix you submitted a few days ago). Otherwise the next version of ZC will have delightful regression bugs...

---

I haven't forgotten. I just have not had the time. This was a bad week, with servers down, and to put the cherry on top, I had to have minor surgery. I will forward-port the revisions.

Please, please, fix the AGN connection issue though. I can send you a PM with the IP address that needs to be unblocked, if needed. You have not been on Skype lately, and have not seen (or at least, responded to), my messages, there.

Needing to rest equipment across the board, is very time consuming. I would otherwise be checking AGN 10+ times per day.

It's unfortunately not something I can fix. My advice remains to send War Lord the full text of the error message you are getting, so that he can raise the issue with his host.

Quote:

---

Please let me know if you see anything new.

---

One thing - some of the constants for blank characters have mismatched names and values. CHAR_BLANK142, CHAR_BLANK144, CHAR_BLANK145, and CHAR_BLANK158 should each be named one less.

Quote:

---

Am I missing something, or is this field truly unused, and set to 48 for no good reason?

---

It is used. It's passed to the base class constructor to initialize clk, which in turn is used to initialize clk2. What it ultimately controls is how long it takes for each head past the first to start moving. Why that's something you'd want to change, I have no idea.

Quote:

---

Would you prefer both instances per character? That's what I did, for now, as it was trivial.

---

That works, sure.

Quote:

---

It would be far simpler if everything used Extended ASCII, which was a single standard.

---

The thing is, it's not. "Extended ASCII" refers to any standard that fills in 128-255, but ANSI never extended ASCII beyond 7 bits. A lot of confusion seems to stem from the fact that Windows called its encodings "ANSI code pages." That was because they were supersets of ASCII, but a lot of people took it to mean that the encodings themselves were ANSI standards.

Quote:

---

Originally Posted by Saffith

One thing - some of the constants for blank characters have mismatched names and values. CHAR_BLANK142, CHAR_BLANK144, CHAR_BLANK145, and CHAR_BLANK158 should each be named one less.

---

Fixed. I forgot to change the identifiers, when I offset their values.

Quote:

---

It is used. It's passed to the base class constructor to initialize clk, which in turn is used to initialize clk2. What it ultimately controls is how long it takes for each head past the first to start moving. Why that's something you'd want to change, I have no idea.

---

Hmm... If I was going to choose a gleeok value to expose, it would be the shot timer (for 'breath' weapons, this would be useful), not the head movement timer. How utterly random. I'll make a note of it in the next update. I'm not even sure how to name that constant.

NPCA_GLEEOK_HEAD_CLOCK ? I hate identifiers that can;t explain enough about what they represent, and require a paragraph of comments to clarify what they do. :/

Quote:

---

That works, sure.

The thing is, it's not. "Extended ASCII" refers to any standard that fills in 128-255, but ANSI never extended ASCII beyond 7 bits. A lot of confusion seems to stem from the fact that Windows called its encodings "ANSI code pages." That was because they were supersets of ASCII, but a lot of people took it to mean that the encodings themselves were ANSI standards.

---

I was referencing IBM's Code Page 437, which is usually regarded (once upon a time) as 'upper-ASCII' (not upper-ANSI, although these days, both are seemingly tossed about interchangeably), and I was bleating that it would have been nice if one of these was standardised. There were other things around at the time on every platform, such as Apple's MouseText, and most home PCs had upper chars that were graphical in nature. The MSX and the C64 both immediately spring to mind, in this regard.

I should prefix the present set with CP1252_* though, instead of CHAR_*, as that would [help to] prevent platform-based confusion.

Here is a re-up of the ZIP, with the amended files:

http://timelord.insomnia247.nl/zc/zc...ixwaterjig.zip

I would also like an opinion on something...

Which do you prefer of these two functions:

Code:

---

//Functions to converty angular behaviour to directional, based on the angle.
//Call when setting bool Angular for an object, as Angular = DoAngular(ptr)
//This ensures that the lack of decimal precision in conversion to Allegro radians
//does not prevent setting certain angles; causing 'drift'.
bool Angular(npc n, int deg){
        if ( deg % 45 != 0 ) { n->Angle = deg; return true; }
        else {
                //u,d,l,r,lu,ru,ld,rd
                int dgs[8]={ 270, 90, 180, 0, 225, 315, 135, 45 };
                for ( int q = 0; q < 8; q++ ) {
                        if ( deg == gds[q] ){
                                n->Dir = q;
                                return false;
                        }
                }
        }
}

---

...OR...

Code:

---

//Variation on Angular() that has a void type. Use when declaring a pointer, to st the angle and direction.
void SetAngular(npc n, int deg){
        if ( deg % 45 != 0 ) { n->Angle = deg; n->Angular = true; }
        else {
                //u,d,l,r,lu,ru,ld,rd
                int dgs[8]={ 270, 90, 180, 0, 225, 315, 135, 45 };
                for ( int q = 0; q < 8; q++ ) {
                        if ( deg == gds[q] ){
                                n->Dir = q;
                                n->Angular = false;
                        }
                }
        }
}

---

These are part of the std.zh 2/0 spec, and I'm not sure which users would prefer.

I prefer the boolean return to bool Angular, as you can do this (in 2.60):

Code:

---

if ( n->Angular = Angular(n, degrees) ) { //Note, this is not quality, it is *assign*; assign in a statement is now legal
  ///Adjust attached npc segments for angular movement;
}
else { adjust attach npc segments for directional movement; }

---

This to me, is better than separately setting, then checking it.

I have both in there at present. If you want to see the WIP files, thy are here: std.zh v2.0--alpha, for ZC 2.60


P.S. @War Lord , or whoever is responsible: I can again access the forum without workarounds. Thank you.

Quote:

---

Originally Posted by ZoriaRPG

Which do you prefer of these two functions:.

---

Neither. :P

Besides being in desperate need of optimizing, I don't see the clear purpose of the functions..? But I'm also tired and on my way to bed, so there's that. :spin:

Quote:

---

Originally Posted by Gleeok

Neither. :P

Besides being in desperate need of optimizing, I don't see the clear purpose of the functions..? But I'm also tired and on my way to bed, so there's that. :spin:

---

Code:

---

// This ensures that the lack of decimal precision in conversion to Allegro radians
// does not prevent setting certain angles; causing 'drift'.

---

I hear my share of complaints about this.

Setting a moving object to an increment of 45 degrees, other than 0, sets it to a radian value that is only an approximate for that angle. e.g., Setting an angular object to move straight up and down. It may be off by a small amount, and potentially drift; compared to setting Angular false and DIR_UP/DIR_DOWN. That is what these functions automate. It's the only viable way to fix the lack of decimal precision, as it allows a moving object to shift from using Angular to Directional movement, only when its angle (which may be a changing value, and should be passed in degrees), is one of the 8-way directions.

Obviously, this is useful only to cases where that precision is needed, or beneficial, but it gives an easier way to handle it than making if/else statements in a script.

I could turn the for loop into a switch block, but I do not think that would be any more optimised at an ASM level, although it would use fewer registers. I'll probably do that, or make it an if chain. I also need to add cases for 360 and amounts over 359 in general, and less than 0 (embedded wrapping).

x, y movement components of eweapons and npcs in ZC needs to fixed from within I think, rather than script hacks that mask errors for special cases. Of course I'm assuming there is an actual underlying bug here. As you know I have a few npc bugs on the top of my todo for 2.5x. If you can get a simple use case I'd be happy to look into it while I'm digging around in the debugger.

I think those functions are better suited in std_extra.zh; I'm open to a second opinion though.

Put it in stdextra.zh

I bumped the OP to Beta 9, and I updated all of the links, and the changelog, and other information, there. All of the fixes discussed in this topic should be in the package now.


@Chris Miller : Could you adjust the topic title, please? I think that this is a forum bug, but editing the title for the OP no longer changes the title displayed anywhere on the forum, unless a Mod+ does it. I simply need the '7' to become a '9'.

21st Sept, 2017 @ 03:30GMT

Bugfix: 2.53_Win_Beta_9--fixdrinkguys.zip

I updated the link in the top post of the thread. Anyone still testing the original Beta 9 release can toss it in the scrap heap, unless you want a few giggles...