My MapTool Fork: Video Proofs of Concept 02-07-2013
Moderators: dorpond, trevor, Azhrei
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Thanks! That clears things up.
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)
The thing is you really need the low level programmatic stuff in there first before you make it higher level / more user friendly. What's going to happen is that the low level SQL stuff will release first and a slew of problems/issues are going to crop up and need to be fixed/tweaked/re-thought about it. Once that's done and people are actually using it to good effect, that's when you'll see higher level interfaces.Full Bleed wrote: 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?
Edit: Thanks for pointing out the mis-quote Lee.
Last edited by Dracones on Sun Feb 09, 2014 10:41 am, edited 1 time in total.
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
@Dracones I'm sorry to be nit-picky, but I think you made a small error with the quote boxes
@FullBleed I noticed that I didn't answer the question fully. Yes, there are a lot of simple query builders out there, but I believe the basic macro functions I wrote to abstract the process should be fine for most users.
edit: @wolph you're welcome, man
@FullBleed I noticed that I didn't answer the question fully. Yes, there are a lot of simple query builders out there, but I believe the basic macro functions I wrote to abstract the process should be fine for most users.
edit: @wolph you're welcome, man
Last edited by Lee on Mon Feb 10, 2014 1:42 pm, edited 2 times 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
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: MapTool Fork: Video Proofs of Concept (finally)
Agreed, plus, from what it looks like, the database will be "external"? As long as it's external, you'll most likely do all your creation/editing/loading/etc outside of MapTool in a SQL of your choice like Oracle SQL developer, Toad, or what not. All MT will need is macros to execute your SQL. Sure you'll need macro's for DB creation and what not in case you need to create DB info inside MT dynamically, but I would think any other design work would be done outside of MT?Dracones wrote:The thing is you really need the low level programmatic stuff in there first before you make it higher level / more user friendly. What's going to happen is that the low level SQL stuff will release first and a slew of problems/issues are going to crop up and need to be fixed/tweaked/re-thought about it. Once that's done and people are actually using it to good effect, that's when you'll see higher level interfaces.Full Bleed wrote: 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?
Edit: Thanks for pointing out the mis-quote Lee.
PS, Lee, are you using Java DB? I was thinking of playing with it as it seemed an easy way to add a Database to MT but since you already tackled it...
-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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
My shared rpg stuff:
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Yes, H2. There are some small quibbles with it, but those are of the advanced usage sort. After quite a bit of research (including Java DB), it's what I settled on for the SQL aspect. I like where it's going, and in the event something better comes along, it'll be easy enough to do the switch.
While I used SQL Workbench for the demo, users can pretty much design everything from within MT. I haven't written the table views yet, but I already wrote an abstract view for the tables I used for the token, macro, and application properties, so I can write one for dbs without much work.
When the time comes, I'd like to discuss how I structured it, and see if it holds up to scrutiny. It only has 2 users, one on admin-level and another on restricted user. Password for both are set on db creation. I kind of don't see the point of having a multitude of registered users, when the macros written for db functionality hides the details from users, and all calls to the db stems from a GM push. If there is a compromise to security, it would generally lie in dbs with easy or no passwords.
While I used SQL Workbench for the demo, users can pretty much design everything from within MT. I haven't written the table views yet, but I already wrote an abstract view for the tables I used for the token, macro, and application properties, so I can write one for dbs without much work.
When the time comes, I'd like to discuss how I structured it, and see if it holds up to scrutiny. It only has 2 users, one on admin-level and another on restricted user. Password for both are set on db creation. I kind of don't see the point of having a multitude of registered users, when the macros written for db functionality hides the details from users, and all calls to the db stems from a GM push. If there is a compromise to security, it would generally lie in dbs with easy or no passwords.
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
Would love to hear about the DB details, Lee!Lee wrote:When the time comes, I'd like to discuss how I structured it, and see if it holds up to scrutiny. It only has 2 users, one on admin-level and another on restricted user. Password for both are set on db creation. I kind of don't see the point of having a multitude of registered users, when the macros written for db functionality hides the details from users, and all calls to the db stems from a GM push. If there is a compromise to security, it would generally lie in dbs with easy or no passwords.
DBs are a large part of my workday so I might be able to contribute something of value.
My shared rpg stuff:
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
Awesome! It'll happen very soon, I don't have enough time right now, but with your background, you'll get for sure what I mean when I say:badsequel wrote: Would love to hear about the DB details, Lee!
DBs are a large part of my workday so I might be able to contribute something of value.
- It's on auto-commit
- 2 users for each MT related DB, like I mentioned above
- Things are written for embedded mode, though server-mode isn't far off. I just don't see the much use for it right now in games over internet and varying internet service speeds per user etc. But I do see the value for people who'll go headless.
- We got basic sql (select, insert, update, delete) down on macro script, and 2 functions to pass any kind of SQL statement directly to the db engine.
Ooops, out of time. Let me know what you think
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
i'll get back to you. I'm on a tablet atm and find myself creating more typos than meaningful text. Touch screen revolution my a**
My shared rpg stuff:
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
SQL may be more of a "coder's only" solution, but it's a standard language that you can Google any hundreds of sites and largely get the same answers. While the MapTools wiki is great, there are a number of stubs and functions that don't have immediately obvious uses, and best practice is never really explained, or may be nestled deep in one of CIF's or Wolf's forum posts.
Example: I have never used broadcast() for my roll results. The result was always preceded by the character that rolled it. I'd seen the broadcast() wiki entry and understood it, but never made the connection.
With something like SQL, there is a huge pool of practical information, best practice, implementation, etc. On top of that, it's incredibly powerful and scalable. So while this may be more of "Great, more coding commands I have to learn", it's also an in-place resource with a much broader userbase, which means more help and support.
Lee talks about moving the information off the token, and it's a really exciting direction. MapTool right now can easily get confused in regards to which token a macro should be running on. The more macros you run, the higher the odds of confusion. There's best practice to avoid this, but you could essentially remove the issue if all the data is stored in a single, searchable database. Imagine a single point of data storage versus the multiple tiny storage locations we are familiar with now.
I can't see myself rewriting my framework now to leverage the SQL, but I sure wish it was an option when I first began making one.
Example: I have never used broadcast() for my roll results. The result was always preceded by the character that rolled it. I'd seen the broadcast() wiki entry and understood it, but never made the connection.
With something like SQL, there is a huge pool of practical information, best practice, implementation, etc. On top of that, it's incredibly powerful and scalable. So while this may be more of "Great, more coding commands I have to learn", it's also an in-place resource with a much broader userbase, which means more help and support.
Lee talks about moving the information off the token, and it's a really exciting direction. MapTool right now can easily get confused in regards to which token a macro should be running on. The more macros you run, the higher the odds of confusion. There's best practice to avoid this, but you could essentially remove the issue if all the data is stored in a single, searchable database. Imagine a single point of data storage versus the multiple tiny storage locations we are familiar with now.
I can't see myself rewriting my framework now to leverage the SQL, but I sure wish it was an option when I first began making one.
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
badsequel wrote:i'll get back to you. I'm on a tablet atm and find myself creating more typos than meaningful text. Touch screen revolution my a**
@jckrbbt I think it'll be easier than you think. If you watched the token props video, it basically shows a 2 column view that parses JSON if it encounters it on a row. The same mechanism can be used to transfer all token properties (well, at least the data, if you want to keep attributes on the token) within a token into a 2-column, Key-Value db. The good news is, you likely won't have to write macros for it, there's already a transfer process written for it.
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
I refer back to the Scanner's gif.
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
You intend to use TWO databases, Lee?
One for persisting POJO's(HDB) and another for user data tables(H2)?
I can understand that to avoid ORM for pojo -> RDBMS..
Perhaps you should take a look at OrientDB.
http://www.orientechnologies.com/orientdb/
I think a single instance of it can run both as a DocumentDB and ObjectDB, but I am not sure.
Edit: The above might have more to do with the "internals"(hdb) always following the MT code, and that the user data can be located elsewhere..
I've experimented a bit with OrientDB and like it, but my experience is limited to using it as a document DB and very simple java code. I suck at java to be honest..
One feature I really like about OrientDB is that the query language is SQL. So you can dump pure SQL statements to the server and catch the response(JSON).
I've managed to forget how to log on via console to check up on that. *facepalm*.. But using the built in Studio app that comes with the server:
Another is that it returns JSON via class/function ODocument.toJSON
Like this:
Anyway..
A single table for storing key-value pairs to hold Token data in a relational database is perfectly doable. I'll assume there is a column holding a TokenId or equivalent so you know who owns what.
Embedded/server mode:
How do you connect? if the conn string is an address like localhost:port, switching that for a remotehost:port address shouldn't really matter, right?
If you have some docs on how H2 is set up(the schema, not server config) I'd love to look at it.. PM if you want.
Dunno if any of this is of any help...
One for persisting POJO's(HDB) and another for user data tables(H2)?
I can understand that to avoid ORM for pojo -> RDBMS..
Perhaps you should take a look at OrientDB.
http://www.orientechnologies.com/orientdb/
I think a single instance of it can run both as a DocumentDB and ObjectDB, but I am not sure.
Edit: The above might have more to do with the "internals"(hdb) always following the MT code, and that the user data can be located elsewhere..
I've experimented a bit with OrientDB and like it, but my experience is limited to using it as a document DB and very simple java code. I suck at java to be honest..
One feature I really like about OrientDB is that the query language is SQL. So you can dump pure SQL statements to the server and catch the response(JSON).
I've managed to forget how to log on via console to check up on that. *facepalm*.. But using the built in Studio app that comes with the server:
Spoiler
select * from character
Returns:
{"result":[{"@type":"d","@rid":"#9:1","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"},{"@type":"d","@rid":"#9:2","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"},{"@type":"d","@rid":"#9:3","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"},{"@type":"d","@rid":"#9:4","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"}]}
Returns:
{"result":[{"@type":"d","@rid":"#9:1","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"},{"@type":"d","@rid":"#9:2","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"},{"@type":"d","@rid":"#9:3","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"},{"@type":"d","@rid":"#9:4","@version":1,"@class":"character","playername":"fluke","charactername":"Skywalker","class":"Fighter"}]}
Like this:
Spoiler
for (ODocument d1 : db.browseCluster("character")){
System.out.println(d1.toJSON("character") );
}
returns:
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
System.out.println(d1.toJSON("character") );
}
returns:
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
{"playername":"fluke","charactername":"Skywalker","class":"Fighter"}
A single table for storing key-value pairs to hold Token data in a relational database is perfectly doable. I'll assume there is a column holding a TokenId or equivalent so you know who owns what.
Embedded/server mode:
How do you connect? if the conn string is an address like localhost:port, switching that for a remotehost:port address shouldn't really matter, right?
If you have some docs on how H2 is set up(the schema, not server config) I'd love to look at it.. PM if you want.
Dunno if any of this is of any help...
My shared rpg stuff:
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
Re: My MapTool Fork: Video Proofs of Concept 02-07-2013
@jckrbbt
@badsequel Here's their doc page, the schema info is listed near the bottom.
I checked out OrientDB early on when I reviewed possible NoSQL solutions. I liked it too, but, there were several factors as to why I set it aside in favor of HyperGraphDB et. al. I don't recall all the details, but it not being truly embedded was likely one of them, and, perhaps, being primarily a document DB was another. Not to mention, I can recall rumblings of "overkill" when a discussion like this came up in the past and MongoDB / OrientDB was mentioned.
Also, it having a nod to SQL, when we already have a dedicated SQL DB, made it a non-factor, we preferred the OODB/Graph DB to provide access methods more akin to Java, since we'll be using it for the internal models anyway.
If ever we'll be reviewing OrientDB for use again, it's probably to use it for the (simple) web services we have planned, where assets/resources remain static for a long time. Idk, we'll cross it when we get there
As for the 2-column, KV table, the table name (taken from a token's unique ID) will serve as reference back to it, so it really is a 2-column structure.
Yes, it doesn't matter. It's a toggle in the connection string, and how things move around is taken care of internally. We prefer users to use embedded as it is suitable for most use cases.
Oh, all of this is helpful. No worries
@badsequel Here's their doc page, the schema info is listed near the bottom.
I checked out OrientDB early on when I reviewed possible NoSQL solutions. I liked it too, but, there were several factors as to why I set it aside in favor of HyperGraphDB et. al. I don't recall all the details, but it not being truly embedded was likely one of them, and, perhaps, being primarily a document DB was another. Not to mention, I can recall rumblings of "overkill" when a discussion like this came up in the past and MongoDB / OrientDB was mentioned.
Also, it having a nod to SQL, when we already have a dedicated SQL DB, made it a non-factor, we preferred the OODB/Graph DB to provide access methods more akin to Java, since we'll be using it for the internal models anyway.
If ever we'll be reviewing OrientDB for use again, it's probably to use it for the (simple) web services we have planned, where assets/resources remain static for a long time. Idk, we'll cross it when we get there
As for the 2-column, KV table, the table name (taken from a token's unique ID) will serve as reference back to it, so it really is a 2-column structure.
Yes, it doesn't matter. It's a toggle in the connection string, and how things move around is taken care of internally. We prefer users to use embedded as it is suitable for most use cases.
Oh, all of this is helpful. No worries
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
That sounds like a strange approach to me. So you are in essence querying the H2.INFORMATION_SCHEMA to look for tables that might hold KV pairs belonging to a Token?Lee wrote: As for the 2-column, KV table, the table name (taken from a token's unique ID) will serve as reference back to it, so it really is a 2-column structure.
SELECT table_name FROM INFORMATION_SCHEMA.TABLES
where table_name like 'someTokenIDfromTheJavaCode'
I assumed a KV table schema like this:
+-----------------+
|TokenId|Key|Value|
|100 |STR|18 |
+-----------------+
You do avoid some DB setup before use. No need to create/make sure tables exists that conform to a predefined/expected schema.
edit: btw I kinda like H2. Haven't figured out how to interact via Talen Open Studio for data integration yet, but the DB itself works fine. I loved the way they packaged that simple web browser studio app in it. \O/
My shared rpg stuff:
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev
(exe)TokenNameChanger3: https://www.dropbox.com/s/cqsof54v3dl2k ... 3.zip?dl=0
Tiddly Spell Wiki: https://www.dropbox.com/s/53pya4k68mnvc ... ddly01.htm
Stuff to check out:
Mote Kickstarter(back it): https://www.kickstarter.com/projects/74 ... abletop-ev