-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: importData() function #4728
Comments
Hopefully, you'd use forward slashes instead of backslashes — the name you've chosen has an embedded TAB character in it (that's what In general, the goal of a campaign is for everything in it to be self-contained. If you find yourself copying data from campaign to campaign, your best approach is likely to store it on a token either as properties or as macros. Then you can d/d that token onto the map of a new campaign and drag macros from it to that Campaign panel or copy/paste properties from it to other areas. If you do that a lot (as in, SERIOUSLY a lot), create a macro that copies the macros or properties for you; then it becomes just a single click after the d/d. Or create an empty campaign that has the information in it already and use that as a template when you create a new campaign, or export the map containing your token full of info and import the map into a new campaign. While MT tries hard to provide upward compatibility of campaigns, maps, and tokens, we can't do anything about arbitrary files just sitting around somewhere on your system. Those external resources make the campaign fragile as they'll only work on your system and nowhere else. Not particularly useful when you want to share your campaign file with someone else, or even load the campaign on a different machine or run it from a flash drive. IMO, the If you're truly intent on using an external resource, there are also the various REST.* functions. They allow you to open a read/write connection to a web server somewhere and exchange data. You could store your data on a throwaway account on a free web server, then use the REST functions to access that data. (GET requests should be relatively easy, but a POST request would likely require some work on the web server end, particularly on the free services.) Sorry, long rant. I'll shut up now, but I wanted you to know there are options already that are more fitting with the concepts behind how MapTool stores data. |
I think I am using "", however have learned to use "\" in place of "" I don't have a lot of programming knowledge, so am kind of learning as I go. Unless my limited understanding of REST is totally skewed, its a way to get data out of maptool, so wouldn't that be "arbitrary files just sitting around somewhere on a restful server"? I am honestly not trying to sound snarky, but the simple fact that rest.GET exists shows there is a need/desire to get information into maptool from the outside world, doesn't it? Again, unless I totally misunderstand restful (Very possible.) |
Sorry, clicked wrong button to close issue, was not intended. |
No problem. It's impossible to know what level folks are at until after there's been some interaction. Now we each know where the other is coming from. :)
That's why I suggested a token (if you only want to persist the data) or exporting a map (which would include one or more tokens). I agree with you that copying data around is likely a pain in the neck. It does sound like you might not be familiar with some of MapTool's other features. If you haven't yet checked out our wiki, then I would encourage you to. The first column of the home page has a bunch of "introduction" articles and you may find various ways that people have organized their own MapTool campaigns. Personally, I like exported maps. (As you can probably tell!) They are fairly self-contained, except they don't save Token Property Types or other campaign settings (they're just the graphics assets and any properties or macros on those assets). Exported maps from 15 years ago can still be loaded today.
Ah. That's my shortcut for not having to type out "drag and drop". Another abbreviation is "dnd" but that looks too much like the name of the game system!
Okay. I'm just pointing out that when you upgrade to a new computer, it will be painful to ensure that all of the external assets you want are in the right place. I've upgraded my laptop many times over the years and the last thing I want to do is upgrade a laptop and then find out that my workflow is no longer going to work — I either retrofit my workflow, or change the new system so that it does work. Either way it can take a lot of time.
That "accepted" comment was just a side note that the focus of MT is to keep things self-contained. Functions for dealing with external resources have a tough hill to climb before they are approved for adding to MT. Clearly, if it works for you, there's no reason to stop using it. At the same time, there may be other options that will work for you.
It's true that you would need to right-click on the token and select Save As.... You're likely to get better results working with techniques that are recommended (since MT's support for those things will be more refined). When I run a game, I create a campaign file and set up all of the Campaign Properties the way I want. Then I add a new map for the first encounter area, populate it with NPCs and/or monsters, and then export the map before game night. That gives me three things: (1) a pristine version of the map in case something happens during the game and I need to start over, (2) a backup of the map that can be loaded in a different campaign in the future, if I wish, and (3) an archive copy that's already been prepped. It might be an important encounter in one campaign, but it could be a random encounter in another, so I like to reuse the work I've done. :) I can put text into a token's Notes field and put it on the Object layer. When players click on it, they'll see the Notes appear in a popup panel. I can use plain text, HTML text, or markdown text (which can be easily converted to HTML). For use between game sessions, the HTML can be saved on a web server or emailed to players and they'll be able to view it directly. My campaign file will usually have 6-10 maps in it (sometimes more). As the PCs progress, I delete old maps (after exporting them if I want to save the state) and create new ones. That way, the same campaign is used over and over and becomes a "container" with replaceable components. For your workflow, I would suggest keeping your data on one or more tokens on a single map, you can either export the map and import it into another campaign, or.... just delete the other maps that you don't need anymore, then create new maps within the same campaign. You can always use Save As... on the campaign file and keep different versions of it. I used to keep two copies of my campaign for each game session, one from before the game starts and one after it's over. I named mine
Yes, I understand. That's a result of me not knowing what your experience level was. Don't sweat the small stuff, and just ignore the REST functions at this point. It would require more effort than you want (or need) to put into it.
That's a great attitude! And "thanks". :)
It's difficult enough to communicate clearly in text — I make mistakes all the time, thinking that something sounds good in my head, but other people take it wrong. It happens, but it didn't happen here. :) And good luck — maybe comments from others will encourage the addition of a new |
@ShadowWizard11 here is an example which may work for you to pull data in from a file: https://discord.com/channels/296230822262865920/1222304280204279948 |
Describe the Problem
There is no way to get Data back into maptool automatically.
I regularly create bits of data, configurations, etc that need to follow from campaign to campaign. Automatically importing that data from a written text file written with exportData() would be ideal with me.
The Solution you'd like
Create an importData() function:
[h:imported=importData("c:\maptooldata\thefiletoimport.txt")]
Honestly, if we can write to the disk, why not let us read from it too?
Alternatives that you've considered.
Outputting to a text file, and manually importing it by copying and pasting it into a property, or into a dialog box.
Additional Context
No response
The text was updated successfully, but these errors were encountered: