My MapTool Fork: Video Proofs of Concept 02-07-2013
Moderators: dorpond, trevor, Azhrei
Re: MapTool Fork: Video Proofs of Concept (finally)
Sorry for the delay. I had to re-upload as someone powercycled the #$@@#$!@# router!
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
- Bone White
- Great Wyrm
- Posts: 1124
- Joined: Tue Aug 23, 2011 11:41 am
- Location: Cornwall, UK
Re: MapTool Fork: Video Proofs of Concept (finally)
Thankyou for this Lee, we all know you're hard at work behind the scenes when you can, but a picture tells a thousand words and a video...
Re: MapTool Fork: Video Proofs of Concept (finally)
Thanks BW. I appreciate it
I don't have time right now to upload the 2nd video, as I'm leaving on a trip that will take me away from anything digital for the rest of the day.
I've added the database video to the OP, however, and I hope you guys like it
Edit: BTW, please read my description on Youtube about the newest video. It will explain a lot!
I don't have time right now to upload the 2nd video, as I'm leaving on a trip that will take me away from anything digital for the rest of the day.
I've added the database video to the OP, however, and I hope you guys like it
Edit: BTW, please read my description on Youtube about the newest video. It will explain a lot!
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Again, great job on the SQL implementation. I really wish this had been around from the beginning! Great choice of music on that video, too.
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
.
||| Lee adds SQL to MapTool |||
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Well that sure as hell makes my latest table addition to the bag of tricks obsolete
Cool stuff!
So when r u going for a release?
Cool stuff!
So when r u going for a release?
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
Re: MapTool Fork: Video Proofs of Concept (finally)
This is real nice. Is there any propogation of the actual on disk sqlite file or is it all handled via the sql statements pushing to all the clients?Lee wrote:I've added the database video to the OP, however, and I hope you guys like it
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
@A.M. HAHAHA. I haven't seen Scanners since I was a kid. Good times.
@wolph Sorry about that. Did I mention that I have also completed manipulation functions for standard MapTool tables?
As for what you asked, very soon. I know I keep saying that, but if you saw everything on my end, most of the delays weren't completely mine. Right now, I have a green Launch button, but I'm waiting on other people so that we'll have the strongest possible package to survive the long haul.
We'll want to discuss the user structure for MT dbs in the future. We may have differing views but a good talk always spurs innovation
P.S. I'm too pooped to work on the 2nd video right now, and I'm about to hit the sack. I'll do it first thing when I get up.
@wolph Sorry about that. Did I mention that I have also completed manipulation functions for standard MapTool tables?
As for what you asked, very soon. I know I keep saying that, but if you saw everything on my end, most of the delays weren't completely mine. Right now, I have a green Launch button, but I'm waiting on other people so that we'll have the strongest possible package to survive the long haul.
Right now, the structure is:Dracones wrote: This is real nice. Is there any propogation of the actual on disk sqlite file or is it all handled via the sql statements pushing to all the clients?
- The application has an embedded SQL engine. The user db is H2, by the way. After doing reviews on several, similar engines, this one fits the bill for now. The connection string is dynamic anyway, so we can always load up the next front-runner w/o needing to change the code.
- Since MT is a client-server mish-mash, designers can opt to either have all clients access one database through server mode, or let each client keep a copy of game data using embedded mode.
- Information is pushed as with any macro command, albeit, designers won't need to do any fancy macrolink/macrolinktext magic. We did that for you, in that execution is done client-side.
We'll want to discuss the user structure for MT dbs in the future. We may have differing views but a good talk always spurs innovation
P.S. I'm too pooped to work on the 2nd video right now, and I'm about to hit the sack. I'll do it first thing when I get up.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool Fork: Video Proofs of Concept (finally)
Going to play the Devil's Advocate here...Lee wrote:I've added the database video to the OP, however, and I hope you guys like it
I take it that this will allow us to create more powerful/useful tables and db's to access data?
To be honest, as someone who's never used SQL it looks like a very "programmatic" approach (i.e. lots of json syntax and populating/pulling data with long strings of code.)
I guess I don't see a more programmatic MT as being an entirely positive direction. Are there simpler/better SQL DB editors out there that can be incorporated?
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
- CoveredInFish
- Demigod
- Posts: 3104
- Joined: Mon Jun 29, 2009 10:37 am
- Location: Germany
- Contact:
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
I agree that MT shouldnt get a coders only tool.
(But) with a database in place I bet you could easily create some "dumbed down" functions to use its basic features - you shouldnt have to learn SQL to look up random treasure. But having it all accessible is awesome if you want to do more complex stuff.
(But) with a database in place I bet you could easily create some "dumbed down" functions to use its basic features - you shouldnt have to learn SQL to look up random treasure. But having it all accessible is awesome if you want to do more complex stuff.
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Yes to the first part. The ideal is also to wean away from the current data storage (in-token) system, something we'll be chopping away at as we go. It'll not only be SQL, we're looking at others too.Full Bleed wrote: I take it that this will allow us to create more powerful/useful tables and db's to access data?
To be honest, as someone who's never used SQL it looks like a very "programmatic" approach (i.e. lots of json syntax and populating/pulling data with long strings of code.)
I guess I don't see a more programmatic MT as being an entirely positive direction. Are there simpler/better SQL DB editors out there that can be incorporated?
We're gunning for:
- A slimmed down token model. No more data riding on it that doesn't pertain to it's relation to a map, or any information that has references to the token (e.g. macros).
- Relations allow the actual information to be stored elsewhere and will exist on the token only as links/references.
- One instance of a token's model with a data map tracking where images of it is at on all maps/scenes.
- Updates to the token will then mean all token images will have reference to the newest information.
- etc.
Lastly, I predict several grand community projects spearheaded by the technically savvy to make definitive databases of their game system's data (e.g. spells, weapons, powers characters), and SQL will provide a standard (dare I say "universal"?) means of access to these. No more rewriting macros from scratch to access self-made data structures hosted on tokens. Yay.
I understand. I'm just keeping it real to the project's design ideal of "empowering designers, who in turn create great experiences for players."CoveredInFish wrote:I agree that MT shouldnt get a coders only tool.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
even if its quite 'cody' in its basis, users (like me) upto now always managed to create a more UI friendly interface. E.g. the new tables I created has an interface that is easily created and used (the processing was the real pain, but that's now taken care off). So I wouldn't worry too much about that.
I'm curious though. Your talking about moving the data from the tokens to a database and have user access that db instead of the token for info. So stuff like
- properties
- stored vision data
- location
right?
currently (IRC) when one thing on the token is changed (e.g. moved) the updated token is send to the server and the server sends the updated token to the remaining clients, right?
in your case? is the data again send to the server and then again distributed to the remaining clients (but now to local databases instead of tokens)? Or is the data is send to a central db, but how do the clients then'know' the changed location of the token?
Overal I gather that the big advantage is is that when e.g. the 'wounds' property of a tokens is changed, you no longer need to send the entire token with all its data over all clients, but just that piece of information?
Basically all of the above are questions/assumptions. Care to elaborate on them?
I'm curious though. Your talking about moving the data from the tokens to a database and have user access that db instead of the token for info. So stuff like
- properties
- stored vision data
- location
right?
currently (IRC) when one thing on the token is changed (e.g. moved) the updated token is send to the server and the server sends the updated token to the remaining clients, right?
in your case? is the data again send to the server and then again distributed to the remaining clients (but now to local databases instead of tokens)? Or is the data is send to a central db, but how do the clients then'know' the changed location of the token?
Overal I gather that the big advantage is is that when e.g. the 'wounds' property of a tokens is changed, you no longer need to send the entire token with all its data over all clients, but just that piece of information?
Basically all of the above are questions/assumptions. Care to elaborate on them?
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
@wolph Something similar, quite close. I will elaborate, but later. I got to run out for some personal stuff.
In the meantime, I've uploaded the play on the map system
In the meantime, I've uploaded the play on the map system
Last edited by Lee on Sat Feb 08, 2014 7:38 pm, edited 1 time in total.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
awesome!! i notice that you have the same issue i had when i started making vids: no voiceover. Get over it and add them!!Lee wrote:@wolph Something similar, quite close. I will elaborta, but later. I got to run out for some personal stuff.
In the meantime, I've uploaded the play on the map system
one question, the (forgot the name..isotropic??) not top view, is that something you can set or will this be default?i ask cause i still prefer the top down view. Also the fading fog, also cewl, but it might get annoying, so again, is this a setting or default?
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Oh the things I can accomplish if I had more time...We're thinking of redoing our videos as it the last one turned out so well with the right settings on Bandicam. I admit it's a character flaw, but I'm so much of a perfectionist at times that I keep scrapping stuff over the smallest of errors, and find out belatedly that I wasted the whole day over some thing as short as 2 minutes I'll try; that's about the best I can promise right now.wolph42 wrote: awesome!! i notice that you have the same issue i had when i started making vids: no voiceover. Get over it and add them!!
one question, the (forgot the name..isotropic??) not top view, is that something you can set or will this be default?i ask cause i still prefer the top down view. Also the fading fog, also cewl, but it might get annoying, so again, is this a setting or default?
As for your questions, it's a map generation option. I mentioned working with finite maps (but we're mulling putting an infinite map option in), so the work process will be:
- Choose map type (top down, isometric, etc) or import
- set dimensions (where applicable)
- tweak settings
- design
Not exactly, it's not a forceful move. The new data options are just that, options. Users can opt to keep everything on the token base if they choose to do so. Trust me, it'll be clear once it is made.wolph42 wrote: I'm curious though. Your talking about moving the data from the tokens to a database and have user access that db instead of the token for info.
Properties will exist on the token model BUT we're moving toward (very loosely) defining what a property should actually be, especially seen in the light of relevance to the object/token. For example, we are used to storing gobs of info on tokens that are not necessarily lib:tokens. Actually, the existence of library tokens itself is (no offense meant), what I think, a product of well-meaning design that got convoluted due to MT's organic growth; in other words, an anomaly. I mean, we have an image asset to represent a data store on the map, but no actual interface to view the data? Wouldn't it make things easier for people if data is separate from the token system, and designers can just create the references that they need?wolph42 wrote: So stuff like
- properties
- stored vision data
- location
right?
Under the hood, another question, you need to traipse map information to locate a library token, so that you can then perform operations on it? Why aren't all tokens referable no matter where they are? Why do you have to be on their map to do so? Some of the answer to that is because there was a hard association made between a map, and what was on it. It makes sense sometimes, and creates problems in other situations. Everyone here knows more or less what I mean.
Stored vision data will not persist on the token. I'm guessing that when this was conceptualized, thing were viewed from the actor's perspective; like what an entity perceives, it "knows", so the logic then is to store the knowledge there. I haven't sat down to implement this but I'm going to test shifting things to the Player's perspective, and it starts with storing vision on the map itself, as opposed to the token. (To me) it makes more sense that way.
Being in-character aside, a player with ownership over a certain token "sees" or "knows" what the token does, if we apply the same logic to all his/her tokens, then all their vision data should be an amalgamation both in (stored) and on (visualized) the map. If we take vision data out of a token, passing it along the network would be a lot lighter. The ideal is to "flatten" the consolidated views and forget the vision data on the individual/character level, but I'm guessing people would still want to make some sort of persistent references to a character's vision data (i.e. Character: Vision info), so that's still on the table, though, I think, that defeats the purpose a little; though one good scenario for keeping references is when there is transfer of ownership to another player, so that player's map needs to be updated, while the former owner needs his map to "forget" what the character saw. In order to the impact of maintaining these references lighter, I think we'll need to take it out of memory and store it on media at certain intervals or force storage script-wise, and call it up when it is requested for, e.g. a transfer of ownership.
Storing on the map itself takes care of several things like multiple characters (e.g. summoned creatures), and the trickiness of the current Individual FoW. Instead of IFoW being an option, it can be made a standard. We'll essentially have our cake and eat it too. The only person who won't benefit much from this would be the GM, as he maintains and "knows" all the views. Since they're built to suffer for their players, it'll be nothing new to them
Location info is definitely a token property, so it stays on the model.
I think I've answered most of the first paragraph. When a token is moved on the map, we'll only be moving its image. Location information will be updated when it gets dropped on the map, and that's about it. There will only be one model per token, hence one data model as well. When information pertaining to it is manipulated or modified, it behaves as it always has: all client's get updated in session time, but everything becomes permanent only if the host saves things post-session. We'll just make thing smarter by updating only the parts that got changed, instead of passing the whole token around each time.wolph42 wrote:currently (IRC) when one thing on the token is changed (e.g. moved) the updated token is send to the server and the server sends the updated token to the remaining clients, right?
in your case? is the data again send to the server and then again distributed to the remaining clients (but now to local databases instead of tokens)? Or is the data is send to a central db, but how do the clients then'know' the changed location of the token?
The reason (I think, and only on anecdotal evidence) things are what they are right now is, MT started out only to move images around on a map, and it was great and all that connected clients can see a token move in real-time. When data was added to the model, and macro script introduced, everything just rode on how the token movement mechanism works, regardless on whatever it brought along with it. It's just about as close as MT can get to having a "god-object". Again, purely guess work on my part.
Yes, and that all instances of the same token on different maps are just images referencing the master token model.wolph42 wrote: Overal I gather that the big advantage is is that when e.g. the 'wounds' property of a tokens is changed, you no longer need to send the entire token with all its data over all clients, but just that piece of information?
Phew. I need to take a break. We're prepping for launch, so I'll be very busy over the next 5 days, but I still hope people will drop by and continue the discussion. 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
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in