I ask about shaders and bump mapping because GAE had some of this working in game. I put some bumpmaps in tech and tested before and it worked. Perhaps much could be learned/brought over from there?
I assume there are feature implementations in GAE which can be merged without major modifications. It neccessary to keep in mind, though, that GAE and MegaGlest have sufficiently changed under the hood, and diverged from both Glest and each other, that in most cases porting existing implementations of a feature from one to the other engine is not a matter of copy-and-paste. All of what you have in MegaGlest now and in the future is and will need to be written in a way that it will work for cross-platform gaming. My (admittedly quite limited) understanding of GAE is that this was never a strict requirement there.
As such, implementing features there could - with respect to cross-platform compatibility - often be done in a different (and possibly less complex) way than it is the case for MegaGlest. So in cases where you coud copy a feature implementation from GAE and it would work for single-player MegaGlest with just slight editing, this
may break cross-platform network gaming, and thus a different approach (and thus new code) will need to be used. Of course there can also be situations where programmer just thinks that the way something is already done elsewhere is not the way s/he likes it / think it should be done - that's a different matter. So it can be one or the other or a mix.
I do not mean to bash on GAE here, it is very well possible some preconditions (such as "must work cross-platform") would also need to be complied with when porting in the other direction, I'm just not into GAE enough to know them.
I understand your time constraints, but I was just checking, as honestly we've had little word on the topic. Thanks.
In fact you asked whether
we are going to get a feature
within the next 6 months. I do understand that you are
not (at least not directly) asking that something is done for you within 6 months, however, the way you're putting it can be interpreted as getting close to it.
A little excursion into grammar to explain why: In your sentence,
we probably refers to the modding community,
are going to get is passive/intransitive, i.e. the receiving party is not going to contribute to make it happen, and the source it is supposed to come from, while indirectly addressed, is not even mentioned (but it's clear from context that it's supposed to be Softcoder and Titi). While within professional projects asking for and even requiring a timeline and fixed date of completion is perfectly fine, this is almost never acceptable for hobby projects. And while its developers are professional programmers, MegaGlest belongs to the latter category. Getting used to this, and that there will never be any fixed timelines, is part of getting used to work on this and any other project which isn't driven by commercial pressure (which is the case for many projects with a developer community, for example). This very aspect, the lack of fixed time constraints,
can make it fun for developers to work on it, and is often a precondition for them to get involved in some pro bono project in the first place.
As such, for a developer even asking whether or not a given feature will (reliably) become available within a given period will not just remind a developer of paid work, which this project is not, but also displays that the requesting party is not fully aware of the overall situation and her/his position.
I'm mostly writing this long statement to make it easier to understand each others' motivations, and how things feels for every side involved. Following the forums, discussion threads where it is my impression that this point of view is not widely known or participants are, based on how they discuss, are not fully aware of the situation, emerge every now and then.
Finally, to not be misunderstood: I am not (at all) saying that filing feature requests should be limited, I'm just saying that requesting statements on feasibility of implementing some feature within a given period, unless maybe there is real-world indication that it is needed to not delay some other meaningful on-going work (this situation has occurred several times, and I've always been impressed how fast Softcoder and Titi implemented new features for the more advanced undertakings such as Annex), is hardly ever a good idea on a project which works on a I-spend-some-of-my-rare-spare-time-on-this-when-I-feel-like-it basis. This is something people really, really need to understand to not demotivate the existing developers.
So (in my opinion) the best way forward is: Create something which is somewhat close to being ready, but which lacks some engine feature to make it work as desired. Then file a feature request or discuss it on IRC, explaining this very situation and showing what you have and what's missing. On the other hand, discussing (in public) that you started your work but are not going to finish it because what would drive it is (by the person stating so, and possibly others, too, and maybe it's also a generally accepted point of view, and maybe not) conceived as lacking and incomplete, won't add to the motivation of those who create what is supposed to drive it. So when you spell things out, think about how you do it, how you make others want to do what you want to achieve (this often includes demnonstrating that you can nearly finish something yourself), and how reading something feels when you have the background of the party you are addressing. This way you can get
a lot done.
