RPTools.net

Discussion and Support

Skip to content

It is currently Tue Dec 12, 2017 9:00 am 






Reply to topic  [ 102 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

Previous topic | Next topic 

  Print view

Author Message
User avatar  Offline
Great Wyrm
 
Joined: Mon Sep 15, 2008 8:27 am
Posts: 1183
Location: Bristol, UK
 Post subject: Re: MapTool: Refined
PostPosted: Fri Apr 26, 2013 5:50 am 
JamzTheMan wrote:
I would have to say, the #1 reason we use it every week is because of the dynamic lighting, FoW/VBL. You just can't emulate that with a marker and mini's.


For my group it similar, we needed something to provide the online connectivity, mine is a pure skype group. We tried a few different options, include HP Rooms! But the reason we have stuck with Maptool is the dynamic vision and the frameworks.


Top
 Profile  
 
 Offline
Cave Troll
 
Joined: Sun Oct 24, 2010 3:44 pm
Posts: 38
 Post subject: Re: MapTool: Refined
PostPosted: Fri Apr 26, 2013 1:31 pm 
Background info: our group uses MapTools every week for our gaming session. We started this primarily because we all live in different parts of the country, and wanted to continue our pen and paper RPG campaigns. However the last time we all got together for a face to face session, we ended up networking all our laptops and gaming using MapTools, because we preferred it to straight pen and paper! We are big fans of the software.

I am generally positive toward the idea of a KickStarter for MapTools.

If Lee wants to do it his way, then I would support that. I definitely feel there is room to improve the current 1.x line of MapTools. I would go so far as to say that there is still a fair amount of low hanging fruit to improve upon in the form of improving dialogs and workflows. Not things that don’t work, but things that could be improved. MapTools: Refined is a great concept to express that.

I understand that there is a relative scarcity of developer time for the project’s 2.x next version. (I would support a second KS campaign in that area as well.) I understand how people would like him to be working on a 2.x version instead of going down what some people will see as a dead end path. I don’t see a dead end path, I only see a great thing becoming greater.

_________________
OSRIC Framework (1st ed AD&D)


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Sun Aug 27, 2006 8:19 pm
Posts: 1164
Location: Atlanta
 Post subject: Re: MapTool: Refined
PostPosted: Fri Apr 26, 2013 3:40 pm 
Hey, guys. What's going on in this thread?
/waves at familiar faces
Been a while and just recently started lurking again a couple days back.

For my 2 sheckles; I think the best route would be to push resources to MT 2. As much as the current version is awesome, because it is, and as much as it sucks that development has come to a screeching halt, because it has, I really think the community and the technology would be better served moving towards a more advanced MapTool.

2.0 needs some steam behind it to get moving. Momentum is the thing that has been lost currently and if we are to try and regain it, doing so on the next version is where it's really needed. More work on 1.X is not a bad thing, but IIRC there are certain bottlenecks of performance that more coding will only do so much for (extensive macros and VBL, for instance). We really need the next step in development to start sooner rather than later.

_________________
I cast firecube! ~4E


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Sep 11, 2007 6:31 pm
Posts: 5412
 Post subject: Re: MapTool: Refined
PostPosted: Fri Apr 26, 2013 4:22 pm 
Jector wrote:
much as it sucks that development has come to a screeching halt, because it has,
Not true...Craig worked fairly hard for 3-5 months straight on the new parser which is a decent part of what it will take to power MT 2.0. He has also been doing few other proof of concepts recently. Neither of those are shiny new things that an end user can look at, play with, and say "ah.. I see things moving along", but they are in fact happening(just behind the scenes.)

Jector wrote:

2.0 needs some steam behind it to get moving.
As stated above, it's got some, it's just invisible steam... :mrgreen:

Jector wrote:

More work on 1.X is not a bad thing, but IIRC there are certain bottlenecks of performance that more coding will only do so much for (extensive macros and VBL, for instance). We really need the next step in development to start sooner rather than later.


Thanks, that's exactly my point in not wanting any more work on 1.3/1.4. As a matter of fact, Azhrei and I were talking and he related an antidote that when along the lines of(the below is just paraphrasing!!!!!:

Quote:
Azhrei: for the next version, let's take X, copy to the MT 2.0 code and then tweak
Craig: No, that code's really so hard to deal with, it' would be faster and better built if we just scrap what's there and built it from scratch.


Now, IF there were just one thing in 1.3 that needed a re-write, it would be much easier to stomach continuing along with the 1.3 code if changing that one thing was part of the proposed 1.4. But the problem is that there are SO many things that really need an overhaul. Don't get me wrong, in NO way am I trying to demean Trevor's or anyone else's coding skill!!!! It's more a matter of 1.3 growing organically instead of in a planned way and sometimes when you get near your destination you realize you took the REALLY long way around(and it shows in how the code is structured.)

_________________
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Sun Aug 27, 2006 8:19 pm
Posts: 1164
Location: Atlanta
 Post subject: Re: MapTool: Refined
PostPosted: Fri Apr 26, 2013 4:49 pm 
Well, good to hear there's much more than appears going on behind 2.0. I'd still prefer more pushed towards that than behind 1.4, if it's possible.

Lee must make his own decisions, naturally, and for whatever reasons work best for him. If he really has no desire to mess with 2.0, it may be better to get his wholehearted concentration on 1.4 than meh effort on 2.0.

_________________
I cast firecube! ~4E


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Tue Aug 23, 2011 10:41 am
Posts: 1134
Location: Cornwall, UK
 Post subject: Re: MapTool: Refined
PostPosted: Sun Apr 28, 2013 12:50 am 
jfrazierjr wrote:
As stated above, it's got some, it's just invisible steam... :mrgreen:


Steam is always invisible, because it's a gas. What you see when water boils is water vapour. :roll:

On topic: I, like most here, do not give up "hope" on MapTool because 1) It's a very working product and therefore deserving of our patience and 2) being re-energised by the community along with updates from developers.

Regardless of how the program is progressed, and who does the developing, there's been some good ideas and opinions in here about potential avenues. At the end of the day we all want to make MapTool the best program it can be, so we can enjoy using it more, and to spread our fanaticism to include as many other users as possible. It all comes down to simple product development and marketing.

Who is the product for?
What do they want from it?
What are the key features which sell our products to existing/new consumers?
And the age old twins:
How much time/money will it cost?
How much time/money do we have available?

Kickstarter is good for funding money, but only when there is a very clear goal, a feature list dripping in desired elements that expands the scope of potential consumers or heightens the quality of the existing product for the existing consumers. Kickstarter is for selling dreams, but there is one thing that it cannot do, unless MapTool gets so much money it can hire developer(s) which I highly doubt, which is generate time for the developer(s) to work on MapTool.

I'm sure someone who's actually studied this field would help more - I'm just applying logic here.

_________________
How to get around the two code nest limit in MapTool (and MOTE)


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Wed Nov 15, 2006 9:03 am
Posts: 1023
 Post subject: Re: MapTool: Refined
PostPosted: Sat May 25, 2013 10:31 am 
So yea, I've been gone while, as I've said else where. I would have to say I'm against a funded fork. If Lee wants to be brought into the 2.0 team, great let him in. I had done some VERY minor work, with both Trevor and Az for some bug fixes, trying to get my feet wet with some stuff. But I'm a hobbyist coder, at best, when it happens. Like a lot of people, I'm anxious to see what 2.0 brings, but I really think that 21 degree freeze needs to meet a good Nor' easter and snap down into the negatives and get a good, solid, freeze on it, outside of any connectivity issues.


Top
 Profile  
 
 Offline
Dragon
 
Joined: Wed Oct 19, 2011 1:07 am
Posts: 958
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 2:11 am 
Hello everyone,

I apologize for coming back to this thread only now, I did promise here and elsewhere that I did not want to take the community's focus away from finalizing 1.3 by stoking this discussion with my input. Honestly, I kept myself from reading anything beyond my last post. Believe me, it was hard to do because I know everyone here deserves answers and replies, even if only to acknowledge the time spent on making a post. With b90 in the horizon, I'll try to make up for it now.

I must say that the content I missed out on all these months is amazing. I appreciate that so many have taken time out of their day to give intelligent and well thought out responses to the seed of thought I flung out in the OP. Thank you kindly everyone.

My apologies in advance for multi-posting. I thought it'd be best to do it this way so as not to create a juggernaut of a post as I reply to stuff that jump out at me as I resume reading this thread.

First off:

Azhrei wrote:
Third, we want to reiterate a few of our core beliefs:

Open source software projects are the One True Way™.


I couldn't agree more. I'll take the opportunity to reiterate that the end result will indeed be open-sourced.

Azhrei wrote:
Contributors to open source projects have a responsibility to work within the system, so to speak. ...but bug fixes should be reported back to the project in a timely manner so they can be incorporated into the master branch of code. This keeps the core code up to date so that other forks will be able to incorporate those bug fixes.


I fully support this and commit to doing so.

Azhrei wrote:
We recognize that we each stand on the shoulders of giants in regards to the code that already exists. That code may not be deemed perfect by any given member of the team, but we also recognize the practical aspects of not attempting to reinvent the wheel. We try to express our vision for unity within the software project in a way that doesn't step on the author's toes, but when we are the author we accept constructive criticism and try to mold our way of thinking so that the ideas of others can be incorporated where practical. And we accept that we're not experts on all facets of software development! Some team members will likely have more object-oriented background, others will be better at graphical design, and some have a knack for administrative/managerial tasks. We are each a part of "the whole" and the sum of those parts is greater than the whole.


I accede to this ideal. The only reason the source is closed during development is to set things up in a more manageable way architecturally (at least for me). If the suggestion made about me taking up the reins and maintain 1.4 officially, happens, I would like to push the sled up the hill and set it up just right for the ride. As JFJ mentioned on a later post, things got pretty organic with regard to development; this will likely still be unavoidable once 1.4 is open-sourced, but hopefully some method can be injected into the "mayhem".

Also, in the spirit of this ideal, I definitely will need to tap others in the community to make this a success, and open up my ideas to criticism with the goal of achieving a better MapTool.

Azhrei wrote:
We want to be inclusive. This is similar to the last point. If someone sees a need for something and wants to contribute, we will try to support their contribution as best we can. That means helping someone who wants to write a new series of wiki pages, build user documentation, design new artwork, or create tutorial videos for new users…


I think the greatest thing I want to achieve with this is spur the community to evident action. I say evident because, while a lot of stuff is happening, it's like a deep river, no one can't see what's going unless one takes a plunge. These forums are great, but I think we can do better. A great point made by Bone White downstream was that MapTool should empower framework developers (and other creators), who in turn will grow the community by attracting people to their creations. That's a great paradigm to design toward, IMHO.

Azhrei wrote:
...we would prefer that bug fixes get filtered back to the master branch on a timely basis so they can be incorporated into new builds and into the work done by other contributors.


Of course. I always do my best to help in this regard as evidenced by my contributions so far (though not always perfectly at times :oops:), and will continue to do so moving forward.

Azhrei wrote:
We would prefer to have Lee working on 2.0. It seems like a logical choice to us. But if that's not to be...


I firmly believe that a lot of the work I plan to do or have done on 1.3 also adds to what will come out in 2.0. This was a conscious design decision I made early on because, before I even started, I read through most of the threads under General Discussion, Feature Requests, MapTool etc. regarding 2.0. For example, the sound functionality is API-ready, anyone can just take it out of MT and drop it into any project and call it from there. Same is true for most, if not all, the things on the list.

Azhrei wrote:
...take the existing code and call it done with 1.3b90, then put Lee in charge of 1.4 and the existing SourceForge.net Subversion repository. Craig and I, and anyone else with an interest, will then spend most of our time working on 2.0. We will rename the existing MapTool forum to "MapTool 1.x" and create a new forum for MapTool 2.x. We would ask Lee to keep the repository up to date; instead of posting test JARs to the forum, we'd rather have a new build come out. In the past, the decision about when to produce a build has been mine. I typically wait until a few bug fixes have accumulated, a new translation is added, or some major issue is discovered and resolved. That decision would now be up to Lee. Since he's already implemented a bunch of things, I expect that 1.4b01 would incorporate that work and while the community is trying out those features he can be working on the next one.


I was deeply honored when you offered me the reins. I hope you understood my response as "Yes, I am willing, but only when everything's ready on my end.", and not a "No". The expectation of 1.4b01 is to the point. If the project is to be divided into phases with phase 1 accomplishing what was initially listed and stretch goals getting pushed out in phases after, then indeed users will get the accomplished copy after phase 1 and I will then proceed to phase 2.

Azhrei wrote:
Lee has indicated a reluctance to regularly commit his code to a public repository in what he considers an "unfinished state", so we are offering to set up a private location. Intermediate updates can happen there and if he should, heaven forbid, get hit by a truck his progress to that point won't be lost. We see this as a common sense approach to ensuring that his time doesn't end up wasted.


:lol: Let me catch up on Git. It's been a while since I last used it, a looooooooooooong while. In the meantime, to allay concerns regarding my untimely demise should it (heaven forbid) occur, all sources are regularly backed up in real-time in 2 cloud locations, and 2 local ones. In the event of my inability to continue, associates/friends in my dev team (info: they're not working on MT), will make the source readily available here (specifically to RPTools).

Azhrei wrote:
The RPTools team would need to agree to the wording to ensure all the required disclaimers are in place and promises are not unintentionally made on our behalf. There needs to be clarity as to what the benefits will be before the funding campaign starts. This includes any stretch goals or pledge rewards.


I do appreciate the help on this and will be guided accordingly.

Azhrei wrote:
...I believe (and this is Azhrei, not the team) that most companies shy away from this approach for two primary reasons: (a) adding features to an existing product eats into the profit-making potential of the next version, and (b) when v1 has all the features that v2 has why upgrade? We don't need to worry about the first one, but the second one is a concern.


It is a concern of mine as well. I can't give any specifics right now since they're just a lot of concepts in my head, but if the goal of 1.4 is to provide new features of the transparent kind to the end-user, features that will likely find itself in 2.0, then can't it be seen as an evolutionary step toward 2.0? Or, put in another way, if 1.4 is made great, won't stating that 2.0 has all great and relevant stuff (sorry maptoolscript) and more, "sell" it even better?

Azhrei wrote:
As maintainer of the 1.4 series, we hope Lee would coordinate changes with the rest of the team, at least in terms of "here's what I want to do -- any comments?" With the right amount of up front communication perhaps some of the features will be isolated to a degree that will allow them to be integrated into 2.0 without redoing too much work.


I will certainly do this. After all, I humbly do think I still have a lot to learn that all of you already know. I also do not think that what I bring to the table are skills and expertise because you guys have that in spades; I'm just persistent and tenacious when I have a bone to chew and I learn really quick. Of course, I do want this to succeed.

Thanks, Azhrei, and the rest of the core team, for weighing in on this and saying it clear :)

_________________
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in


Top
 Profile  
 
User avatar  Offline
Dragon
 
Joined: Wed Aug 31, 2011 8:49 pm
Posts: 495
Location: Somewhere between Heaven and Hell
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 4:25 am 
As far as heavy opinions go, mine isn't - I'm pretty much just a regular user of the most innovative VTT there is; innovative in that I have designed, from scratch, a framework for every game mechanic we use - and I can tell you, there are a ton. I've never used any other VTT, because the customization is absolutely atrocious by comparison to the things my groups need/like to do.

That being said 'the devil is in the details' comes to mind. Would I support a product that gave free reign to profiteers to advertise with no governing criteria? Not a chance. This is referring to allowing contributors to have 'buy my stuff' banners left and right, or an 'online shop' akin to roll20. I love this notion, but without strict regulation of what a 'free sample' is and other gimmicky catch phrases to draw you to a product, I couldn't possibly support this effort. As a disclaimer, this is not implying any one site as bad or 'doing it wrong' or even an assumption anyone here would, but you know they exist, and I'm sure you can name a few yourself.

However, assuming the criteria was intelligently laid out - assuming the 'sleeze' was removed from contribution-purchasing, I'd back this idea in a kickstarter in a heartbeat. Hell, I've spent way too much money on Kickstarters this year alone (Numenera, Torment, Divinity Original Sin) to name a few, and a product as incredibly player-controlled as MT would have my support immediately.

Lee, as far as personally, I only know you're helpful - very helpful, but most everyone here is. I've seen some of your submissions, and they are rather brilliant - so as far as all that is concerned, having you behind the reins is definitely a positive for whether or not my money would be contributed.

Overall, as the initial point dictates, its all in the details. I think its a fantastic idea, at least in theory.

_________________
"An arrogant person considers himself perfect. This is the chief harm of arrogance. It interferes with a person's main task in life - becoming a better person." - Leo Tolstoy

Image


Top
 Profile  
 
 Offline
Dragon
 
Joined: Wed Oct 19, 2011 1:07 am
Posts: 958
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 5:15 am 
Thank you Xaelvaen. I appreciate what you've said. I'm backtracking and making replies moving forward so I'll get to you once I crest over this wave :lol:

paulstrait wrote:
How much money are we talking about here?


I know this question has been the biggest elephant in the room as far as this thread's life goes. My desires are simple: I've been on the proverbial road too much over the past few years and want to spend some time with my folks. My mom just crossed retirement age and my dad's getting a little long in the tooth. When I stopped for a moment a year or so back and thought about it, while I know them very well, I know next to nothing about their lives up to the point when they had me. I want to take time out and rectify that while I still can, and at the same time, work on something I enjoy so it does not feel like "work". I believe most everyone goes through this kind of phase and I guess the time has come for me. Hence, this offer was made.

Since I've painted a target on Roll20, I was thinking of starting on the same modest(?) amount they did for their work (was it $2k or $3k?). This will be used over a period of 3-5 months to attain the primary goals stated. Yes, I definitely earn a lot more in my day job, but again, this allows me the free time I need to do what I plan to do.

I'll commit in writing if needed that any excess will either be turned over to RPTools for them to hold and dispense as they fit, or be used to fund stretch goals if desire for these is supported by the community; though I was also thinking that part of the fund can be diverted toward providing incentives to resource creators for all that they provide to the community (if they are welcome to the idea of receiving donations for their work. Some people don't, as everyone well knows). I also have nothing against putting RPTools as the recipient of the funding and have it dispense to me what I need. It has to be said that, like what others have mentioned in this thread, I may end up tarnishing RPTools reputation if I fail, so a level of disassociation needs to be in place until such time this can be considered a success. Making RPTools the recipient at the onset would complicate this disassociation. What do you think?

Furthermore, regardless of who ends up with the excess, if any, I think it would be great to use some of the fund to get services that may help expand MapTool's (RPTools in general) reach and influence. Dracones posted further down this thread on an idea similar to one of my own stretch goals: hosting headless instances of MapTool over a cloud engine like Amazon EC2. As I've mentioned before, we now have headless capabilities, the 2nd part of the idea I'll leave to the community to mull over. Certainly, keeping in the RPTools' spirit, the ideal would be to offer a free service, propped up by funds from this endeavor, donations or whatnot, where GMs send over their campaign details and players just connect to the readied server instance. This can effectively headshot UPnP issues at the very least, and other connectivity issues as well. Of course, once this gets released to the wild, some enterprising individuals would go against the ideal and create a subscription service. IDK how everyone feels about that; certainly something worth discussing.

I subscribe to the idea that, if done right, doing this will help this community greatly and further the reach of the spirit that RPTools was founded on. I know fully well I cannot do it alone, so I hope that as things become more tangible, support for this will also gather similar momentum.

Well, that's all I can say about the initial funding goal. Of course, do let me know if you think it's excessive, or (gasp) it's not enough :lol:

_________________
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Tue Aug 23, 2011 10:41 am
Posts: 1134
Location: Cornwall, UK
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 5:37 am 
Lee, when you are ready to sit down and plan out what you're doing, and how long you estimate it will take you to complete these things, then you can come up with your estimate and a definitive list of features and expectations. Only you will know when you're ready for that. Perhaps because I am unemployed and bleeding savings out of my tear ducts, I'm not so interested in funding goals because I know I won't be able to contribute much if anything.

_________________
How to get around the two code nest limit in MapTool (and MOTE)


Top
 Profile  
 
 Offline
Dragon
 
Joined: Wed Oct 19, 2011 1:07 am
Posts: 958
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 5:45 am 
aliasmask wrote:
...If there is to be a new branch we should treat it as a completely separate product and not try to incorporate new features or bug fixes in to the current line and focus on 2.0 development. It doesn't satisfy the "I want it now" people, but that's what you get with an open source project. Now if we see features in 1.4 branch nothing says we can't incorporate those in to 2.0, but it wouldn't be a cut/paste job because the processes will likely be very different. That means it'll have to be developed twice.


Thanks A.M. I've always valued your input since I've joined this community and having your opinion on this is much appreciated. This has been mentioned a lot of times in this thread and I do understand the concerns regarding putting all efforts instead into developing 2.0. I have to say again that I'm tackling this prioritizing goals that are "hybrid" in nature over ones that are only for 1.3. Like I mentioned earlier, an example would be the sound API being usable anywhere. Another would be evaluating and implementing tech tackling some of the problems you mentioned (i.e. json speeds, json functionality in general, rendering issues etc.). Since Javascript is the planned language for developing frameworks, doing the JSON overhaul now makes more sense. Also, the script editor is being made to be Javascript ready; yet another 1.4 goal that helps 2.0 development out. Alternate methods of storing and disseminating data over the current token <-> asset management system are also in the works. I think Craig mentioned that a consolidated data source is desired for 2.0; we can test it now in 1.3 by including tables and SQL functionality, disseminating processed data either over TCP/IP or sending over components instead and having clients do the computational lift. The current design on the board is to toggle DB management between these 2 approaches.

Anyway, doing such work now on a completed platform would yield better results than waiting for 2.0 to come out. Behavioral features and a more intuitive interface studies using 1.3 can collate enough knowledge on how to do it right in 2.0.

aliasmask wrote:
...The thing about pay projects is that there will be a requirement for a professional look along with some bells and whistles to justify forking some money out. Something they can point at and say "Ooh, shiny." to make them say it's worth paying for beyond what is already available. What will be that Ooh-shiny piece of development that will hook the kickstarters for either 1.4 or 2.0?


With regard to interface, I have big plans for it after achieving the 1st phase of this effort. Indeed, the shiny bits are important for this to get traction; my opinion on this is to provide transparency on a work in progress. Not everything will be shiny at the start, but people will definitely feel the momentum, and this, I think, is more important.

_________________
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in


Top
 Profile  
 
 Offline
Dragon
 
Joined: Wed Oct 19, 2011 1:07 am
Posts: 958
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 5:58 am 
Bone White wrote:
Lee, when you are ready to sit down and plan out what you're doing, and how long you estimate it will take you to complete these things, then you can come up with your estimate and a definitive list of features and expectations. Only you will know when you're ready for that. Perhaps because I am unemployed and bleeding savings out of my tear ducts, I'm not so interested in funding goals because I know I won't be able to contribute much if anything.


Good points, B.W. In the event of a KickStarter, one of the mandated points is to have a project that is at least 80% complete prior to being allowed to start anything at all. I'm either at that state or very close to it. The remaining 20% of the work are stuff I've chosen to do over the development period because they are labor intensive, but not functionally critical. Stuff like creating the source file for all of MapToolScript's functions which will be used for code completion and context help (that's a lot of writing), evaluating the look and feel for phase 1, how much control over the SQL engine should be transparent to a MT scripter, evaluating and implementing tech upgrades to outdated or over-stressed critical components such as the JSON and Geometric libraries, and a whole lot more.

The estimated time to complete phase 1 is 3-5 months. The earlier the better so the community can test, create and critique; after which, another phase can commence if desired. That I am posting on this thread again is sort of a signal that I'm putting things together to get things started.

As for your last remark, your help is invaluable in other ways. As a framework developer, and someone I share similar ideals with regarding a unified or directed approach to framework building geared toward attracting more users to MT, I think (if you are willing) that you will be a part of many a discussion regarding making this ideal real.


Thanks.

_________________
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in


Top
 Profile  
 
 Offline
Dragon
 
Joined: Wed Oct 19, 2011 1:07 am
Posts: 958
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 6:35 am 
I'm going to say this a lot as I go, but thanks for weighing in JFJ.

jfrazierjr wrote:
I have had a hard time coming up with a response for this topic. My first point is that like Rumble has mentioned, i believe 1.3 code to be evolutionally dead. There is so much wrong with it that it needs to be have a complete overhaul and hence why the core team decided to take this approach a number of years ago. IMHO, there is only a small amount of 1.3 code(let's just take a WAG and say 30%) that will end up making it's way into 2.0 in favor of re-rewriting it from the ground up.

...Like Azhrei, I would FAR prefer any effort Lee puts into MapTool come toward 2.0. I would also have no problem with a KickStarter being put into place specifically for 2.0 by the core team with the proceeds going to Lee to actually do much of the implementation while working with Craig/Azhrei for direction.


jfrazierjr wrote:
I have some very real concerns with Lee doing anything "MapTool" that might be out of scope for 2.0 and then the core team having to handle the discrepancies. For example, Lee notes wanting to put "sound" into his revision. However, that would then put pressure on the core team to do the same or people will feel as if they can't upgrade to 2.0 when it comes out without loosing functionality. It's not that I don't want sound put in, but more that Azhrei has noted some possible legal gray areas in the past with doing so. On the flip side, if Azhrei/Craig say it's all good, then that "problem" goes away.


I know that, without much proof for people to see, it's hard to back up my opinion that work I choose to do for 1.3 can find itself easily into 2.0. So, for the record, I will take time out this week to start on video proofs for at least some of the primary goals. RL's been toxic for the past few months, so while I did promise to furnish this early on, I couldn't find the time, sorry.

jfrazierjr wrote:
Likewise with adding Cling(an UPnP library) to MapTool's source code.... If Lee adds that in 1.4, it could be at odds with what the Core team was planning for 2.0(the Cling library is HUGE, and that is a concern)... Ditto a headless server....


With regard to Cling, I liked it because it's a modern library that now has lenient support for old .xml specifications that broke it when I ran a test build including Cling last year. Also, thinking forward, it'll likely be a top candidate for 2.0's UPnP library (if we're doing UPnP) if 2.0 wants to be Android-ready in the future. As for the headless server, you're right, it's a 1.3 only feature as 2.0 will likely figure this in at the onset of coding its GUI.

jfrazierjr wrote:
I would rather have one of three approaches:

  1. Lee takes the existing MT source code and completely separates it from the RPTools project and uses this as the foundation for his KickStarter. The project would not be named MapTool and have no affiliation with RPTools other than where the original source was pulled from. If Lee makes any of his code open sourced, at some future point some of that code might make it into MapTool 2.x just as with any open sourced code.
  2. RPTools does the KickStarter for MapTool 1.4 and works with Lee privately to set goals and "hires" Lee(possibly others??) to complete if the KS is funded.
  3. RPTools does the KickStarter for MapTool 2.0 and works with Lee privately to set goals and "hires" Lee(possibly others??) to complete if the KS is funded.

Of course, I would much rather have number 3 be the direction to take over number 1 or 2(my lease desirable outcome). My main point is that any new functionality Lee adds into an "Official MapTool" should be something that will be committed to for 2.0(regardless of if the code is re-used or re-built with a different approach.)


I'm fine with any of this, but wouldn't doing #2 or #3 effectively commit RPTools and make it all the things you, Azhrei, and Craig don't want to get paid to do? As for #1, while I would much prefer to return to the fold at the end of phase 1, if this is a safer route where I can do no harm to RPTools and its community, then I'm okay with it as well.

jfrazierjr wrote:
...However, the FOW update is a huge change to write time wise and if it's going to be done anyway, in my humble opinion, it would be made EASIER to start from scratch then retrofitting the existing MapTool code(in most cases.)

One thing non developers may not understand is that a good 20% of MapTool deals with FOW and the whole rendering. Imaging taking your arm off and sewing a new one onto it and that's the level of effort required to fix the brokenness of the current code. Again, as I noted above, there are some fairly large benefits to just building a new body vs taking the saw off and replace approach.


You're correct on this point, JFJ, especially when people take into consideration that you helped code a lot of its implementation, so no one knows more on this than you; but my personal feelings on this is, while you consider the system broken, you still a heck of a job in providing the RPG world with the vision effects, stuff not found anywhere else in the same working form. While you'd rather leave it as it is, I'd like to think if it can be fixed a little, it'd leave a better legacy than its "broken" appellation. Besides, we need to farm for ideas and tech for vision in 2.0, this is a good place as any, considering.

jfrazierjr wrote:
Then there is the UI stuff. At the end of the day, the UI NEEDS to be re-written in JavaFX instead of continuing along with Swing(the current Java UI library) and making some tweaks to it. One issue is that Swing has antiquated support for html/css which is 10+ years old, while JavaFx is (fairly) up to date on the the most recent html/css specifications, so things like skins would be far more possible with JavaFx that just can't be done in Swing.


While this is not a phase 1 goal, I plan to push for Swing <-> JavaFX interoperability within 1.3 with the goal that the JavaFX parts will eventually be components for review for 2.0. The reason it's not in phase 1 is because (for me) GUI overhauls can become intensive and time consuming while providing little functionality (in terms of the visual components). But, for example, within 1.3 is an html frame factory. I plan to create a similar factory generating frames using JavaFX, which would probably break the dam with regard to what MT users can create and style. IDK, if people want docking with it but it's certainly doable. But going back on topic, this is another example of work done for 1.4 helping 2.0 out :)

Edit: If I'm not mistaken, with JavaFX, encoding problems (e.g. UTF-8 in 1.3) and several localization aspects are taken care of out of the bat so this can be welcome news to users like booga.

_________________
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in


Top
 Profile  
 
 Offline
Dragon
 
Joined: Wed Oct 19, 2011 1:07 am
Posts: 958
 Post subject: Re: MapTool: Refined
PostPosted: Thu Aug 01, 2013 6:57 am 
@Rumble: I've read all your posts and appreciate the alternate perspectives they present. The thing I wanted to respond most to, which others have also brought up, was ease of use. It is actually the first thing I started working on last year as, much as I love MT, it lacked the kind of flow in usage that makes one feel things are seamless from point to point. Which is why it's on the priority list for phase 1 and a lot of work has already been put in toward this end.

Particularly important is up-front configuration dialogs for setting up MT initially, then a server initially or connecting to a server easily and the like. A more transparent system of acquiring assets, and in another phase, an update listener so users won't be burdened with updating. Even opening any framework for the first time will have generic assistance from the system itself to move things along. An example of this is character/token creation; a selection of art assets will be displayed and bindings to set campaign properties will happen once the GM finishes with the preferences. Of course, this implies that framework creators should have campaign properties set. In the absence of this, tokens will just be tokens; though an intelligent solution would be to ask for a lib:token or database location that houses token properties. This will need input from framework builders as standards need to be set to make this work.

A few months back, I tried asking if people were interested in discussing campaign generics, which essentially means extracting things that are common to most/all systems that can be supplied within the code itself. While the discussion didn't spark much interest, I think it should be revisited in the future.

_________________
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 102 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Who is online

In total there are 2 users online :: 0 registered, 0 hidden and 2 guests (based on users active over the past 5 minutes)
Most users ever online was 243 on Sun Nov 04, 2012 6:14 am

Users browsing this forum: No registered users and 2 guests





Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman