@username Well, I think it's great you're keeping things going for 2.0, and should still keep at it. When I first came into the community, I've always admired your contributions, and while I may not agree with everything you've said, these views were all well thought out, and delivered.
I'd like to think that I do my part for it as well (i.e. 2.0 modules/components that can work in 1.3 today), but I got a long time ago that a lot of people were skeptical at best in terms of execution, whenever I pipe in with an idea, so I did what I do best: rolled my own way. You'll be glad to know that the UI was the first thing I made easier to use. I'm almost done porting just about everything from the Preferences API to AC Configuration, and plan to weed out, bit by bit, the messy control scheme in order to have a configurable master map of controls. But it IS a mess, so I'm touching that quite a bit further down the line.
I respect your opinion about the additional features. Indeed, I put those in because I subscribe to the belief that one man's garbage is another man's treasure
Only time will tell if anyone makes anything out of these. We'll see.
@wolph (and a bit of username's comments as well)
If there is anything in common between we who have forked the code is, we just "do", and talk along the way. I understand as well as anyone that the best designs come from careful planning, and if ever 2.0 comes around, it will definitely show there.
I agree we all have differing viewpoints, and, in my case, I'm too far ahead to stop and consider the newer inputs. Besides, with differing viewpoints, we will (likely) have what has brought the most delays to 2.0: lengthy discussions, when there's very little time to do anything else. Moreover, we also have different scales of how far we want to take this, not to mention our philosophies are also quite different. For example, backwards compatibility; one wants to scrap macro script while the other is conscious about keeping it, going as far as to write a simple plugin system so that stuff made can cross over nicely. Who wins out? Both do as they'll go their own separate ways.
I'm not tooting my own horn or anything, but I'm gunning for bigger ideals, and I believe I design with the big picture in mind. There are simply too many new (and modernized) VTTs for MapTool to stand on its merits and be considered in the top 3, anymore; powerful scripting, vision, and everything else considering. I believe everything starts with fostering a healthy development community (not the actual source, but in-game content), and a large consumer base.
The healthiest dev community should encompass the works made through macro script, and the ones made by future scripters who can use another language. Whatever others might say, Oracle chose Javascript to be the one their Java tech plays nice with, and will certainly be the language of choice for the HMTL/CSS/JS crowd.
The consumer base will only flock to where great content is easily found and put together. As powerful as MT is, it doesn't quite offer this. I think I saw a post a few days ago where someone was pointing a free tileset, and someone else said that it was great and we should tell dorpond about it so he can upload it to wherever MT's accessible image assets are hosted. If, for example, I were a content creator who wants to reach out to as large an audience as I can, would this be the setting that I want my work to be initially displayed? Of course not. IIRC, that tile set trickled down from a Roll20 user's post.
Not to mention, while a lot consider it fluff, audio assets and the ability to play them, when available, will
definitely be used. If one VTT offers it and the other doesn't, users who just want a mat to play on and don't care much for automation, will choose the VTT with the sound feature over the one that has the powerful script engine 10 times out of 10.
With that being said, what do we do? I know there are quite a number of people here that (respectfully) disagree with my method of executing my "vision" (i.e. crowdfunding), and their silence is notable, but I don't see a better way to make a bigger, and lasting impact than making people invest on an idea, and have expectations that their investments will be returned. Anything else in the realm of production is just a hobby, and will always be in danger of being set aside for something more important. Bottom line, if die-hard fans of this VTT want its (re-)ascendance, it won't come through the current volunteer system, regardless of how skilled the team behind it is. I am confident enough to say this: If an MT fork does well and is on par with what's hot right now, then people will be more than willing to wait for the real next-gen release.
Anyway, in my defense, I was "hiring" when I first started out, just like the other people working on the forks mentioned here. Like them, the response was (forgive the word) tepid. Things took a life on its own, and my team and I recognize it was an opportunity for us to finally work together professionally.
This'll be the first I'll mention this, but my development group and I have bigger plans beyond Mote (the name of my fork). We're investing 1 to 2 years to make good on our promise of a mature, and modern VTT, with a thriving community of users, developers (framework, not source), and content creators, all connected with no middle-man in between, after which we'll open the source, and move on to our enterprise targets (i.e. different industries). Sure, we'll be asking for support to do this full-time during the period, but our real compensation is the rewards we reap from a great reputation, if we pull this off well. So, with such stakes and rewards, you can see why we don't just "hire" anyone who comes along
OSX uses a "disk image" (filenames ending with ".dmg") as the installation format of choice. Users double-click the .dmg and the OS mounts the disk image and opens a window showing the contents. There is typically an icon that the user drags to their /Applications folder and now the app is installed. Building the disk image is half the problem, the other is the Jar Bundler.
