Contributor instructions

[DarkDragon]

Groups of variables are fine. (Especially if they are simple getters/setters) but please don't add dozens of functions at once, plus C-style block comments, plus function pointers, plus...

Also there has been disagreement in the past about which variables are worth adding and which are not. If you send a pull request with a large group of variables, you might be told to break it up further.

[ZoriaRPG]

Groups of variables are fine. (Especially if they are simple getters/setters) but please don't add dozens of functions at once, plus C-style block comments, plus function pointers, plus...

Also there has been disagreement in the past about which variables are worth adding and which are not. If you send a pull request with a large group of variables, you might be told to break it up further.

Has anyone in recent history, reviewed the change logs or ZScript files to note what I added to this build; or is this just speculative based on ideas I've thrown around? Why not look at the files:

Here is a compiled list of the additions, in short form.

To be honest, I just don't feel that this is worth touching at all until the following occur:

(1) Saffith signs off on it. Top prirotiy, that, as his decisions have shifted this back and forth several times, up until this fork, which is based on what he said would be the master branch. I don't think it is worth devoting time to it until this happens.

(2) The latest bugfixes to 2.50.3 are implemented in it.

(3) Gleeok's script drawing changes are implemented. He changed several factors in the way that this works, and until those changes are solidified, building on it is pretty wasteful. Note that DrawBitmapEx() will NOT work without at least some allegro 4.4 components. I hacked in some drawing routines from 4.4 (into 4.2, and they still run on the old libs) to get it to work at all. For proper, and full implementation though, 4.4 is mandatory. At present 70% of the supported modes are disabled by default.

(and D) There is public disclosure on who is in charge.

I would also like to see a core dev hierarchy posted visibly. All the discussion on this branch should have been public, IMO. Keeping it dark and then throwing it up there seems to me, to be in bad taste for an open source project. Everyone involved should have had in out, and while I don't have objections to the refactoring, many questions remain unanswered, and this still does not seem finalized. I haven't a clue who was involved, other than you, at present, and who approved the branch.

Because of what has happened in the past, I'd like to see @Saffith and @Gleeok mark this as approved before I even think of touching it... This is nothing against you, but rather, to prevent doing this a fourth, and a fifth time. This is already my second round of fun, and the new CMAKE branch will make the third. I specifically took all of December off to work on this, because it was (supposedly) finalized; during which time I have often elected to not sleep, just to keep on focus, as to get something usable completed.

I do not have time to reimlement the same things repeatedly, and I would appreciate if the core devs would go over the changelog, and the short list of new stuff, at the least, and tell me in advance if anything is not going to be included. This could well make the difference between working on the core project, and just going me own way with it. That was always in the cards, from the onset.

I certainly do not wish to waste me time makng changes that won't be included.

It would also be nice to see some documentation on the changes; particularly the benefit and drawbacks of what the refactoring entails, in summary form.

[DarkDragon]

(1) I think it is an excellent idea for you to discuss with Saffith what changes he thinks are valuable to make to the ZScript system. In fact I would like to be involved in those discussions as well. It is good to have such discussions before anyone does any more coding.

(2) Those should already be in (if they were in 2.50.x).

(3) Merging in Gleeok's changes from the current-master, and adding Allegro 4.4 (again, assuming this fixes more hardware issues than it creates) are both high-piority items for the near future, as I've said in the past. I will work on this myself once the build system and repository is sorted out.

(4/D) There is no hierarchy. You can see the list of people with commit access on GitHub, and War Lord decides what binaries are available for download on zeldaclassic.com, and whoever is in charge of PureZC does likewise over there. That's it in terms of formal structure. Informally Gleeok is the current lead developer, and I will defer to his final decisions, but for the most part development works by consensus. If one developer goes rogue and runs amok, the rest can fork the repository and keep working somewhere else; such is the nature of open source.

This does mean that there is a constant risk of miscommunication and developers working at cross-purposes. It also means that decisions can be slow to make and changes difficult compared to a corporate setting where some manager hands down orders from on high. For example, I am currently trying to convince Gleeok that using CMake instead of manually-curated Makefiles is a good idea. If I'm not successful, the whole CMake thing will get rolled back. You are certainly wise to wait and see how things fall out before investing a lot of your time.

My best advice to you is to pick one small but important change you would like included in the official ZC release, and (once the repository is sorted out) make a pull request containing that change (and only that change). One of us will review and accept it. Once you can see for yourself that the change is in the official ZC source, start working on the next feature. This safeguards your own time, and also makes it easier for us to check your work: win-win.

It sounds like you are hoping one of us will pick through your fork and check all of the tens of thousands of lines of changes and personally approve them, and copy them into the official source. I hope you understand why this is probably not going to happen. I *do* want to work with you and I *do* want to make sure your useful and valuable features find their way into the ZC source, but I also have a responsibility, which I consider even more important, to ensuring that ZC remains stable, maintainable, and backwards-compatible. I will help you, but you have to work within the collaborative-development system.

And for the record, I am really sorry that you are in this position. This situation, where you have a huge divergent fork, should never have happened, and should never be allowed to happen in the future. But the only reasonable way forward now is to go through your changelog and apply patches one useful feature at a time.