2.x vs 3.x

[Tamamo]

I've decided to take it upon my shoulders to start acting as an ambassador between 3.x developers and the 2.future fork.

Here are the 3.x threads
Gleeoks Original Proposal
Angelscript Proposal (removed for now)
Saffith's current goals
What Gleeok has been working on

Here are the plans for 2.x

Important: All of this is quoted from saffith here.

My only goal right now is to clean up the code so that it's possible to make bigger changes without everything falling apart. Anything else comes after that. Even the AngelScript integration was meant to be to that end.

I don't consider backward compatibility optional. I don't want to put out 3.0 and have it be unable to play a large subset of quests, especially recent ones. If it goes into 2.x, it goes into 3.x.

I don't even see PMs here half the time. vB isn't so good with the notifications.

Seems... mhm "We have come to terms"

[Dimentio]

Not to be rude, but have there not been issues between you and Zoria in the past? Not to mention you kept dismissing a bug most of us though was a bug as "not a bug" simply because it could be worked around. Are you sure that you can handle being an ambassador?

Anyways, I'm neutral on whether to continue 2.X or 3.X. 2.X has everything set up, so it would probably be faster, and more people would be more comfortable with the familiarity. However, 3.X would give us a lot more room to work with, and would be easier, as we'd know what each and every variable would do. So whatever the majority feels, I guess. Maybe a rewrite of 2.x?

[Tamamo]

@Dimentio
If you are depressed, you are living in the Past. If you are anxious, you are living in the future. If you are at peace you are living in the moment. – Lao Tzu
That is all I have to say about the matter. And you assume I'm the only person whose had problems with ZoriaRPG in the past. I assure you I am not.

[ZoriaRPG]

It would be nice, but in reality, it means holding off making anything new, or useful, for two years, or more. There's no reason that changes can't be reintegrated, if the changes are logged. In fact, most of what I've been doing should be reusable as-is, either way.

It cames down to:

1. New functions, tied into the ZScript bytecode tables.
1a. Drawing related.
1b. System-environment related.
2. Bison/Flex improvements and expansions.
3. Class object->Property additions.

By the time we get 'round to doing some of the things on the list, if there's a cleaner basecode, we'd use that, but there's no valid reason to put what we're doing on hiatus for an indefinite duration, nor does any one of us want to sit down and rewrite all of the enemy, or Link, collision, or weapon handling at present.

FFC improvements, as I mentioned, should in theory be a drop-in replacement for either branch.

In fact, in the process of expanding various components, it is possiblethat they'll be cleaned up. I'd like to make the process of adding ZScript instructions clearer, too.

You also need to keep in mind that the rewrites might fail. There is no way to determine hw long it will take for a 3.x rewrite to be stable, at all, if ever. I was around for the 2.11/2.5 rewrite. It was a period of eight years of darkness, and I eventually gave up feeling that it was vapourware.

A fair amount of what I'm doing, is finishing features that were planned, or intended for 2.5, and left unfinished.

You also need to pay attention to the general lethargy in the userbase. We really have had little to no influx of new users, since 2.50 was released. New releases, even if imperfect, revitalise the community, by drawing interest of new users, and by reigniting interest of present users; as they try to top one-another in 'showing off' what they can do with the new/updated widgets.

I'm watching every day as users fade out, and no-one replaces them; the general activity tapers off, and interest wanes. In two or three years, with nothing new or exciting to offer, there won't be anyone left to use or appreciate a cleaner codebase. People want features to compete with other tools, and without them, they'll just use other software. Once that happens, good luck getting them back.

[Dimentio]

Oh no, I never said you were the only one. I'm just hoping that there won't be any biases or such.

Anyways, I think a rewrite would be the best thing so far, if only becauseit would allow us to get out of the mess that 2.5 is. However, I think we should keep most of the things 2.5 has, like ZScript. If we were to remove ZScript, that could turn off plenty of people.

Again, though, 2.5 would make a new update faster, without turning off anybody. I think that cleaning up 2.5 would be a rather nice goal.

[Tamamo]

It would be nice, but in reality, it means holding off making anything new, or useful, for two years, or more. There's no reason that changes can't be reintegrated, if the changes are logged. In fact, most of what I've been doing should be reusable as-is, either way.

It cames down to:

1. New functions, tied into the ZScript bytecode tables.
1a. Drawing related.
1b. System-environment related.
2. Bison/Flex improvements and expansions.
3. Class object->Property additions.

By the time we get 'round to doing some of the things on the list, if there's a cleaner basecode, we'd use that, but there's no valid reason to put what we're doing on hiatus for an indefinite duration, nor does any one of us want to sit down and rewrite all of the enemy, or Link, collision, or weapon handling at present.

Yeah I can understand that. It's a pain in the ass to work with. >_>

FFC improvements, as I mentioned, should in theory be a drop-in replacement for either branch.

My thoughts exactly.

In fact, in the process of expanding various components, it is possible that they'll be cleaned up. I'd like to make the process of adding ZScript instructions clearer, too.

Definitely needs to be made clearer. I refuse to touch that stuff.

You also need to keep in mind that the rewrites might fail. There is no way to determine how long it will take for a 3.x rewrite to be stable, at all, if ever. I was around for the 2.11/2.5 rewrite. It was a period of eight years of darkness, and I eventually gave up feeling that it was vapourware.

Yeah it's sad but true. It's going to be a long tunnel, but it's sure in hell gonna be worth it.

A fair amount of what I'm doing, is finishing features that were planned, or intended for 2.5, and left unfinished.

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?

You also need to pay attention to the general lethargy in the userbase. We really have had little to no influx of new users, since 2.50 was released. New releases, even if imperfect, revitalise the community, by drawing interest of new users, and by reigniting interest of present users; as they try to top one-another in 'showing off' what they can do with the new/updated widgets.

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!

I'm watching every day as users fade out, and no-one replaces them; the general activity tapers off, and interest wanes. In two or three years, with nothing new or exciting to offer, there won't be anyone left to use or appreciate a cleaner codebase. People want features to compete with other tools, and without them, they'll just use other software. Once that happens, good luck getting them back.

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.

Oh no, I never said you were the only one. I'm just hoping that there won't be any biases or such.

Hahaha, I do not discriminate don't worry I treat everyone fairly. I work with ZoriaRPG more then you think.
Speaking of which @ZoriaRPG 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.

Anyways, I think a rewrite would be the best thing so far, if only because it would allow us to get out of the mess that 2.5 is. However, I think we should keep most of the things 2.5 has, like ZScript. If we were to remove ZScript, that could turn off plenty of people.

Again, though, 2.5 would make a new update faster, without turning off anybody. I think that cleaning up 2.5 would be a rather nice goal.

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.

[ZoriaRPG]

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 @ZoriaRPG 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.

[Gleeok]

Speaking of which @ZoriaRPG 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.

The problem with the complexity of ZC isn't actually because some things are hidden behind layers of needless abstractions or shitty virtual functions, or, other things are just plain data where runaway procedures are free to alter anything and everything they feel like. The problem is more because of state. ZC is a ginormous twisted mass of wires and circuits that breaths fire on elephants and then eats their burning flesh before laughing at you and then exploding. Simply put, everything is already doing too much. Whether you have a switch or a vtable it's not going to change much. More abstractions never actually solve any real problems, they simply abstract them further, making them even harder to deal with later. I would argue that any reasonable improvement to a problem of 'too much' (state, bloat, special cases, years of bug-fixes, etc) is simply less code, not more. Sounds simple, but it took me years to figure it out.

[Tamamo]

The problem with the complexity of ZC isn't actually because some things are hidden behind layers of needless abstractions or shitty virtual functions, or, other things are just plain data where runaway procedures are free to alter anything and everything they feel like. The problem is more because of state. ZC is a ginormous twisted mass of wires and circuits that breaths fire on elephants and then eats their burning flesh before laughing at you and then exploding. Simply put, everything is already doing too much. Whether you have a switch or a vtable it's not going to change much. More abstractions never actually solve any real problems, they simply abstract them further, making them even harder to deal with later. I would argue that any reasonable improvement to a problem of 'too much' (state, bloat, special cases, years of bug-fixes, etc) is simply less code, not more. Sounds simple, but it took me years to figure it out.

You're going to like this Gleeok, trust me. Something needs to be done with that convoluted mess. And it matches Saffith's goal on making the codebase more manageable. So everyone wins.

[ZoriaRPG]

You're going to like this Gleeok, trust me. Something needs to be done with that convoluted mess. And it matches Saffith's goal on making the codebase more manageable. So everyone wins.

One thing to note, is that even if it doesn;t make the cut for 2.,5x, or 2.6x, or even 3.x, you can always make a custom fork that uses it, and if people like it, or want it in a main version, we can add it. This is the type of thing, that I'd want user opinions on, before committing it, anyhow; and of course, I'd need to know how it will change the interface (ZScript instructions) for handling the objects. If it's transparent to the user, and only adds options for them, that would be fantastic.
@Gleeok : Ypu forgot, that it explodes into inverted butterflies, made of smoggy rainbows.