MapTool 1.4

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: MapTool 1.4

Post by Full Bleed »

KaylaKaze wrote:Actually, I was constantly hearing "It's coming in 1.4" since I first started using MT 7 years ago. Frankly, it's a massive problem. Either start posting some code for 1.4 or just call it dead so some of us who still care about enhancing MT can fork from the existing 1.3 codebase without having to worry about our work becoming obsolete by a new version.
More specifically, the so-called "lock" on 1.3 for the past few years is where I see the biggest problem.

It has deterred a good number of people from contributing, all in the name of not doing anything more with a 1.3 that "should be done with 1.4" (or 2.0 as that is now generally understood to be the next "real" version of MT coming from the fingertips of core developers we hear very little from these days).

That entire "1.3 lock" concept needs to be set aside yesterday.

People should continue to be encouraged to submit patches and mods for implementation in 1.3 until such a time as there is an actual 2.0 in the wild for users and volunteer developers to actually focus on.

Further, I feel that Az should explicitly relinquish his duties with 1.3 and *actively* seek out someone who is willing to carry the torch. His participation in the community and project over the last year very much mirrors the disintegrating focus Trevor once had... where much time was also lost waiting for a transition to present itself.

As for forks... I know there are at least 3 forks already out there:

Lee's unreleased fork.
The b90 beta that has been promoted very often by core community users for default use.
Lord Ashe's Plugin fork.

That is not a positive sign.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

wolph42 wrote: actually lee has already started branching. He wanted to start a kickstarter with this, and he has my blessing, but it has not reached so far. As for the 'official' mt. AFAIK the group is working on that, but that will take a loooong time and because this concerns a complete overhaul of MT, 'some code' can't really be published in the mean time... Still you're right, something has to happen in the mean time and there is (albeith slowly) happening new developments (like the VBL manipulation).
Thanks for the support, wolph. I've been ready since the 4th quarter of last year, but me and my group looked even further down the road to plan future projects as an official development group. With that in mind, I had to convert a lot of paperwork from a personal standpoint to a corporate one, and didn't realize that it would take almost 3 months to get to this point. These days, I'm reconnecting with people and outfits who were ready to back me up last year, and filling out stuff (e.g. creating pages, groups, and communities) that will be needed once everything revs up.

@FullBleed et. al

Please feel free to join the project portals once they go live. Things will be definitely coming to life from that point on :)

KaylaKaze
Cave Troll
Posts: 57
Joined: Mon Jun 18, 2007 1:08 pm
Contact:

Re: MapTool 1.4

Post by KaylaKaze »

Full Bleed wrote:
KaylaKaze wrote:Actually, I was constantly hearing "It's coming in 1.4" since I first started using MT 7 years ago. Frankly, it's a massive problem. Either start posting some code for 1.4 or just call it dead so some of us who still care about enhancing MT can fork from the existing 1.3 codebase without having to worry about our work becoming obsolete by a new version.
More specifically, the so-called "lock" on 1.3 for the past few years is where I see the biggest problem.

It has deterred a good number of people from contributing, all in the name of not doing anything more with a 1.3 that "should be done with 1.4" (or 2.0 as that is now generally understood to be the next "real" version of MT coming from the fingertips of core developers we hear very little from these days).

That entire "1.3 lock" concept needs to be set aside yesterday.

People should continue to be encouraged to submit patches and mods for implementation in 1.3 until such a time as there is an actual 2.0 in the wild for users and volunteer developers to actually focus on.

Further, I feel that Az should explicitly relinquish his duties with 1.3 and *actively* seek out someone who is willing to carry the torch. His participation in the community and project over the last year very much mirrors the disintegrating focus Trevor once had... where much time was also lost waiting for a transition to present itself.

As for forks... I know there are at least 3 forks already out there:

Lee's unreleased fork.
The b90 beta that has been promoted very often by core community users for default use.
Lord Ashe's Plugin fork.

That is not a positive sign.
I haven't read the forums much in the past couple of years, so I didn't know about the other forks. I'll search for them. I've been planning my own open source VTT to compete with the upcoming 2 3D Unity based VTTs and figured MT would be a good starting point. Start by adding some of the stuff MT desperately needs IMO: sound support, a built in IRC client tab that connects to a community lobby, better web resource loading, animated map objects, Lua based scripting engine, SQLite database access and some other goodies and maybe add 3D eventually, though I'm not sure how critical 3D would be with those other features.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.4

Post by wolph42 »

Brilliant that three separate programmers all three come up with three different scripting engines the mt 'direly' needs. Upto now the score is
Js, Groovy and lua.

I've done one year of computer science next to my physics masters and one thing I learned early was the saying: every problem has it's own program language... And I guess that here are as many scripting languages as there are programmers.

Petty thought hat yo don't all collaborate, IMO it's a waste of energy to keep branching and ending up doing the same, but most likely unfinished as all the others. Why build a house on your own when you can build a castle with many!

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

Re: MapTool 1.4

Post by Virenerus »

That is a very good point actually. Why not have a discussion about collaborating in further devolopment. Let's create a new team of core devs that work on a new version, and decide together on who works on which features in a common codebase.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

wolph42 wrote:Brilliant that three separate programmers all three come up with three different scripting engines the mt 'direly' needs. Upto now the score is Js, Groovy and lua.
Oh man, I love LUA :) With that being said, the winning argument for JS is that MapTool's displays are all HTML based (not the swing containers). 2.0 will likely use JavaFX and it's GUI platform is centered around Web RIA, so again, Javascript. Anyone who wants to use another scripting language will have to process the script externally from the form code, instead of having one interpreter do it all for HTML, CSS, and JS. Well that's the case for 1.3 anyway, which is why I believe RPTools narrowed it down to JS being what they want for 2.0.

Having more than one scripting language isn't impossible, but who's going to write the unifying API to allow all to manipulate the presentation aspects?
wolph42 wrote:Petty thought hat yo don't all collaborate, IMO it's a waste of energy to keep branching and ending up doing the same, but most likely unfinished as all the others. Why build a house on your own when you can build a castle with many!
I believe it's a matter of timing. I think a couple of other devs, username and someone else, just left before I arrived. I floated ideas around for a while, then struck out on my own. Since then I've formed a team of my own, and we have already started coding on several related projects with too much momentum to stop and do something else.
Virenerus wrote:That is a very good point actually. Why not have a discussion about collaborating in further devolopment. Let's create a new team of core devs that work on a new version, and decide together on who works on which features in a common codebase.
Two points. There have been many discussions. All very stimulating as everyone in it are evidently experts in the field. But it also makes a volunteer effort a very deliberate process. Someone said that it's been 3 years since anything major has happened. With that being said, if anyone wants something done, they have to do it themselves.

Second point, while you can form a group here to develop a VTT, it's not MapTool if stewardship of the code and "brand" is not passed on to you and the new group. There has been foundational work done, albeit on the prototype level. A parser from Craig, and an asset manager and some experimental stuff from username, all hosted on a Git repo, IIRC.

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: MapTool 1.4

Post by Full Bleed »

Virenerus wrote:That is a very good point actually. Why not have a discussion about collaborating in further devolopment. Let's create a new team of core devs that work on a new version, and decide together on who works on which features in a common codebase.
There used to be no urgency or need to "create a new team". The mere thought would have been sacrilege. MT used to be very open to anyone submitting new work to be added to the core program even if you weren't a part of the "core" team. Unfortunately, there was a momentum shift in that ideology years ago when a premature decision to lock down 1.3 and focus "new development" on 1.4 (now 2.0) not only dissuaded new developers from participating, it also had the secondary effect of shelving almost every feature request as well. The mantra was, "Good idea, but it won't be in 1.3 because of the lock down... but maybe in some future version."

While well intentioned and reasoned at the outset, the time with which the lock-down has been in place, and the failure to deliver something that was more open to new blood, has proven to be a disservice to MT's development. Fortunately, some enhancements have shouldered their way in regardless of the lock-down, but far less than we've seen during "open" development cycles. And, also most fortunately, many macro coders have really carried the evolution of MT on their shoulders for quite some time so that MT felt, by proxy, like it was still evolving.

Lee's upcoming fork seems likely to be the most exciting thing to happen to MT in years... but it's still more a collective of lofty possibilities and potential at this point. And no one can be really sure if/when it does hit, what form it will take and how open it will be. Only time will tell.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

KaylaKaze
Cave Troll
Posts: 57
Joined: Mon Jun 18, 2007 1:08 pm
Contact:

Re: MapTool 1.4

Post by KaylaKaze »

Lee wrote:
wolph42 wrote:Brilliant that three separate programmers all three come up with three different scripting engines the mt 'direly' needs. Upto now the score is Js, Groovy and lua.
Oh man, I love LUA :) With that being said, the winning argument for JS is that MapTool's displays are all HTML based (not the swing containers). 2.0 will likely use JavaFX and it's GUI platform is centered around Web RIA, so again, Javascript. Anyone who wants to use another scripting language will have to process the script externally from the form code, instead of having one interpreter do it all for HTML, CSS, and JS. Well that's the case for 1.3 anyway, which is why I believe RPTools narrowed it down to JS being what they want for 2.0.

Having more than one scripting language isn't impossible, but who's going to write the unifying API to allow all to manipulate the presentation aspects?
wolph42 wrote:Petty thought hat yo don't all collaborate, IMO it's a waste of energy to keep branching and ending up doing the same, but most likely unfinished as all the others. Why build a house on your own when you can build a castle with many!
I believe it's a matter of timing. I think a couple of other devs, username and someone else, just left before I arrived. I floated ideas around for a while, then struck out on my own. Since then I've formed a team of my own, and we have already started coding on several related projects with too much momentum to stop and do something else.
Virenerus wrote:That is a very good point actually. Why not have a discussion about collaborating in further devolopment. Let's create a new team of core devs that work on a new version, and decide together on who works on which features in a common codebase.
Two points. There have been many discussions. All very stimulating as everyone in it are evidently experts in the field. But it also makes a volunteer effort a very deliberate process. Someone said that it's been 3 years since anything major has happened. With that being said, if anyone wants something done, they have to do it themselves.

Second point, while you can form a group here to develop a VTT, it's not MapTool if stewardship of the code and "brand" is not passed on to you and the new group. There has been foundational work done, albeit on the prototype level. A parser from Craig, and an asset manager and some experimental stuff from username, all hosted on a Git repo, IIRC.

Personally, I'd prefer JS, since I'm primarily a web developer. I was going to go with Lua though since it seems more designed to be an embedded language and function better that way than JS, though Rhino would work. I don't understand how you think that ties into the UI system though. Maybe we're talking about two different things. As for developing with others, it's been my experience that that's more trouble than it's worth. Open source developers tend to be slow and unreliable and you're generally better off doing it yourself.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

KaylaKaze wrote:I don't understand how you think that ties into the UI system though. Maybe we're talking about two different things.
Since they went the route of exposing HTML3 through Swing in 1.3, and that they had to write macro script from scratch to support this and other needs, I speculate that RPTools' devs would now prefer a single "engine" to handle interpreting game scripts, and rendering the HTML that will be everywhere in 2.0, without having to rely on anything outside the standard kit. Also as of 2.0, the JavaFX API has a bridge for 2-way access, where Java can run JS within it's controls, and JS can call Java internals. With that convenience in place, it might be hard for devs to look beyond this for alternatives.

All they need to do after would be to the write the FXML for the GUI (if they're gunning for "skinnability"), and put into place their planned map system and plug-in architecture.

As for Java's JS, I believe it's not Rhino anymore, but Nashorn, a JS engine built from scratch which is showing great promise. I've written some stuff with JavaFX, but haven't gone all in, with the impending JavaFX 8 release, and all. There are already marked differences, and I'd hate to educate myself on something that might not carry over.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.4

Post by wolph42 »

KaylaKaze wrote:it's been my experience that that's more trouble than it's worth. Open source developers tend to be slow and unreliable and you're generally better off doing it yourself.
I have to disagree. I have a framework in development within maptools (warhammer) and I've opened the development for this framework for everyone interested. Basically the projectdocument is in oneNote and the file is available through dropbox. I've created some basic rules for when someone submits change in the framework and thats it.

Now over the years I think roughly 7 people have contributed to the framework and its true, they come and go aren't always reliable, but as they all worked on specific projects that were either additional tools which could be added unsupervised, or dug into the core code, which always went under my supervision.

my point is: you are partially right that a lot 'open source developers' are unreliable over a longer period of time. However they are IMO reliable to deliver one boxed in piece of code (e.g. a tool/plugin/specific enhancement etc.).
Also, you can get lucky (like I did) and meet someone who comes in for the long haul and I have to say its bloody awesome to have someone next to you to whom you can bounce off ideas and who takes responsibility for a large chuck of the framework of which I hardly know the details. (the framework supports multiple systems and he is responsible for the later systems).
Anyway if someone enters this forum and has either ideas for the framework, or wants to develop one of his own, I always invite them to join the party and maybe they don't join or only for a week or a month, but they usually contribute something and sometimes stick longer. I see it as a win-win.

You do however thus need one active core developer that supervises the project. In maptools case this is currently Azhrei, save the fact that 'active' is currently not applicable (at least not for MT, I don't doubt he's very active in different areas).
Apparently Lee is the supervisor for his branch.
Cause it *is* important that certain parts of the code are closely supervised for consistency, comments, style and compatibility with the rest. I guess for this reason the decision was taken years ago to change this 'organic growth' into a core system with plug-ins. Unfortunately it doesn't look like this will ever come to pass...

KaylaKaze
Cave Troll
Posts: 57
Joined: Mon Jun 18, 2007 1:08 pm
Contact:

Re: MapTool 1.4

Post by KaylaKaze »

wolph42 wrote:
KaylaKaze wrote:it's been my experience that that's more trouble than it's worth. Open source developers tend to be slow and unreliable and you're generally better off doing it yourself.
I have to disagree. I have a framework in development within maptools (warhammer) and I've opened the development for this framework for everyone interested. Basically the projectdocument is in oneNote and the file is available through dropbox. I've created some basic rules for when someone submits change in the framework and thats it.

Now over the years I think roughly 7 people have contributed to the framework and its true, they come and go aren't always reliable, but as they all worked on specific projects that were either additional tools which could be added unsupervised, or dug into the core code, which always went under my supervision.

my point is: you are partially right that a lot 'open source developers' are unreliable over a longer period of time. However they are IMO reliable to deliver one boxed in piece of code (e.g. a tool/plugin/specific enhancement etc.).
Also, you can get lucky (like I did) and meet someone who comes in for the long haul and I have to say its bloody awesome to have someone next to you to whom you can bounce off ideas and who takes responsibility for a large chuck of the framework of which I hardly know the details. (the framework supports multiple systems and he is responsible for the later systems).
Anyway if someone enters this forum and has either ideas for the framework, or wants to develop one of his own, I always invite them to join the party and maybe they don't join or only for a week or a month, but they usually contribute something and sometimes stick longer. I see it as a win-win.

You do however thus need one active core developer that supervises the project. In maptools case this is currently Azhrei, save the fact that 'active' is currently not applicable (at least not for MT, I don't doubt he's very active in different areas).
Apparently Lee is the supervisor for his branch.
Cause it *is* important that certain parts of the code are closely supervised for consistency, comments, style and compatibility with the rest. I guess for this reason the decision was taken years ago to change this 'organic growth' into a core system with plug-ins. Unfortunately it doesn't look like this will ever come to pass...
Yeah, when you're dealing with people submitting patches, updates, and new features, then that's fine. But what you're talking about isn't building a team or getting multiple devs working together to build a product, but the release of a product and then allowing those with the ability to update it. It's the difference between core Minecraft and the Minecraft mod scene. Core Minecraft takes forever to get anything done and when they do, it's usually stupid stuff no one cares about, while the modders are constantly adding new and exciting things.

I agree that one person needs to be in charge of the supervision. I have no problem contributing to the Lee branch instead of going on my own branch, but frankly, until I see something put out, I don't put any more faith in that than I do in 1.4/2.0 getting released. Vapor is vapor. I don't mean that as an insult, but people always like to talk and never put up. "We're waiting to complete feature XYZ." No. You make a change, you put it out. That shows you're serious. I don't know what the status on the Lee branch is since it's not in his sig and I don't know how to find discussion on it, but from what I've read here, it's been "in development" for a while and nothing's been released.

Is your framework for Warhammer war gaming or Warhammer RPG? We used too play Warhammer Fantasy war game over MT, and I developed a few macros to make it easier, including one that allows movement and proper rotation of a group unit (I think that one is in the forums somewhere if you need one).
Lee wrote:Since they went the route of exposing HTML3 through Swing in 1.3, and that they had to write macro script from scratch to support this and other needs, I speculate that RPTools' devs would now prefer a single "engine" to handle interpreting game scripts, and rendering the HTML that will be everywhere in 2.0, without having to rely on anything outside the standard kit. Also as of 2.0, the JavaFX API has a bridge for 2-way access, where Java can run JS within it's controls, and JS can call Java internals. With that convenience in place, it might be hard for devs to look beyond this for alternatives.

All they need to do after would be to the write the FXML for the GUI (if they're gunning for "skinnability"), and put into place their planned map system and plug-in architecture.

As for Java's JS, I believe it's not Rhino anymore, but Nashorn, a JS engine built from scratch which is showing great promise. I've written some stuff with JavaFX, but haven't gone all in, with the impending JavaFX 8 release, and all. There are already marked differences, and I'd hate to educate myself on something that might not carry over.
Like I said, I'm a web dev, not a java dev (it's been a few years since I used it) so I'm not familiar with all the recent goings on in the APIs. When discussing enhancing the current 1.3 version though, any mention of what "they" were planning in 1.4/2.0 or their reasoning for it is moot, unless you're overhauling the core system to use the new APIs in the way you describe.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: MapTool 1.4

Post by JamzTheMan »

Lee wrote:I've written some stuff with JavaFX, but haven't gone all in, with the impending JavaFX 8 release, and all. There are already marked differences, and I'd hate to educate myself on something that might not carry over.
Ya, I've been reading up on some of the JavaFX 8 stuff. Having done some Android development, the UI xml is starting to look very similiar. I heard that JFX8 "may" support android at some level. It would be nice if the UI would translate a little easier. Although I've always been in the mind set that MT for Android would really just need the "Map" and maybe just "PC" view and maybe ability to kick off macros (that the server runs?). The asset manager and such wouldn't be needed at first.


ANYhoo, I ramble. :) Lee, will you eventually open up to new developers or always remain a closed system? (Neither is bad/good btw, just curious). I always figured, I'll continue developing in 1.3 until the next big thing is released and then switch over, just seems like we now have a LOT of movement/developers wanting to develop but no core open source team to work with. :( I agree with a lot of what Full Bleed has commented on.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

KaylaKaze wrote:...I have no problem contributing to the Lee branch instead of going on my own branch, but frankly, until I see something put out, I don't put any more faith in that than I do in 1.4/2.0 getting released. Vapor is vapor. I don't mean that as an insult, but people always like to talk and never put up. "We're waiting to complete feature XYZ." No. You make a change, you put it out. That shows you're serious. I don't know what the status on the Lee branch is since it's not in his sig and I don't know how to find discussion on it, but from what I've read here, it's been "in development" for a while and nothing's been released.
:lol: None taken. But a quick search would yield all my "contributions" so far, and I think if you search posts from a name, it'll pull everything up. I wouldn't say it's vapor; maybe sleet ;)

You'll also see a part of my delay in "putting it out"; I wanted to see the final version of 1.3 put out, let the community enjoy it for a while, and come in with my stuff. I said so numerous times. I think I've honored that promise I made enough to just go ahead with my vision of I'd like things to be.

You'll also see demos I've recently put up. All of which are fully functional, and (hopefully) bug-free. I don't put out buggy crap just to show off. Throughout the waiting period, I tried reaching out to well-known contributors to flesh out my proofs, as what better use-case than something from a user? Not everyone was willing to help.

I know it's on me to provide proof, but to be honest, on the developer side, some energy must come from the community as well, else it just saps the will to be open about what is being worked on. I am pretty sure the others that are doing a fork right will eventually feel what I just described.

I AM grateful for those that helped, however, and, well, let's see what the future brings.

@Jamz: Your post came in as I was submitting :lol:

While Oracle open-sourced JavaFX, and a lot of exciting developments have happened since then (mostly from the community who wants this to go wild on mobile), it'd be nice to commit on Android if Java 8+ and Dalvik officially play nice together, without the hoops needed to make things work.

I want to keep mum about what my team and I are planning about the map system, at least for a short while. But your description of how it's going to work is very close to hitting the nail on the head :)

Our work will ideally be open, hopefully be 1.4, and have parts made well enough to add to 2.0, as I've always said I wanted it to be. With the rise of other forks, I reserve it for RPTools to make that choice. I never claim to be the best option, only that I am doing my best on my end :)

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: MapTool 1.4

Post by JamzTheMan »

Cool beans. Based on your other work, I kinda figured and could guess where you would take some things ;) Let me know when you are ready for some "contributions".

PS I'll be releasing a new Nerps Jar hopefully soon(tm). I've been doing some hacking and have my own spin on some things that people all seem to be working on. It's taking longer than normal to nail out UI design as what you "think works" and how you "use it" during game play sometimes are different. Feel free to use for inspiration if needed...

And +1 on the whole "community support" thing. I know exactly how you feel. If it wasn't for Wolf, the VBL code would never be where it's at. Even it's just bug reports or reports of no bugs, you need some feedback. Nothing kills your will to code quicker than community silence, or worse, naysay.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

KaylaKaze
Cave Troll
Posts: 57
Joined: Mon Jun 18, 2007 1:08 pm
Contact:

Re: MapTool 1.4

Post by KaylaKaze »

Lee wrote:
:lol: None taken. But a quick search would yield all my "contributions" so far, and I think if you search posts from a name, it'll pull everything up. I wouldn't say it's vapor; maybe sleet ;)

You'll also see a part of my delay in "putting it out"; I wanted to see the final version of 1.3 put out, let the community enjoy it for a while, and come in with my stuff. I said so numerous times. I think I've honored that promise I made enough to just go ahead with my vision of I'd like things to be.

You'll also see demos I've recently put up. All of which are fully functional, and (hopefully) bug-free. I don't put out buggy crap just to show off. Throughout the waiting period, I tried reaching out to well-known contributors to flesh out my proofs, as what better use-case than something from a user? Not everyone was willing to help.

I know it's on me to provide proof, but to be honest, on the developer side, some energy must come from the community as well, else it just saps the will to be open about what is being worked on. I am pretty sure the others that are doing a fork right will eventually feel what I just described.

I AM grateful for those that helped, however, and, well, let's see what the future brings.
I know what you mean about the community. Years ago I made an MT framework to play Warmachine/Hordes and absolutely no one ever used it. Yet there are still a good number of people playing Warmachine online using a different software which is vastly inferior.

As for your posts, I'm not sure what to search for. You have over 800 posts so sifting through that would be a pain. :-P

So, since you've presumably been neck deep in the MT code recently and I haven't touched it much since 2007 or so (sadly, it hasn't really changed much since then), what are your thoughts on the difficulty of some of the features I threw out, primarily SQLite3 DB access (like an "executeQuery(db filename, query string)" command) and IRC based "Community" tab? I also had a couple of others I just recently thought of that are seemingly just minor things: loading macro code/HTML from a file (like an "include" to a macro), and making it so you don't select a token if you click on a transparent section of its image?

Post Reply

Return to “Developer Notes”