BatchExec

[NiLSPACE]

Those path's don't work for me

[xoft]

Don't work, as in they don't open the file at all, or they don't get through the filter? I think they should work, there's nothing irregular about them.

[NiLSPACE]

They don't open the file. Though all this is pretty easy to resolve. We just say that people can only use filenames, not paths as an argument, and keep all the batch files in a specific directory. Then we just use 'if (not FileName:match("^%w+%.%w+")) then'

[Zee1234]

SQLite with colums "id" "name" "permission" and "commands" would have a similar effect to an Ini that goes like:

[name]
permission=
1=
2=
3=

But the Ini would be editable from out of game. It could even be loaded into memory in table form during initilization (instead of reading it during execution) and then executed with a for loop. It should be secure as they don't name a file but a key.

Although be wary that a similar plugin for bukkit/spigot has some users that define hundreds of new commands.

I just finished my plugin that stores button information in an ini file and then loads that into memory when it's initialized, then writes back out on disable. I'll see if I can't make a mockup of my idea in a bit, although bugtesting and releasing a my code will take priority.

[NiLSPACE]

The problem with ini files is that they're really slow, especially with larger files. Also, this plugin isn't about creating new commands, but for allowing a user to execute multiple commands automagicly. This would reduce the amount of steps in some scenarios.

[Zee1234]

So with SQLite, would you only allow x number of total commands and make that many columns, make 1 commands column and store them like {command one}REALLYGOODSEPARATORHERE{command two}..., or when a new one is defined, would you read the number of columns currently in the table, subtract by the number of non-command columns, and then if that # < number of commands in new command, ALTER the table and add a new column? The last 2 offer the most flexibility, and the last one is probably the best, but I don't know anything about the SQLite implementation in Cuberite.

Also yes Ini's are slow but you could still only interact with them during initialization and disable (or if you have reload commands). The reload commands could get really long, but they are an optional thing so the owner will learn when they can and cannot do that. LOL IGNORE THIS

I just tried a 250 key ini file with 7 values per key. Using the LIP library (I gave up trying to get the Cuberite cIniFile stuff to work about 12 hours ago), it loaded the file into a table in < 1 second. Literally. I had it then write out to a different file. It wrote out in < 1 second. That's far from slow. I couldn't even see the difference between the LOG's "Begin parse of sample.ini" and "Parse Complete". They popped onto my screen at the same time as
[02:40:16] Begin parse of sample.ini
[02:40:16] Parse Complete
[02:40:16] Initialised BungeecordTeleButton v.1
[02:40:16] Plugin loaded
So yeah. Consider using INIs.

https://github.com/Dynodzzo/Lua_INI_Parser <- LIP library btw.

[NiLSPACE]

Or I could think of my own format.

Code:

<BatchName>
<Tab> <Command1>
<Tab> <Command2>
<Tab> <Command3>
<OtherBatchName>
<Tab> <Command1>
<Tab> <Command2>

Ini files are used as configuration file, not as as a database. If we'd put everything in a table we could as well create our own file format.

Also, with SQLite it's pretty simple to allow an unlimited amount of commands. Consider this table format:

Code:

Batches
BatchName | BatchID

Commands
Command | BatchID | OrderVal

We'd simply put all the commands in a different table. Then we find all the commands by the BatchID and sort them by their Order. A lower order means it will be executed before the commands with a higher order. Here is an example SQL statement. It might not be valid, I've written it from the back of my head.

Code:

SELECT Commands.Command FROM Batches, Commands WHERE Batches.Name = "BatchName" AND Commands.BatchID = Batches.BatchID ORDER BY OrderVal;

[Zee1234]

Very true. I was just suggesting ini because it already has a library to decode it (as well as the cIniFile class). Making your own syntax (by the way you're a colon and two spaces away from YAML) would work just as well and it would be largely preference between the two (right?).

And I didn't even THINK of using multiple tables. That would make it a lot easier. Although there is still the issue of it only being editable in game OR through SQL.

[NiLSPACE]

We could add a page to the webadmin to make it editable from outside the game. ^^

[Zee1234]

I keep forgetting that the webadmin exists. I've yet to do anything with it. Yep, that would work well.