My near-term plans

DarkDragon wrote:My plans for the near future are to help with the following:
- incorporate useful changes that were made to the old branches (now, historical/old-master) but did not make their way into the current master;
- investigate adopting Allegro 4.4;
- start reviewing and approving pull requests from ZoriaRPG, Greyswandir, et al.

I'm particularly interested in fixing the Windows fullscreen issues, the Ubuntu sound issues, and the missing ZScript draw commands, as I believe these are the most pressing issues. Once that is done, I think we can release 2.60 and then move on from there.

I would like to have a discussion on ZC version numbering with you. I've had this conversation in the past, and I think that a jump to 2.60 is unprecedented with such minor changes. If we incorporate the new ZScript, and parser stuff, even then, I think 2.55 is as far as it should go, with a potential series of updates/expansions to follow, leaving 2.60 for more radical changes; such as the introduction of Angel\script as an optional front-end to the scripting syntax.

We've been working on stuff like npc scripts, and the like, in the background. They will not make it into a release in the immediate future, but I think it would be good to have one primary release per year, if not two, until we get to a stage where a rewrite is stable. In so doing, we continue to drive interest in ZC, by showing that development is live. I don;t think that jumping versions in tens at this point is prudent, but if we go for 2.60, we need an intermediate 2.55 release with what you are declaring as the feature plateau. I think that most of the stuff we're wanting to add will be stable, and without foreseeing any other complaints, adding the stuff to 2.55 and 2.60 in stages should be practical.

Don;t forget we're doing this for love, and in whatever spare time we can afford. As I mentioned, I decided to take December off just to work on this nonsense. 😛

I could have also misread your post. It reads as if 2.60 should only incorporate the windows fixes, draw instructions, and ubuntu issues. If you meant it should include all of the above, then that's probably fine. If you want to release an intermediate with only those, that's also fine, but really, 95% of what I've done has proven stable in tests. What I need though, are more dedicated testers.

I think that some rewrites and refactoring of Link.cpp are mandatory though,f or 2.60.

Sure, we can do 2.51, or some other numbering scheme. The exact value of the number is not so important to me (seems a "bike shed" type issue).

DarkDragon wrote:Sure, we can do 2.51, or some other numbering scheme. The exact value of the number is not so important to me (seems a "bike shed" type issue).

There is also a great risk of user confusion with some numbering schemes. Users have intermittently used 2.50.1, 2.5.1, and 2.51 to reference 2.50.1. The same applies to 2.50.2, and 2.50.3 will be no different. That's why we started with 2.54, as it shows a secondary version increment jump, and it can't be confused with any other release.

We need a sane, easy to comprehend scheme for versioning these things, because it is a huge support issue when there are potential conflicts.

I don't know when the heck '2.5' became '2.50' either. I know it wasn't that, initially. I could only guess that this was to show that as a higher value than 2.10.1 or 2.11. ???

That's why I was thinking 2.6, since it does not conflict with any flavor of 2.5*.

DarkDragon wrote:That's why I was thinking 2.6, since it does not conflict with any flavor of 2.5*.

I suppose it depends on what goes into it. I was hoping for an intermediate release with some new stuff for users to try out, in an attempt to revitalize interest in ZC as a whole, because the refactoring, and back-end wrappers are going to take a while to put together.

I would certainly call something that updates massive amounts of code 2.60. If it's just ag 4.4 and minor stuff like the script drawing additions, and some of what we've been doing to 2.future, 2.54 or 2.55 would suffice, as they do not conflict. It would be nice to try to roadmap all of these ideas at some point.

I've been wanting to dive in and start prepping myself to being a useful contributor someday. Wrangling ZC code into VS2015 was a royal pain until I found your fork with a 2015 sln file. Are the CMAKE changes and repository issues on their way to being in order? I question whether I should bother trying to jump in if I don't even know what branch I am diving into and fighting with getting it working in VS2015 is a bad memory.

I've looked into the sound problem on Ubuntu some. Seems to be that it's a bug in PulseAudio, but there's something about Allegro that triggers it far more often than most applications. And it is Allegro, not ZC; Allegro's sample programs are just as bad.
As a workaround, killing pulseaudio (pulseaudio --kill) fixes it.