Joe's Ugly Hacks 'Drop-in' macro libraries - v0.2.5 [alpha]

These are tools and utilities that make it easier to run games. This includes Lib: macro tokens dropped into MapTool to manage the game, a conversion file for CharacterTool to allow use in MapTool, or just about anything else you can think of -- except graphics with macros and anything specific to a particular campaign framework. Those are already covered by the Tilesets subforum and the Links and External Resources forum.

Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

wolph42 wrote:
Thu Apr 08, 2021 2:56 am
how the flying fk did yo figure that one out?!?
I noticed that if you dropped a PDF on the map it ended up as a file named it's MD5 hash in the asset cache, so I figured maybe Maptool wasn't doing any content type filtering on what gets included in the asset cache. Tried it out and it worked. You can literally drop ANY binary on the map to include it. The problem is trying to read it again.

I figured if the Maptool devs had missed a filter on the map drop, they probably missed one on one of the load methods as well, so I tried every asset loading method I could with the MP3 token id/name until one of them worked: "getImage" wound up doing the trick. It will give you the asset tag of ANY kind of asset, not just images.

After that it was just a matter of figuring out how to get access from inside a macro to the Maptool asset cache filepath: hello FSD!
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

Full Bleed wrote:
Thu Apr 08, 2021 8:43 am
I just can't see how a live chat/teamwork app can replace the functionality of a forum and I suspect a lot of good info is being lost in the shift to it (like the release announcement of 1.8.4).

I don't have a hate-on for discord so much as I think it's a poor forum substitute.
Agreed, and you are right. People who insist on using "live chat" tools like Discord and Slack for "productivity" are basically just wrong. By every objective measure they've tried, live chat is an inferior tool, that lowers productivity.

Anyone who doesn't know this, has failed to learn the lessons from ICQ live chat, MSN live chat, Google Wave and everytime some asshat has tried to use IRC as a corporate help forum.

Live chat is mostly just a large distraction, and the signal to noise ratio is so high, most actual valuable content gets lost in a bunch of idle garbage chat.

Any kind of live chat is a poor tool for this job.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

JoeDuncan wrote:
Thu Apr 08, 2021 8:39 am
wolph42 wrote:
Thu Apr 08, 2021 2:56 am
o and before i forget I couldn't find an ontokenmove, so what exactly do you use as a handler for the ambient sound?
That was on purpose, BTW, to not conflict with BoT which I know is using "onTokenMove".

JUH can easily be updated to run the sound manager from "onTokenMove", by calling "onSoundManage@lib:media" from within "onTokenMove" instead of the timer callback.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

wolph42 wrote:
Thu Apr 08, 2021 2:56 am
why you don't use userdefined functions,
I tried using them at first, but I found them too difficult and clunky to use and they kept blowing up on me so I purged them with fire. Like I would get an error message, that has the UDF name in it... now I have to go find the onCampaignLoad method that defined it so I can find the ACTUAL macro to debug... ugh, no.

Naming the UDF functions and the library functions the same name didn't help and was just too "JAVAy" for me - like shades of "IOBuffer myIOBuffer = new IOBuffer()"

It just seemed like an unnecessary abstraction put in place for people who don't understand what their doing and want everything to "look all nice like standard function calls". For me - I found it detracted from my ability to actually grok what was going on. I have never liked "syntactic sugar" that abstracts away stuff you need to know. In my personal experience, I found it was an additional complication that made me write more code for no reason, and I found the abstraction more than doubled my debugging time just trying to resolve which function I was working with. UDFs were an added layer of complication I didn't need.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

wolph42 wrote:
Thu Apr 08, 2021 2:56 am
but if you use h: option then ALL nested routines are automatically hidden, so you don't need to add the h: to the nestngs as well.
What, like theoretically? :P

All I know is that I kept getting phantom empty line outputs that would just NOT go away until I just slapped a bloody "[h" in front of everything.

It was so frustrating I wanted to smash my keyboard :(
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

Oh, one other thing for the forum in general:

I believe this thread more properly belongs in either "User Creations -> Token Libraries", or "User Creations -> Drop-in Macros", but I don't have permissions to post in either (as far as I can tell). Do I have to request those permissions somewhere, or am I missing something?

thx
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by Full Bleed »

JoeDuncan wrote:
Tue Apr 06, 2021 8:02 pm
The purpose of the "file sync directory" is to sync third party campaign assets between clients. It's an optional feature.

Please give it a shot and let me know what you think.
Ok, so, I want to make sure I understand some things in setting this up and using this feature in the future.

I currently have a dropbox account that I use to store my campaign sound files. I do not sync locally with the account though. When I add a new file to my dropbox I add a link to that file in a custom playSound() UDF which is basically a big SWITCH so that I can call the sound by doing something like:

Code: Select all

[playSound("Fumble", target)]
This works fine, but could blow up if dropbox changes their links and does require me to manually add each new sound to the playSound() macro. I think it might also transfer the sound every time they are called, which isn't as nice as the trick you're using to cache the sound files.

That is, if I understand what you're doing, when I drop a sound asset into my campaign MT copies it into my asset directory. The file sync setting then allows me to easily serve that asset to clients using your tools.

This seems quite convenient, especially if I want to add something on-the-fly (though, see suggestions below on this.)

Some concerns:

1) How does your tool distinguish between a clip and a sound when dropped?
2) Any problems if the asset cache is deleted?
3) After the first call, is the file caching client side? Or is it continually pulling from the server's cache?
4) Won't this increase the size of the campaign file significantly if we add large sound files?


As an alpha I suspect that some of these may already be in development but I figured I'd mention them anyway.

Suggestions:
a) It looks like you need to re-execute timeForm when new audio is added during a campaign.
b) How about using tables to hold animation image files? (Not sure if token image tables could be useful or if they are limited to facing calls.)
c) Why not replace a sound's token image with something (like your isAmbientAudio state) when named?
d) Is the is isAmbientAudio state really needed once the token is given the "audio:" prefix? Was thinking that an on/off state would be more useful with a standard sound token image.
e) A settings dialog for new sound files would be nice. Something to quickly name and set the GM note settings would make it far simpler to use.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
That is, if I understand what you're doing, when I drop a sound asset into my campaign MT copies it into my asset directory. The file sync setting then allows me to easily serve that asset to clients using your tools.
Yes - *almost*. Once you drop an asset onto the map, MT shares it automatically with connected clients, I have nothing to do with that. The FSD just allows you to tell a macro how to access those files locally on your client's machine once they're there.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
1) How does your tool distinguish between a clip and a sound when dropped?
It doesn't. It's not my tool that adds it to the map or asset cache - that's all Maptool. Half the reason this works is because Maptool *doesn't* distinguish binary content when you drop files on a map. JUH will play any "audio:" token as a clip, but only loads those tagged as "isAmbientSound" for ambient processing.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
2) Any problems if the asset cache is deleted?
Same problems you'd have if you deleted images from your asset cache I suppose.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
3) After the first call, is the file caching client side? Or is it continually pulling from the server's cache?
It's cached on the client side *before* the first call. The only time it's pulled from the server is when the campaign is loaded - so when you either open a campaign file or connect to a server - *that's* when all the assets (or at least the ones on the current map) get moved to the clients asset cache. The JUH local methods always and only pull from the local client's asset cache.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
4) Won't this increase the size of the campaign file significantly if we add large sound files?
Sure, but so does adding large image files. I can do it now with gigantic images, or drop a 100mb PDF file onto a map...

None of the MP3 sounds I've used yet have exceeded 1mb, but I have several 5mb+ images in my campaign (not the JUH demo one, the AFF one I'm running). This gives you a tool you can use, if you don't want giant campaign files, don't add giant sound files? Even a 5 min song is only a 5mb MP3 though, but whether you explode your campaign file or not seems to be something that should be at the user's discretion.

Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
a) It looks like you need to re-execute timeForm when new audio is added during a campaign.
Yes, absolutely. The current UI is rather rudimentary and barely serviceable. It alllows starting and stopping the sound, but not reloading. I'll add it. thx
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
b) How about using tables to hold animation image files? (Not sure if token image tables could be useful or if they are limited to facing calls.)
I looked into that, but it seemed like they were being used automatically in some other way for token facings, so I didn't want to mess with it. One improvement I did think of, but don't have the skills to implement is using a base image and then transparent PNG delta overlays that you just add on top and flip back and forth instead of changing any token's actual image. It would reduce campaign file storage anyway.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
c) Why not replace a sound's token image with something (like your isAmbientAudio state) when named?
Haven't tried it yet, because I wasn't sure if it would affect the actual audio asset itself. I'll try it and use it if it doesn't break anything.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
d) Is the is isAmbientAudio state really needed once the token is given the "audio:" prefix? Was thinking that an on/off state would be more useful with a standard sound token image.
Not all "audio:" tokens are ambient sounds! Some are simply the MP3s for spatial clips (the heal & lightning etc...) "isAmbientAudio" is how "lib:media" knows which ones to load for ambient processing. The "audio:" prefix is simply convention to denote audio content inline with how "image:" prefixes are used to denote visual content.
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
e) A settings dialog for new sound files would be nice. Something to quickly name and set the GM note settings would make it far simpler to use.
Definitely needs better UI, which is one of the reasons I posted - to get feedback like this on what people need/want/like. I'll add it to the list.

thx!
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
4) Won't this increase the size of the campaign file significantly if we add large sound files?
To expand on my answer to this, adding large sound files can obviously increase your campaign file size - however, this is already the case. JUH doesn't change this in any way.

You can already drop any large file you want on to a map and the campaign file size will increase accordingly. If it is a concern, the correct way to address it would be to add a file size cap on the map drop (like refuse anything >10mb or something), but that's the jurisdiction of Maptool itself, and beyond my purview.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by Full Bleed »

JoeDuncan wrote:
Thu Apr 08, 2021 11:14 am
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
4) Won't this increase the size of the campaign file significantly if we add large sound files?
Sure, but so does adding large image files. I can do it now with gigantic images, or drop a 100mb PDF file onto a map...

None of the MP3 sounds I've used yet have exceeded 1mb, but I have several 5mb+ images in my campaign (not the JUH demo one, the AFF one I'm running). This gives you a tool you can use, if you don't want giant campaign files, don't add giant sound files? Even a 5 min song is only a 5mb MP3 though, but whether you explode your campaign file or not seems to be something that should be at the user's discretion.
Ok. So you've worked around the inherent limitation that they built it to keep people from blowing up their campaigns with media files. ;)

I was kind of hoping that what was actually happening was that the visibly "broken" red X asset was actually just a link to the cached asset and wasn't actually a part of the campaign file. Hence my question about what might happen if the asset cache was deleted.

I like having the option that you've hacked out since it makes adding and managing assets simpler (at the cost of a, potentially, much bigger campaign file and having to build the UI and tools to do it)... but I do think it would be even better if we had some way to have "link tokens" that pull from the File Sync Directory without actually having the large data files being in the campaign file.

JoeDuncan wrote:
Thu Apr 08, 2021 11:14 am
Full Bleed wrote:
Thu Apr 08, 2021 10:39 am
b) How about using tables to hold animation image files? (Not sure if token image tables could be useful or if they are limited to facing calls.)
I looked into that, but it seemed like they were being used automatically in some other way for token facings, so I didn't want to mess with it.
Yeah, I didn't think you could use the built in "image table" feature since it seems tagged to facing... but you could still try using a table to hold all the images so that sharing and transferring animations would be easier than having to share campaign files with all the necessary images. It would be better to be able to have one table and base token image that knew to cycle through Table images.

JoeDuncan wrote:
Thu Apr 08, 2021 11:14 am
Not all "audio:" tokens are ambient sounds! Some are simply the MP3s for spatial clips (the heal & lightning etc...) "isAmbientAudio" is how "lib:media" knows which ones to load for ambient processing. The "audio:" prefix is simply convention to denote audio content inline with how "image:" prefixes are used to denote visual content.
Gotcha. I understand the difference now.

You might still want to consider an on/off state on the audio token image. I think it would be helpful.


Thanks for sharing this.

It's always fun to see "new" contributors pushing the boundaries of what MT can do.


Also, as an aside, as the person that found this getImage() asset retrieval work-around, what do you think about the devs adding a getAsset() function? And if they did, would you like to see it do anything differently than how the getImage() function works?

Now that you've exposed this hack I think a FREQ should be put in for getAsset()... especially if it's deemed that using getImage() this way is actually a "bug". ;)
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

Full Bleed wrote:
Thu Apr 08, 2021 9:14 pm
Ok. So you've worked around the inherent limitation that they built it to keep people from blowing up their campaigns with media files. ;)
No, I haven't, because there aren't any. You can, right now, without using JUH *at all* - drop a 500mb binary video file in your campaign and blow up it's size if you want. There are NO inherent limitations on "blowing up campaign files". There was nothing to "work around".
Full Bleed wrote:
Thu Apr 08, 2021 9:14 pm
I like having the option that you've hacked out since it makes adding and managing assets simpler (at the cost of a, potentially, much bigger campaign file and having to build the UI and tools to do it)
Again, I have NOT enabled this. It was *always* possible.
Full Bleed wrote:
Thu Apr 08, 2021 9:14 pm
Also, as an aside, as the person that found this getImage() asset retrieval work-around, what do you think about the devs adding a getAsset() function? And if they did, would you like to see it do anything differently than how the getImage() function works?

Now that you've exposed this hack I think a FREQ should be put in for getAsset()... especially if it's deemed that using getImage() this way is actually a "bug". ;)
Removing this ability would be a silly thing for the devs to do. It's silly to begin with that audio assets in the asset cache can't be accessed without a hack. There's not a single good reason why an app like Maptool should handle image assets natively - but refuse to do the same for audio.

Every video game asset manager ever written manages both visual and audio resources. Every argument about intellectual property and file size applies equally well to images as it does to audio. It just doesn't make any darn sense not to allow audio asset management the same way.

What I would like to see the devs do, is add proper support for audio assets so I don't have to resort to all these ugly hacks to implement what should be a basic feature to start with.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by Full Bleed »

JoeDuncan wrote:
Thu Apr 08, 2021 10:54 pm
Full Bleed wrote:
Thu Apr 08, 2021 9:14 pm
Ok. So you've worked around the inherent limitation that they built it to keep people from blowing up their campaigns with media files. ;)
No, I haven't, because there aren't any. You can, right now, without using JUH *at all* - drop a 500mb binary video file in your campaign and blow up it's size if you want. There are NO inherent limitations on "blowing up campaign files". There was nothing to "work around".
Sure there was. You had to figure out how to use the file sync feature on the asset cache, dump an audio file into the campaign that throws an big red X (usually a warning sign you did something wrong/unintended), use an undocumented method of retrieving that "broken" asset from the synced cache (getImage()), and then built the tools to encourage doing it. Not sure where the resistance is coming from. This most certainly would not be done without your "work around." You're just going to have to own this one. ;) The devs made a conscious decision/effort to steer users toward using the playClip and playStream functions to implement remote audio file usage without supporting or enticing users to do exactly what you've uncovered they can do. You needn't take it as a criticism.

Full Bleed wrote:
Thu Apr 08, 2021 9:14 pm
Removing this ability would be a silly thing for the devs to do.
I agree. But it's also pretty clear that using getImage this way was not intended. So while I don't want to see the ability go away, I think a more appropriately named and implemented function like getAsset (or getAudio) should be offered. The question is whether or not there is any additional functionality such functions should have.

And, past that, I'm not sure that the lack of content filtering in MT *isn't* either a bug or an oversight. For example, I'm not sure I like the idea that someone could drop a potentially problematic executable into a campaign file.

There's not a single good reason why an app like Maptool should handle image assets natively - but refuse to do the same for audio.
Not sure I fully agree with there not being "a single good reason"... there are good arguments for keeping campaign files lean and/or transitioning to external asset storage/retrieval methods. Not to mention potential issues with how a lot of local audio assets might adversely affect MT's memory usage. That doesn't, however, mean that I don't want the option for local audio storage and distribution... and that was certainly discussed when the playClip and playStream functionality was made available.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by wolph42 »

JoeDuncan wrote:
Thu Apr 08, 2021 9:05 am
wolph42 wrote:
Thu Apr 08, 2021 2:56 am
why you don't use userdefined functions,
I tried using them at first, but I found them too difficult and clunky to use and they kept blowing up on me so I purged them with fire. Like I would get an error message, that has the UDF name in it... now I have to go find the onCampaignLoad method that defined it so I can find the ACTUAL macro to debug... ugh, no.

Naming the UDF functions and the library functions the same name didn't help and was just too "JAVAy" for me - like shades of "IOBuffer myIOBuffer = new IOBuffer()"

It just seemed like an unnecessary abstraction put in place for people who don't understand what their doing and want everything to "look all nice like standard function calls". For me - I found it detracted from my ability to actually grok what was going on. I have never liked "syntactic sugar" that abstracts away stuff you need to know. In my personal experience, I found it was an additional complication that made me write more code for no reason, and I found the abstraction more than doubled my debugging time just trying to resolve which function I was working with. UDFs were an added layer of complication I didn't need.
there are a few VERY good reasons to use UDF's, but agreed you shouldn't rename them thats just making it hard on yourself. My UDF's always exist out of prefix_functionName() where prefix is the lib, so e.g bot_PadStart() so i can always find the function and the lib its on. So that's a moot point.
Where its important is that it *can* save you a CODE level as the macro() roll option requires the introduction of an additional code level when you want to put an if() option in front of it. Granted I've found a hack to go deeper than 2 code levels, but I'd still prefer to omit it if possible. Next to that its just easer readable and cleaner code easier to debug :wink: The other good reason to use UDF's is that you can play with scopy (yes dangerous but sometime useful) AND you can ignore output (so you don't get those horrid blank lines :mrgreen: ).

On the topic of blank lines: not in theory but in practice. Only one [h:] in the outer layer is required. What people always forget is that <!-- comment --> is also output to the chat and usually the cause of the blank line! So indeed EVERYTHING requires a [h:] but with nestings, its enough to only do the outer part.

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

Full Bleed wrote:
Fri Apr 09, 2021 12:23 am
Sure there was.
...
Not sure where the resistance is coming from.
...
This most certainly would not be done without your "work around." You're just going to have to own this one.
I think perhaps we are talking at cross purposes here. The only thing I am resisting is misunderstanding. I guess it all depends on what you mean by "limitation" and "own". I disagree with the last point though, it most certainly could have been easily done by anyone, with virtually no code at all (like 2 lines MAX).

When I think "limitation", I think "the tool prevents you from doing so", not "kind of discourages you". If the tool had *actual* logic in place to prevent people from dropping either audio files or large binary files into the campaign (it doesn't), and I hacked my away around *that* - I would absolutely take responsibility for it, but I didn't do that.

Maptool allows you include arbitrary binary files in a campaign file, it allows you to play local sound files from a "file://" URI, it allows you to set a read only local file path accessible from macros (the FSD) and it allows you to get the asset tag of arbitrary assets with "getImage" (regardless of the name, which is semantics, not a limitation). As far as I see it - all I have done is push the boundaries of Maptool's inherent capabilities. I don't see the issue with that. If people don't want to use the JUH libraries, I'm not forcing them to. If the devs want to cripple their own product in response to me showing people how awesome it can be, I can't stop them. Would be sad though :(

Besides, weren't YOU the one encouraging me to ACTUALLY change the things you say are limitations? (e.g. changing the red X, adding import dialogs etc...) :P

Same thing with "own" - I think we're talking of different things. To me "own" means "caused and are responsible for". I will absolutely own the following:

-pointing out that Maptool allows you to include any asset you like
-pointing out you can get any asset tag with "getImage"
-pointing out you can use both to provide locally cached audio
-building a tool that uses the above to redress a shortcoming in Maptool

What I won't take responsibility for, is the fact that Maptool doesn't do anything to prevent you from dropping your entire life's photo album of images onto a campaign map and "blowing up your campaign file size". That was always possible and has literally nothing to do with me or JUH.

To me, it feels like I'm pointing out a pothole in the road, and you're telling me I that I must have caused it. I disagree, but hopefully that wasn't what you meant.
Full Bleed wrote:
Fri Apr 09, 2021 12:23 am
You needn't take it as a criticism.
I'm not, I'm just trying to be clear about what things I'm actually responsible for here.

Full Bleed wrote:
Fri Apr 09, 2021 12:23 am
But it's also pretty clear that using getImage this way was not intended. So while I don't want to see the ability go away, I think a more appropriately named and implemented function like getAsset (or getAudio) should be offered. The question is whether or not there is any additional functionality such functions should have.
I don't see being unintended as an indictment, more of a "bonus feature". It's not any more detrimental than anything else you can already do with other assets in Maptool, which is what matters in the end.

I agree though, a proper "getAsset" or "getAudio" method would be the correct way to go, and I would love it if it got implemented and made JUH obsolete. A simple "getAsset" that returned "asset://<md5>" for any asset would seem the simplest and most preferrable approach.
Full Bleed wrote:
Fri Apr 09, 2021 12:23 am
Not sure I fully agree with there not being "a single good reason"...
Don't forget the "why this should apply to audio and not visual assets" part! Everything you mention applies equally well to visual assets, but nobody seems concerned about people dropping their 2Tb photo album into a campaign, so worrying about people doing same with audio falls a bit flat on my ears.

I also find the idea that it's somehow the Maptool devs' responsibility to ensure that users can't "blow up their campaign files" to be patronizing and distasteful. It should not be the devs responsibility. If a group wants to play with a 2GB campaign file and they all have 500mb/s internet, who is anyone else to tell them their campaign file is "too big" and they shouldn't be allowed to do it?

I think we can trust users to not shoot themselves in the foot and keep their campaign file sizes reasonable, without imposing on them someone else's definition of what a "reasonable" campaign file size is.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

User avatar
JoeDuncan
Giant
Posts: 118
Joined: Sun Nov 22, 2020 9:02 pm

Re: Joe's Ugly Hacks 'Drop-in' macro libraries - v0.1 [alpha]

Post by JoeDuncan »

wolph42 wrote:
Fri Apr 09, 2021 3:14 am
Where its important is that it *can* save you a CODE level as the macro() roll option requires the introduction of an additional code level when you want to put an if() option in front of it.
Now that could be useful. Stacked "if"s are annoying.
wolph42 wrote:
Fri Apr 09, 2021 3:14 am
Next to that its just easer readable and cleaner code easier to debug :wink: The other good reason to use UDF's is that you can play with scopy (yes dangerous but sometime useful) AND you can ignore output (so you don't get those horrid blank lines :mrgreen: ).
Have to disagree on this one. I find UDFs much harder to read, debug and grok, and screwing around with scoping is extra complexity that is unnecessary when you can pass state around with tail recursive calls. I found it just added steps and time for no real benefit (that I could see at the time - deeper nesting could be useful so another look is warranted).

I generally find when most people say "more readable" they really mean "simplified so everything looks like a function call and I don't have to worry about how it works" - which is quite the opposite of what "more readable" means for me. I prefer my source to be as isomorphic to the underlying structure as possible, especially in cases of leaky abstractions like this one. Anything that obfuscates that, or makes two different things "look" the same hinders my ability to read and comprehend it.
"Joe's Ugly Hacks - Get 'em while their hot! Guaranteed ugliest hacks around or your money back!"

Post Reply

Return to “Drop-In Macro Resources”