Add dynamic media without loading from disk

[GoodClover]

Ready for review. Implements & closes #12755.

This PR simply adds the ability to send ephemeral media from a file already in memory as a Lua string. Rather than having to save it to disk, have the engine read it, and then delete it from disk again.

updated doc for dynamic_add_media in lua_api.txt

minetest.dynamic_add_media({
  filename = "foo.png",
  data = "<raw-png-file>",
  -- data implies (requires) ephemeral=true
}, function() end)

As a side-effect, this allows the following, which will read bar.png from disk but send it to the client as foo.png. You could add an error for this, but why remove a free feature that harms no-one?

minetest.dynamic_add_media({
  filename = "foo.png",
  filepath = modpath.."/bar.png",
})

To do

• Implement the thing.
• Error checking on table passed to dynamic_add_media.
• Documentation.
• Feature flag?

How to test

1. Download the mod test.zip
2. Check out init.lua, it's not long at all.
3. Load up a world, wait 1 second.
4. Observe an upright_sprite added at your location, both textures working.
5. =^)

[GoodClover]

This is my first time writing C++, so for now there's quite a bit of code duplication (two functions are copies of others with small changes) and I've been avoiding figuring out what combination of &*s I should have in arguments (passing by what I think is value presently).

But it works! Just the code needs tidying.

[GoodClover]

Shoot, misclick… checks thing disappeared and placed the button right below my cursor as I clicked, thanks GitHub.

[Desour]

Instead of copying here, you could use a const char * to the lua string, and the lua string's size, and pass that around.
Then you only have to memcpy the filedata once: When you put the string into the network packet.

In such cases I wish we had string views...

[GoodClover]

std::string_view is C++17 :(
Is changing everything to a const char * (+keeping track of length) really the only way?
Would require re-working addMediaFile, as that expects a std::string& which it can assign to, managing that's above my C++ knowledge.

[Desour]

If it's too much work, just keep it at copying into std::string.

[savilli]

Doesn't it still require to generate a unique filename? For me it looks like it doesn't solve much. If you already generated a filename, you can just save your content to that file.

[GoodClover]

Without a filename, the client and server have no common way to identify it, no way to tell it's type (MT uses file extensions), and no way for it actually get used anywhere.

This PR simply adds the ability to send ephemeral media from a file already in memory as a Lua string. Rather than having to save it to disk, have the engine read it, and then delete it from disk again.

[GoodClover]

Any features of replacing already sent media are unrelated & waaaay outside the scope of this PR. They would go quite nicely hand-in-hand with this however.

[GoodClover]

I would appreciate someone looking over the changes to lua_api.txt, as the explanation for dynamic media has got a bit long… which might be a sign the API changes themselves aren't so good.

[TurkeyMcMac]

filepath should be checked for emptiness like in the other branch.

[TurkeyMcMac]

What if someone uses data = ""? Won't that cause addMediaFile to try to read from filepath? IMO you should add a separate parameter to signal that filedata_to is an input, rather than checking whether it is empty. data = "" should be supported out of principle.

[TurkeyMcMac]

filedata is allowed to be nullptr in the header declaration, but here it seems it is assumed not to be nullptr.

[sfan5]

Do you plan to continue working on this?

[GoodClover]

I am not knowledgeable of C++ enough to work on it. I just happened to bash something semi-working together.