Alathon wrote:

JBoer wrote:

I would like some help with the Eclipse plug-in project, though I'm not sure where I can advertise that since nobody around here seems to care about such projects. :(

I'm sorry you feel that way, and I'm fairly certain that isn't the case.

Oh no? Are you willing to help me with this project? And if anyone is, how long will it take before that person is going to give up and stop working on it?

I find this thread exemplary, in that it demonstrates what is basically a problem in expectations and communication. If Tom were never anywhere to be seen, and never responded to user features, users would instead debate amongst themselves on how to improve the existing suite. But because he is, and in fact spends a fairly gracious amount of time reading user feedback (Because he's one of those rare breeds that does in fact care), its oftentimes easier to request a feature. And people requesting features that Tom personally reads, expect him to realize how important the given feature is.

I expect that if I create an issue that it's going to be looked at.

I think that the problem is that neither Tom nor Lummox JR know how an issue tracking system is supposed to work.

An issue gets reported by someone. One of the developers of the project would look at the issue and decide whether or not it has merit. The issue is then either assigned to someone or immediately resolved with a reason (e.x., "already implemented/works for me", "won't/can't fix").

When I then go and look at the issue and it's been assigned to one of the developers, I'll know for sure that my issue has been looked at and that someone is responsible for it.

Normally when an issue is resolved a senior developer has to close the issue. This workflow allows the senior developer to see all resolved issues, and if necessary, to reopen them in the event that something is wrong.

I've seen this in many issue tracking systems but not in the one on this forum (and the ones blatantly added to all hub entries).

But you're right, I think this is a communication error in that I've been misunderstood. I don't really care about getting these features implemented because at the end of the day BYOND remains just a hobby for me and I realize it's going to take time to do these things. I just want to see a document with a projected timeline so we can all see the grand scheme of things.

This isn't to say that feature requests are 'invalid' or wrong, I've made quite a few myself over the past 11 years. And the feature may be entirely valid. But it stops being productive, when it goes beyond a feature request, over to, 'BUT THIS IS IMPORTANT! STOP DOING WHAT YOU'RE DOING AND DO MY THING!'.

I believe that the current direction of development is wrong. Focusing on developing a grandiose feature (the Flash client) should not be done in this case as Tom is suffering from major staffing and financial issues.

I've been here for over 5 years and the IDE has always remained the same. I may be part of the "entitled generation" but the thing is that I've been content with everything for years. It's going to be outsiders who will see the lack of features that the IDE has to offer and walk away from this platform. It's going to be them that see that this language doesn't even offer a proper way to catch errors (even suppressing the log messages when a game has been running long enough).

And what kind of message do you think a thread like this one sends to an outsider? That this language won't improve, and that it'll be a waste of time to write anything in this language.

As an example, having the compiler run on a separate thread is something that should have been added years ago and probably could be done in a few hours as the only thing it involves is running "dm.exe" as a separate process and feeding the results back to the IDE.

IMHO the only way to continue is to improve the software bit by bit, not working on grand features.

The trick is not to try and manage Tom's product for him, because you're not going to anyway, and its just stepping on toes and wasting time ;)

Don't get me wrong here. Even though I don't fully understand the motivation behind the Flash client I acknowledge that Tom has the final say in the development of BYOND and I don't intend to offend him or his creation. After all, I wouldn't be using this if I didn't have that respect.

All I've been asking is that we're kept in the loop of what's going on development-wise instead of having to pull this information from a staff member. A projected timeline would help considerably as we'd all have an estimate of what the future of BYOND has to offer. I don't care how accurate it would be but knowing anything about the development of the software is better than knowing nothing at all, and I feel that none of us are getting any information about the unresolved "Open" issues.

We treat the bug system more as an "official" tracker, where we try to update the status and attend to issues pretty quickly. As of this writing, there are only a handful of "open" and "verified" reports, which is pretty good. Although our software and website releases often have issues, we put a premium on fixing them as quickly as we can, and the tracker has been a big help in this.

The feature tracker is really more-or-less just a forum where users can make suggestions. We only put it in the tracker system because it's a convenient way to organize things and generate the release notes for us. If it makes you feel better, you can assume your feature is "deferred" unless we say otherwise; I don't think saying that explicitly really helps anyone because whoever requested the feature is going to defend it and this will just lead to back-and-forth that, honestly is a big waste of time. It is not that I think that the feature suggestions are bad, but rather there are too many good ones.

As an example, let's take your compilation in an outside thread. The reason I haven't done this yet is because, while it's a perfectly reasonably suggestion for how a "modern" IDE/compiler should work, I don't think it really adds a lot of value. DM would basically be unusable (just not frozen) during the duration of the compile. Like I said elsewhere, the main thing is that you could kill the process, which is something that helps a few marginal cases (albeit for the bigger games such as SS13, which inflates the priority somewhat). So this is what I call a low-priority feature. Same thing with the tabbed editing-- it's not that I didn't do it earlier because I wasn't aware of it or that it'd be hard to do; it's just that it's not really that important. I'm glad users seem to mostly like it.

The software has been steadily improving for many years. We've had almost 100 releases since 4.0 (with many more subreleases) and each one has numerous bug fixes and/or features. And this is on top of stuff we don't even mention . And this is only on the software, not factoring in the website, hub, or the various database and tool improvements we have on the backend.

My view of BYOND is that the language and product we have today is largely complete. I realize there are a zillion different language improvements that could be made, but we have fundamental limitations on what we can do based on 1) money, 2) time, and 3) (most important) the design of what is basically a stable product. As such, I'm concentrating on taking the product we have now and taking the perfectly viable games it has created and can create into the mainstream. If we are successful, then we could look into taking what we now know and spinning off into a more modern product (that would have some fundamental differences such as a simplified language with a single atomic type, native pixel-based positioning, and client-side processing .. as well as just using Eclipse for the IDE). As of now, that is a pipe-dream, though.