525 replies to this topic

[dan200]

MKlegoman357, on 03 February 2015 - 07:12 AM, said:

You can either pass it as a string or use the new textutils.serialiseJSON( table ) to convert a table into JSON.

EDIT: example:

local parameters = { Invulnerable = 1 }

local paramsJSON = textutils.serialise( parameters )

commands.summon( "Cow 15 75", 50, paramsJSON ) --# yes, you can put all arguments into one string

You can also just pass it a table, it'll call serialiseJSON by itself

[Thatparadox]

MKlegoman357, on 03 February 2015 - 07:12 AM, said:

You can either pass it as a string or use the new textutils.serialiseJSON( table ) to convert a table into JSON.

EDIT: example:

local parameters = { Invulnerable = 1 }

local paramsJSON = textutils.serialise( parameters )

commands.summon( "Cow 15 75", 50, paramsJSON ) --# yes, you can put all arguments into one string

Oh wow, yeah ok I didn't realize you can just put a string in there likecommands.summon( "Cow ~0 ~0 ~0 {Invulnerable:1}" )

Thanks for the help!

[Bomb Bloke]

awsumben13, on 01 February 2015 - 06:42 PM, said:

I've also done some testing and found that running commands causes a coroutine yield, so by running every command in an individual coroutine you can get some decent building speeds. Not sure if this puts a lot of strain on the server, but running ~100 at a time would be fine I'm sure.

Running setblock in async mode seems to run pretty much instantly, in server terms... so long as the target block is already the same as the requested block, and the default "replace" action is in use.

Spamming actual change requests that have to be actioned, on the other hand, causes a bit of... stutter, shall we say. A hundred blocks at a time isn't anything to write home about, but I accidentally spammed about 200,000 changes to stone, and it took five or ten minutes before my game's framerate came back up from 2FPM and I could access the computer's interface again...

What surprised me is that the yield protection didn't kill it. In my prior tests I found that async will trigger yield-related crashes if "miss-used", but in the above example it didn't. I guess the game's tick rate fell as well, and so as far as ComputerCraft was concerned nothing was wrong. The commands would've all been passed to the server side by then anyways...

Speaking of async commands, I did see execAsync when I first looked at the help!... Then promptly forgot about it, as I tried to work out how command blocks work. I've never played much with them, nor with server commands in general, really. Still trying to work out if there's a way to read signs or check chest contents. I get the impression there isn't.

Anyway! I've tightened up the scanning script a bit. Although reading in world data is still quite slow, it can now viably handle much larger structures:

pastebin get pXjdQDf6 worldporter
pastebin get cUYTGbpb package
package get PVu6C3qc
worldporter build BBCastle 54

[dan200]

Hmm, I could probably forcibly yield even in the async case if the size of the task queue rose beyond 1000 or so. shouldn't break too much

[Bomb Bloke]

Ah, this is what I'm saying - it seemed it didn't need to yield despite executing for far longer than ten seconds. My assumption is that ComputerCraft treats "ten seconds" as "200 server ticks", so if the server tick rate drops, then the script can run much longer without issue. Making async yield won't change any of that, and really I don't think there's anything to "fix" there.

[dan200]

yes, but if it yielded, you wouldn't get 200,000 commands executed in one very long tick, you'd get 100 each tick for 200 ticks

[Bomb Bloke]

Given that yielding doesn't take a tick, and that CC code can execute over multiple ticks without yielding, I'm... completely lost. Are you talking about waiting on a delayed timer event or something, in the manner that sleep does?

If that's it, then I'm not really in favour of the idea. Seems to me that much of the benefit of using async is that you don't need to worry about it yielding - making it do so under "some conditions" complicates matters. Leave it up to the script author, I say - if they have access to the command in the first place, it's a fair bet that they're high-ranked enough on their server to be trusted to use it, and even at 100 commands a tick any mistakes are going to execute far too quickly for anyone to prevent them.

[dan200]

yes, i meant yield and then resume once the queue had reduced to a manageable number (which will happen when the task queue has been emptied, which is once per tick).

now I think about it though, I don't have to yield when the command is being queued up, i just have to limit the rate that commands are executed to X per tick

[Bomb Bloke]

commands.list() seems a bit... odd. Putting aside that it seems to be there instead of the "list" server command, if I dump its output into a table, then table.sort() won't work on that table (no errors, but the content remains in the same order). Manually copying each index into another table results in something that can be sorted, but I've got no idea why this extra step is necessary.

It also mentions the "help" command, which doesn't have a respective function in the "commands" table (unlike all the other entries). This can still be ran with commands.exec() of course... but it only returns "true", making it seemingly useless. "seed" also only returns true. Where's the command output go?

Then there's the "forge" command... can't find any documentation for it, and I couldn't guess the correct parameters for it. What's it do?

[Xukkorz]

Is there a possibility of increasing range on wireless transmission for wireless modems wrapped to command computers? If not that then maybe "command" or "Admin" versions of peripherals that have extended functionality for mapping. I want to use them for a custom map but the range limitation is hard to work around and while having Skynet in Minecraft seems good its probably a bad idea.

[Lyqyd]

The modem range is configurable, which may be useful for your custom map project if you're shipping the mod configs as well.

[Bomb Bloke]

Since you mention it, how about letting Command computers re-write ComputerCraft's config values (even if the changes only apply to the current world, and then only until it's restarted)?

It'd also be nice if they could mount the drives of other computers, and re-write them remotely. You'd need a way of getting the ID of remote systems, though...

Come to think of it, if such a thing were implemented then an "adventure mode" computer would go hand-in-hand with Command computers. A system which won't boot from floppy, and doesn't have built-in access to the "edit" or "pastebin" scripts.

[immibis]

Since command computers are admin-only, what's the reasoning behind restricting the rate commands can be run at?

[Cranium]

immibis, on 05 February 2015 - 09:33 PM, said:

Since command computers are admin-only, what's the reasoning behind restricting the rate commands can be run at?

That's just limited by how fast the computers can run period.

[Thatparadox]

not sure if this is a bug or I'm just being an idiot. Every computer is telling me I "must be an OPPed player in Creative mode" when I try to look at them (not turtles) like when you try to look at a command computer. This still happens when I create a new map in any game mode. Is it something I'm doing or should I submit a more detailed bug report?

[Bomb Bloke]

Sounds like that'll already be fixed for the (as yet unreleased) pr4.

Cranium, read further up the page to see what immibis is talking about. Personally I don't so much mind the idea so long as it doesn't trigger a yield. Spam too many commands per tick and the whole server chugs. I'm sorta on the fence though; I'd imagine that making the server chug gets the job done faster. Hrm.

Edited by Bomb Bloke, 06 February 2015 - 12:02 AM.

[Lyqyd]

I'd agree with Dan on this one. You don't really want to have your mod kill the tick rate if it doesn't need to, and from what it sounds like, doing fewer commands over more ticks may not even be slower, which makes it the better option in my opinion.

[dan200]

New version in OP

[MKlegoman357]

dan200, on 08 February 2015 - 08:58 AM, said:

New version in OP

You've put the 1.64pr6 version of ComputerCraft, not 1.66pr4!

[dan200]

Haha! my bad. Fixed