Command Computer frustration

I wrote a teleport program, and installed a command computer at all my cities / mines / castles / etc… I replaced all my wrapped command blocks and computers with a command computer, and changed all my programs to use "commands.exec" instead of "cb.setcommand" and "cb.runcommand". I tested everything, and it worked great… Until I switched to survival mode. [email="!#@$%"]!#@$%[/email]. message "you gotta be op and creative to use it". Is there a way to turn this "FEATURE" off? or is there a mod / tweak I can use to allow survival mode / non-op players to interact with my programs? I prefer they not be able to modify / create programs on it, but they should be able to click on it to run startup. after all, a non-op can click a button attached to a command block, even though they can't modify the command.

Thanks in advance. IBS

I've got a hunch that Dan never got around to making Command Computers immune to computer peripheral calls (though quite frankly, I reckon he should probably disable the shutdown and reboot commands, if they happen to be active).

Use monitors. This way you will not be directly interacting with the command computers, but will still be able to use them

infinitebrainspace, on 01 May 2015 - 03:05 AM said:

…

Not fully sure if I understand your setup. You are asking for interaction.
You can interact with them with redstone signals (e.g. pressure plate) or via rednet.

Creator, on 01 May 2015 - 03:01 PM said:

Use monitors. This way you will not be directly interacting with the command computers, but will still be able to use them

Oh, have to test this :)/>

this would work, except that the command computer will not auto-start when the chunk loads, so the user has to click on the command computer to get the startup program running which will then use the monitor. if the user is not op'd and not in creative mode, they can't click on the computer to start it, so I'm back were I started.
I have a discussion in both ASK A PRO and BUGS referring to computers not running startup at chunk load.

I just tested in my game world. I'm not able to reconstruct the behavior you are describing.
When loading my world in survival or adventure and the chunk of the command computer is loaded after this, it runs its startup.

Well, there is a small difference, because I created my world a creative world (using NEI I don't know if there is a difference).

You could try a chunkloader (spot loader), maybe this changes the behavior?

my setup is rather simple. I have several command computers in my SMP server world. Each one has a copy of a program called startup. a file containing the xyz coordinates, and the names of all the locations is read and displayed as a menu. click on a location, and you are teleported there. the interaction requires the command computer to be running the startup program, and the user needs to be able to click on the location they want to go to. As it stands, the user can not even get the startup program to run unless they are op + creative. This all works perfectly if you are op + creative.
There should be the following rules:
op + creative - command computer is available. create / edit programs / files.
op (not creative) - create / edit programs / files
non-op - initialize command computer (if no startup file, blank screen and no access to O.S.)

BTW The startup problem is only on server app. testing the chunk load on a local world will always work.

infinitebrainspace, on 01 May 2015 - 06:23 PM said:

…
BTW The startup problem is only on server app. testing the chunk load on a local world will always work.

Oh, then I'm also interested in a solution!

I could just go back to using an advanced computer, and wrap a command block to it. I was just trying to eliminate the need for 2 components. also, I like to use the return values from commands.exec(). I can determine who the user is, and whether they are permitted to go to certain locations. I can do this with the command block method, but it requires comparators, repeaters, and redstone dust, as well as much more wait time. and a much larger footprint at each location.

For my game world I could try to use command computer only in spawn chunks, but I have to test this.

it will work fine on your local world, but not on a server. the world spawn chunk unloads when all users are either in the end/nether or logged out. in other words, someone has to be on the overworld or the chunk unloads, and the computer will not "startup" when you come back to the overworld. note: it takes a few minutes before the world spawn chunk unloads after the last player leaves the overworld, so keep this in mind when testing. I've tried everything I can think of to get the computer to "startup" when the chunk loads, but to no avail.

also, if you shut the server down, and restart it the startup code will not execute even in the World Spawn Chunk. This was reported the BUGS forum, and hasn't been fixed yet (or maybe it will never be fixed).http://www.computercraft.info/forums2/index.php?/topic/21090-mc-1710cc-165-startup-script-not-executing-on-chunk-load/page__fromsearch__1

Bear in mind that bug doesn't affect "all servers".

These days I lean towards the idea that something goes wrong when the systems are unloaded, causing them to crash in a manner that shuts them down. They get saved that way in the world data, and when the chunk's reloaded, they remain as they were - shut down.

Usually I only encounter this if the server I'm playing on has actually encountered a program, eg it crashed, and I've personally never had a situation where it occurs every single time my computer's chunks are reloaded. I see this maybe once every few months. If that.

If I did have such a problem on a regular basis, I'd be taking a look at which computers were affected, what peripherals they were using, which peripheral mods were installed, what the server logs have to say about it, and so on. Knowing the actual cause would go a long way towards any potential fixes.

again, I was told this is a bug (talking about the startup script not running). No peripherals, nothing in the log files - because nothing crashed. The server is working as it should. The startup code simply does not execute at chunk load. Maybe some servers are running a mod that forces the computers to "startup", but that's a different scenario. vanilla minecraft (forge) with computercraft. nothing else. In single player (local PC) The computers run the startup script as expected, but on a server they don't. Mr. Bloke, I know you followed the posts regarding this problem, so I don't have to explain the whole scenario to you again. This thread is mainly about the command computer, and the restrictions put on a non-op survival player not being able to interface with it (start it up and use the programs on it). I have conceded the fact that the startup code wont run, and write most of my code with that in mind - however it has no bearing on the problem with command computer non-op interface.

infinitebrainspace, on 02 May 2015 - 07:52 PM said:

again, I was told this is a bug (talking about the startup script not running).

The point I'm trying to get across is that it doesn't affect every server. I'd go as far to say that worlds which are affected are in the minority. No, there are no mods which "force" all ComputerCraft systems to boot; there's something special about servers where they don't, and only people with access to such servers are likely to figure out what that is.

Bugs which have no known triggers are harder to isolate and therefore fix. I'd be taking another look at those logs, for example - you're keeping in mind your server doesn't just log crashes?

infinitebrainspace, on 02 May 2015 - 07:52 PM said:

I have conceded the fact that the startup code wont run, and write most of my code with that in mind - however it has no bearing on the problem with command computer non-op interface.

In that case, to be absolutely clear, only OPs in creative mode may directly interact with Command Computers. The "option" to give your players the sort of OP-command access that Command Computers provide is to specifically put them into a position where they themselves can execute OP commands via chat, too. There isn't a "secondary toggle".

This is a major downside of wrapping command blocks as peripherals - if that option is available on a server, and command blocks are accessible to players, then non-OP players with half a clue about ComputerCraft can do most anything they like. They just hook up a computer they have control over, and start running commands.

So:

If you want indirect access to a Command Computer, then use a monitor, redstone inputs, or something like nsh.

If all you want is for people to be able to turn the things on, then I gave you your answer way up at the top of the thread.

My book
Title: Command Computer - is it what we expected?….Really?

Preface
In respectful response to Bombe Bloke

Chapter 1 The monitor peripheral

I did test using a monitor, and there are some small changes I have to make, like the y position of the monitor-touch seems to be off by one compared to the mouse-click, and I haven't tried any text input on a monitor yet, but I don't think that's a problem.
Assuming I will never figure out why my server doesn't auto start CC computers, I still have to deal with the problem of a non-op, non-creative player not being able to activate a command computer even if it is attached to a monitor (it has to run a program to connect to the monitor).


Chapter 2 The really cool, but almost useless Command Computer

Since the restrictions on the command computer are both OP and Creative, I will combine the two into "O/C" for discussion purposes.
I don't want to give users OP-level access to the command computer. I thought a non-O/C should be able to at least cause it to startup, and execute only the startup program if it exists. This would be similar to the existing command block - in that a non-O/C can look at the command and execute it, but they can't change it. It would be much "safer" than having command blocks connected to (potentially) many computers throughout a world. If a command computer (with the suggested change) were clicked on by a non-O/C player, it would either execute "startup" if it exists, or simply display "You do not have permission to use this computer". If startup script is executed, any interface the program requires / allows would be valid, and the non-O/C player would be able to Click / type accordingly. If the user terminates the program, the "you don't have permission" message would appear. If the program crashes, (of course mine never do ;)/> ) the same thing. I don't have a big problem with requiring OP and Creative for obtaining / programming command computers, but it seems that If you are OP, you can easily switch gamemodes, so why require both - other than it adheres to the command block's permission requirements.


Chapter 3 That darn startup / chunk load thing again.

in regard to not all servers having the auto-start problem, I would be interested in what they are doing different than I am. windows server 2003, 8g ram, solid state drive, single processor (6 cores), minecraft 1.7.10, CC 1.73, forge 10.13.3.1360. Are there any CC config options that might affect this?

Chapter 4 Post unload crashing

I just re-read one of your posts above. I misunderstood you when you said "when systems are unloaded". I thought you meant Chunk is unloaded (which is close to the same thing). I guess if the code was in a loop (waiting for redstone signal or for a user to get within range, etc.), and the host chunk unloaded, the program would be in a potentially unstable state (loop counter might be lost, or a null value might be returned from a no longer available api call) This may (guessing here) cause the program to "crash" during the chunk unload process. However, I would assume it would still "startup" normally when the chunk re-loaded - unless the crash was so severe it physically performed a "shutdown". With that said, on to chapter 5.

Chapter 5. What I have now

I have several computers running different "startup" programs, some of which prompt the user before they actually "do" anything, and some that auto open doors or turn on a light when someone gets within a specific range. In my case (on my server), the ones that need to be actively running without user input, do not startup when the chunk loads, but do as soon as a user clicks on them. As you can see, I don't need an auto door, or auto light switch, if the user has to click something to activate it. Using command blocks wrapped to computers would work (if the auto-start also worked), but the amount of space required to facilitate that interface (and get a result from the command block) is not as desirable as a simple command computer (not to mention the player that has a clue about CC and command block peripherals).
On the other hand (again where the startup does not work) where user input is needed to continue ("Please Click on a Destination"), It would be advantageous to allow the startup program to execute when a non-O/C user clicks on the Command Computer.

Chapter 6 Conclusion

I am suggesting that the following be addressed in a future CC release / patch.
Pertaining to non-Op / non-Creative "players" and Command Computers:
Similar to a command block for user interaction: can't modify it, can't do anything with it except click on it
Similar to a command block in functionality, but instead of a button attached to it, clicking directly on the command computer would display the running (startup) program, or execute the "startup" program if not already running.
Similar to a command block, a user could look at the interface, however with the command computer, the (Op / Creative) programmer would design the interface (startup program), and execute commands based on the users interaction with that interface. A "player" would at no point be able to access the O.S.
afterthought: after displaying a message of "you don't have permission to use" in case of crash / termination, the computer should reboot and execute the startup program.

I dedicate this book and its many pages to Bomb Bloke, for his insight, wisdom, and of course patience.

IBS.

Two things you're forgetting:

1. edit and lua are both programs — you want non-OP players to be able to use the computer but only be able to run programs, with these two programs they'd be able to do anything they desire with the computer;
2. Computers are multi-user — how should the Command Computer behave if an OP and non-OP player are using the computer at the same time? Computers don't know who is using them;

It should be noted that with a little effort almost anything is possible. For example you could have a startup script on a command computer, and have a advanced computer hooked up via wired network to the command computer.

By doing this you can do the following:
1. Turn the computer on (will run the startup script)
2. Reboot the computer (will rerun the startup script)
3. Setup a network using the modem api, where you can run presetup programs remotely (this will accomplish whatever you are wanting, not to mention something like this is only around 50 lines at max).

It all boils down to the amount of effort you are willing to put into the system.

With that said, the problems with implementing the things you mentioned is as theoriginalbit said, CC is multi user. Handling multiple people accessing the same computer would become far more complicated than it needs to be.

Your startup script problem is one I have really only seen on cauldron servers running CC versions prior to 1.7. Since 1.7 came out I have not seen startup scripts not boot on computers in any of the many servers I occasionaly visit.

edit:

infinitebrainspace, on 01 May 2015 - 06:00 PM said:

this would work, except that the command computer will not auto-start when the chunk loads, so the user has to click on the command computer to get the startup program running which will then use the monitor. if the user is not op'd and not in creative mode, they can't click on the computer to start it, so I'm back were I started.
I have a discussion in both ASK A PRO and BUGS referring to computers not running startup at chunk load.

As for this problem a way to solve this is to have another computer right beside the command computer with this:

peripheral.call(side,"turnOn") --#where side is the side the command comp is on

I personally would name it startup, so the second the normal comp is turned on it boots the command comp.

infinitebrainspace, on 05 May 2015 - 03:37 AM said:

the y position of the monitor-touch seems to be off by one compared to the mouse-click

That shouldn't be the case. Targeting certain x-positions can be a bit buggy, but issues with y-positions are a new one on me. On the other hand, odds are the same bug affects both axises…

infinitebrainspace, on 05 May 2015 - 03:37 AM said:

Assuming I will never figure out why my server doesn't auto start CC computers, I still have to deal with the problem of a non-op, non-creative player not being able to activate a command computer even if it is attached to a monitor (it has to run a program to connect to the monitor).

Personally - again, working under that assumption - I'd probably find myself sticking regular computers everywhere, and just having one single command version, rigged to fire off specific commands whenever it receives certain wireless modem messages.

This is somewhat more viable than the "hook all your systems together with wired modems" route, as at least you can go wireless. A few systems up at world-height running the repeat script would help with any range issues, assuming you don't just increase transmission distances via CC's config.

Though I wouldn't be inclined to assume such. Automatic startup works for most other people, I'm sure it can be made to work for you.

infinitebrainspace, on 05 May 2015 - 03:37 AM said:

I thought a non-O/C should be able to at least cause it to startup, and execute only the startup program if it exists.

Unfortunately, as BIT points out, computers are currently unable to determine who's interfacing with them. Just to be clear, though, that wouldn't be simple to change; it'd require quite an overhaul of the mod to implement - the MineCraft server would need to check the events coming in from the client in a new way, and CraftOS itself would need to be rigged to deal with that as well. Even just "you can see the display but can't interact with it"-type access is easier said than done. I'm afraid this affects the majority of your "conclusion" list in quite a negative manner.

infinitebrainspace, on 05 May 2015 - 03:37 AM said:

in regard to not all servers having the auto-start problem, I would be interested in what they are doing different than I am. windows server 2003, 8g ram, solid state drive, single processor (6 cores), minecraft 1.7.10, CC 1.73, forge 10.13.3.1360. Are there any CC config options that might affect this?

The config's one possible avenue worth exploring; as far as I'm aware, the servers I've played on stick to the defaults there (with the exception of the http whitelist, in some cases).

I wouldn't consider the hardware or OS specs to have much to do with it, though the Forge version may be related. May not hurt to try some different versions (including older ones).

But before that, I'd be moving the world-save to the side and doing some trials in a new one with just a computer in it. No peripherals - that means no monitors, disk drives (with or without disks in them!), printers, modems, whatever, just the computer.

By the way, one thing I've never been clear on, do you find this effects systems every time they're chunk loaded, or is it only when they're first chunk loaded after a server reboot? For example, if you teleport off to the nether and come back, do your computers reboot as they should, or are they all turned off when you return? I'd be running a computer at spawn (which is always chunk loaded so long as the server is running, no matter where players go) to compare against, both when restarting the server and when jumping between dimensions.

infinitebrainspace, on 05 May 2015 - 03:37 AM said:

I have several computers running different "startup" programs, some of which prompt the user before they actually "do" anything, and some that auto open doors or turn on a light when someone gets within a specific range.

How are you doing your sensing, by the way?

This effects all chunks whether server boot-up, or I just leave the chunk and come back. It happens every time. I can remember one case, where some rouge turtles took off digging when the chunk they were in loaded, but that was one time only (that I know of).

the sensing is done by using "testfor @p [r=4]" (This may not be exact, but I'm at work now and cant look at my code)

The command block is wrapped to the computer, a RS comparator is pointing away from the command block - that feeds a RS repeater - which powers a RS dust trail to side-x of the computer.
I wait (sleep(.2) for the redstone components to have time to ignite, and test for redstone on side-x. succeed or fail, I always force the redstone off by doing a "testfor poop" command.

As you can see, a Command Computer would (and does) simplify this quite a bit. There is no delay between executing the command, and getting the results. There is no need for a 3x6 building made of bedrock behind the computer to house and protect the redstone components. I would like you to see my inventory system, experience-banking system, enchantment process, and teleport system. I'm not trying to impress anyone, but it would help you understand my frustration. At this point, it all works without the command computer, but it could work much more efficiently with it. I even have a teleporter that teleports me from the overworld to the nether - and back. (you would need to see it to understand how it does it.)

Bombe Bloke, I'm sending you a friend request, so I can give you the IP information for my server. If you want.

Sounds good, we'll see what we can arrange.