Tamamo wrote:
This is also my one of my goals as well. So I agree that this stuff needs to be done. Have you taken a look at my Mirror Shielded Enemies code yet?
I did. I'm not sure why you didn't just set a flag for what it can reflect, and then just treat reflected weapons exactly as shielded enemies treat boomerangs, except that you replace the weapon with a ew type. (i.e. kill the lw, make an ew, set its dir to reverse.) That method is already there, so, why not re-use it?
It would be nice if weapons returned if they were blocked, or reflected by a shield (for ew and lw) though. That should be a unique deadstate across the board.
Speaking of widgets; Saffith, at least I think it was him anyways, has been replacing the allegro GUI with GTK. Now isn't that fancy, Now quest rules have tabs!
We really need to stop using QRs, and make any new rule a quest setting, that isn't tied to these old values. As I said, what I was thinking, is that we make a Game->Settings[] array, with each setting using one index (easier to parse in iteration than binary flags in one index). Read that array in functions that (at present) read quest rules. Thus, the old rules will turn into boolean values in that array, and can be read, and set by script. This means that we can do things, such as changing scrolling methods at different points in a quest.
I'm not sure what shifting to GTK will do, but it should potentially fix some display concerns.
I agree with you there, more of the reason we need somebody willing to call you all to a round table and have a cup coffee and talk things over.
Well, you pretty much said you were disinterested in what we're planning, which is why you weren't involved. The rest of us discuss these things regularly, and we pass on ideas, and our plans, to Gleeok; but it's all based on 2.5/2.6, and as you've said multiple times that you had no interest in working on that, ...
You also refuse to use Skype, which is where we tend to congregate. I wouldn't mind if the SysOps added a 2.6 board as a subforum though.
Hahaha, I do not discriminate don't worry I treat everyone fairly. I work with ZoriaRPG more then you think. 😉
Speaking of which [MENTION=42228]ZoriaRPG[/MENTION] I'm planning on rewriting weapons next month to make it less of a mess. I'm going to add inheritance. In otherwards their will now be a class for each weapon type. Their might be some Parser changes so I'll get together with you on that later on.
If I wrote the new setter/getter stuff right, that'll make a good example on adding new ZScript instructions.
You'll need to detail what you want to accomplish with this, and what you're changing. You're pretty much saying that you'd need me to write a unique class interface for each type, which would be pretty redundant, and time-consuming to create, so tell me what advantages separating *weapons into unique classes would have. I think it'll make a huge mess, as it means that we'd need a specific type for each class, so instead of eweapon and lweapon, we'd need 20+ classes for each in ZScript. That is a whopper, in terms of adding it, and I don't see the practicality of making a user remember all of that; plus, it'll break things LRC.
I'm not sure that anyone is too distressed over these sharing a class, otherwise. It's convenient. The main problems seem to stem from using script types, and some properties of other classes that can't be changed; and of course the ypes that are part of the Link class. I'd suggest giving priority to those, so that swords, hookshots, staves, wands, and whatnot can be created, and modified. Making the ladder an lweapon, might be extremely amusing; but it would be more painful than almost anything else I've mentioned to date. Hah. )
Unless you mean that you're making them properties of the main class, and giving them their own properties. That might work, but again, I try not to overly muck with the things that do work at present. This is the sort of thing that I'd push to 2.6 or later, and not 2.55, as it'd require a lot of rewrites, and testing. Our main objective is to push out a new, stable release, with features that hve been repeatedly requested, or that those of us in the group want pretty badly.
We will cross the bridge of removing ZScript when we get their. Most likely it isn't gonna happen. In fact I would be against it.
(We'll burn those bridges when the enemies are at the gate.) I've given some thought to using flex/bison to con vert ZScript to AS at some point, but if AS has an in-build ability to write parsing defs, which I believe it does, it could be done more elegantly. The main thing, is that you'd need to add the ZScript types to AS, grandfathering them (old_float, old_int, old_bool, old_sring), then tell the AS interpreter how to handle them. The rest of the syntax should otherwise be identical.