Questions for human beans.

Is it possible to use plotscripting to load local files into a game? Maybe like this:

Where 3 is the song number in the editor.
Or for graphics:

---

Sent from my iPhone

No. Hamsterspeak doesn't even support strings as function parameters.

---

Mega Tact v1.1
Super Penguin Chef
Wizard Blocks

What were you hoping to use that for?

Well, I was hoping going to give the player in the game an MP3 Player (more like ogg player), and the player could put custom music files in it to play during the game. Or maybe one could use it to make "texture packs" for OHR games?

---

Sent from my iPhone

First: I'm sorry but why wouldn't a player just play their own music and mute the game? No programming necessary and it's already available on all OHR games.

Second: Texture packs for 2d games aren't a thing.

/thread

Those were just examples. A game that could be customized with outside resources would open up many new possibilities.

---

Sent from my iPhone

I agree with this sentiment. Or, if not reading files from game.exe's directory, at the very least being able to create persistent metadata that could be used for things like new game +. Or bonus features/areas if you replay the game after certain conditions are met in a prior playthrough.

As far as implementing something like that goes, I have no idea how easy or difficult (or possible) it would be for OHRRPGCE.

Most of that stuff is trivial through globals, save files, and read/write globals.

Actual files though, not so much.

You could, in theory, design some stuff that players could input to the game by creating an editor that writes save files with globals, and then doing something with those globals. But... you're probably better off using another engine at that point.

Who wants to rewrite CUSTOM in GAME? :P

To expand on Mystic's answer, you can store data in a hidden save slot (script commands can access up to 33 save slots regardless of the number visible on the save/load menu) by using the importglobals and exportglobals commands.

However, it would be nice if you can read and write text files especially with scripts. There are lots of uses, from log files (you can use the trace command though) to character dumps and high score lists to adding some kind of level editor to a game, while being friendlier to edit by hand or copy between computers than a save file (and not having to overwrite some other save file).

Importing/exporting some other file types could surely be useful too. Probably mainly graphics: for the likes of Stampo!, OHR Pal (or maybe OHR Paint or Toy Town).

And no, it wouldn't be difficult to implement this sort of thing, except maybe for how graphics would be imported (overwrite existing?), but adding a set of file operations is a big step, and I have to wonder what the interface would be. A function to return the nth line of a text file? One to open the file browser and search for graphics files?

Though I can see some stuff you can do with these types of functions I don't see the need and I think implementing a function like this would largely be a waste of time. Everything you can do with the function can be done other ways. Not to mention that most of these other ways would be less complex.

Dang. I did not even know about this. I'll have to look into it in detail some more at some point, thanks for the heads up.

Comparing against other features we could be implementing instead, I think reading/writing text files doesn't compare that badly, though it's certainly not a priority. I disagree that you can always just use save slots instead. Being able to importing graphics at run time is admittedly much less useful.

Can not strings and slices already be saved? Can not a string be nearly infinite in its length? Can these facts not already be combined to export/import text? As the only OHR Developer to TWICE make a word processing program, I call talk of this new feature frivolous. And I intend to prove it.

The major function that TMC is suggesting is basically having the ability to have a second text-based save file.
It's a bit funny how TMC is suggesting something almost completely different from the original intent. I can actually think of some good uses for TMC's suggestion.

Apparently still too controversial.