Regarding the further development; I must accept that as my own organizational failure again, that the 3.4.0 is taking a little long already (and getting little big), and there certainly were things that could be released earlier. Additional problem is that we have particular features introduced, but not complete (they either have annoying bugs, or simply not working as they should in all aspects yet).
Therefore, the decision I am proposing is this:
1. We slow down on adding features to 3.4.0 now; preliminary deciding which extra features it still might need. By features I mean completely new stuff, not fixes of something that does not work well (enough) - that's a separate question. We should not go too far with these. I will note the ones I believe should be added, or at least considered, below.
2. To improve the usability of 3.4.0, and therefore let people use new wanted features with less fear, we might focus on fixing the worst of the known problems first. I suggest developers should scan through the changes they were working on in the past time and see if anything requires fixing. I will make couple of notes regarding these below too.
3. When considering on adding a feature or a fix, we need to examine whether it could be added on top of 3.3 branch instead.
It is difficult to make a strict rule here, but I think that it may go to the next 3.3.* release if:
a) it does not depend on any of the changes made in 3.4.0;
b) it does not belong to same distinct group of features as introduced in 3.4.0 (like the lots of new script commands made by Gurok);
c) it does not require a big rewrite of the existing code, - this is something we do in 3.4.0.
d) critical fixes (program crashes etc).
4. This might happen that someone would like to start working on a new feature, and find him/her-self having progress, but the feature may be too large or taking too long to add into 3.4.0 (since the proposal is to start "freezing" it) - in such case we may create a next development branch for 3.5, and even make an alpha release, if some users will be wanting to have them.
But that is a possibility; I would prefer we finish what we started first.
The features I would like to still put into 3.4 branch are:
+ Mouse sensitivity (I really hope to finish this);
+
Draconian features;
+ Fully working User managed structs (they would put AGS script up on a completely new level).
+ Sprite cache limit (was bugging several users in the past already).
Most annoying problems to fix:
+ Well, first of all is a new game compilation system (multiplatform), which has number of seemingly non-critical, but pretty irritating glitches (dedicated thread here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=51289.0);+ Some bugs in display resolution init were reported, I'd need to look into them.
A special note regarding ports (especially mobile ones and OSX, because Linux is more or less stable now).
I was asked about them number of times, and I must say this.
Unfortunately, I have a little knowledge of them, and did not have a chance to study their work. This will be impossible for me to do anything without learning how they work, which requires time, which I do not have much at the moment. Realistically, I would not be able to do anything here, at least not before we make a first stable 3.4.0 version.
That would be very fortunate if someone could dedicate him/her-self as a port maintainer to solve many questions asked in related threads and provide new builds regularly. OSX port requires special treatment, which I would not discuss right here (there is a lot to say, and I would like to speak only to someone who is ready to work on it).
Same with various documentation, manual etc, I probably won't be able to address these issues until stable 3.4. As you may see, my time I can dedicate to AGS is limited, and I find it very difficult to switch between tasks all time.
