Skip to content
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

Open
ShadowWizard11 opened this issue Mar 20, 2024 · 5 comments
Open

[Feature]: importData() function #4728

ShadowWizard11 opened this issue Mar 20, 2024 · 5 comments
Labels
feature Adding functionality that adds value

Comments

@ShadowWizard11
Copy link

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

@ShadowWizard11 ShadowWizard11 added the feature Adding functionality that adds value label Mar 20, 2024
@Azhrei
Copy link
Member

Azhrei commented Mar 20, 2024

Hopefully, you'd use forward slashes instead of backslashes — the name you've chosen has an embedded TAB character in it (that's what \t means in a string). All of which is mentioned in the wiki entry for exportData(). 🙂

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 exportData() function shouldn't be in MapTool. It was likely sucked into the codebase as a smaller part of a much larger set of changes and not properly reviewed. I doubt it would be accepted today.

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.

@ShadowWizard11
Copy link
Author

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.
As far as self contained, for my purpose that won't work. I have created macros specifically for player treasure for example, and I use a new campaign file for each dungeon. That treasure needs to be moved to the new campaign.
I am afraid I don't know the term "d/d". Very new programmer with no formal programming training.
As far as the campaign working on my system and no one elses, thats kind of the way I have it set up.. It is so full of bugs, strange functions, etc that it would be almost useless to anyone else.. But I am okay with that. It is designed to work with my system and my group, and thats all I really want it for.
For me personally, the exportData() function is a godsend. It allows me to log things outside the program I want to keep track of, and save treasure to text files for the players viewing outside the game. I am not quite sure why a function would "not be accepted" but personally I use that function a lot, and has really helped both me and my players.
I have considered placing the data I want to transfer onto a token, but that is only slightly more convenient then copy/paste. I forget to copy that data, and then I load a new campaign file.. Then we go to do something, so I have to load the old campaign file, copy the data, close the old campaign file, and paste the data into the current one (I do load maptool a second time to do that) but its just a pain. And the same thing would happen.. I would need to load, save the data token, and paste it into the current one. I have also considered REST functions, but thats a whole new learning curve for me. I understand almost nothing about it. So little I have tried googling, and get nothing because I don't know what to google. I have tried things such as "Setting up a restful server to store data to be retrieved later" "RESTful for data storage and retrieval" etc. I just don't know enough about it to even be able to google it.

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.)
Finally, don't apologize for the rant (And this isn't me poo-pooing your ideas either.) Additional information is always welcome. Even though I have considered the options you are suggestion, the next person that reads this may not; and you didn't know what things I had considered either. importData() may never come, and no one else may ever find it useful (I doubt it, I am sure if its there people will use it) but you never know unless you ask.
Again, thank you for taking the time. I am pretty sure some of the things in here may come off the wrong way, but I am not meaning them to; I am thankful you took the time. I have some disabilities that make it times difficult to communicate without sounding rude.. I am beginning to realize I need to start to put that disclaimer at the end of most of my reply posts.

@ShadowWizard11
Copy link
Author

Sorry, clicked wrong button to close issue, was not intended.

@Azhrei
Copy link
Member

Azhrei commented Mar 21, 2024

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.

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. :)

As far as self contained, for my purpose that won't work. I have created macros specifically for player treasure for example, and I use a new campaign file for each dungeon. That treasure needs to be moved to the new campaign.

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.

I am afraid I don't know the term "d/d".

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!

As far as the campaign working on my system and no one elses, thats kind of the way I have it set up.. It is so full of bugs, strange functions, etc that it would be almost useless to anyone else.. But I am okay with that. It is designed to work with my system and my group, and thats all I really want it for.

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.

For me personally, the exportData() function is a godsend. It allows me to log things outside the program I want to keep track of, and save treasure to text files for the players viewing outside the game. I am not quite sure why a function would "not be accepted" but personally I use that function a lot, and has really helped both me and my players.

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.

I have considered placing the data I want to transfer onto a token, but that is only slightly more convenient then copy/paste. I forget to copy that data, and then I load a new campaign file.. Then we go to do something, so I have to load the old campaign file, copy the data, close the old campaign file, and paste the data into the current one (I do load maptool a second time to do that) but its just a pain. And the same thing would happen.. I would need to load, save the data token, and paste it into the current one.

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 cotct-YYMMDDa and cotct-YYMMDDb with the a and b on the end to distinguish before the game or after the game. And yes, I have hundreds of these files now from a campaign that last many years! I don't use them as much as I use the exported maps.

I have also considered REST functions, but thats a whole new learning curve for me.

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.

Finally, don't apologize for the rant (And this isn't me poo-pooing your ideas either.) Additional information is always welcome.

That's a great attitude! And "thanks". :)

I have some disabilities that make it times difficult to communicate without sounding rude..

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 inportData() function!

@Baaaaaz
Copy link

Baaaaaz commented Mar 26, 2024

@ShadowWizard11 here is an example which may work for you to pull data in from a file: https://discord.com/channels/296230822262865920/1222304280204279948

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Adding functionality that adds value
Projects
None yet
Development

No branches or pull requests

3 participants