Command Computers do not boot startup.lua from disk as documented in original ComputerCraft
TheMindVirus opened this issue · 3 comments
The original documentation states that Command Computers shall not boot startup.lua automatically from disk drive.
Original Documentation: https://computercraft.info/wiki/Command_Computer
This causes problems when commanding them using remote procedure call programs over the network with inconsistencies.
Modems are also not allowed to call functions remotely on the computers without remote procedure call programs over rednet
which never start because the boot program was never called for cluster units in device firmware upgrade (DFU) mode.
The temporary solution is to allow Command Computers to boot automatically from the most local disk drive as normal.
The more permanent solution is to make a new type of computer called the Cluster Computer which has the new textures and is configured to allow calling methods over the network from new types of device called Router and Switch.
A Cluster Computer is built on top of a Command Computer to allow startup disk booting and calling methods using Modems.
A Switch is built on top of a Wired Modem to allow calling methods on Computers with peripheral.call(...)
.
A Router is built on top of a Switch and adds a built-in Computer to configure the Firewall to filter messages from any source.
A Wireless Router is built on top of a Router to allow Computers with Wireless Modems to connect in Infrastructure Mode.
Configuration options to enable the usage of the newly proposed blocks should be added
but not to toggle the presence of the block itself as this would cause world loading errors.
Documented Further: https://github.com/TheMindVirus/CC-Modded/tree/main/usage#hidden-settings
A new alpha version may be created by editing the .jar with 7-zip to edit .jar/data/computercraft/lua/bios.lua
to completely ignore the shell:allow_disk_startup
setting and force it to true
.
This would need to be patched out again in a future release and is untested.
-- Load user settings
if fs.exists(".settings") then
settings.load(".settings")
+ settings.set("shell.allow_disk_startup", true) --override
+ settings.save()
end
The above patch did not seem to work but was actively being checked for syntax errors.
The following patch to .jar/data/computercraft/lua/rom/startup.lua
may be required:
-- Run the user created startup, either from disk drives or the root
local tUserStartups = nil
if settings.get("shell.allow_startup") then
tUserStartups = findStartups("/")
end
+if true then --if settings.get("shell.allow_disk_startup") then
for _, sName in pairs(peripheral.getNames()) do
if disk.isPresent(sName) and disk.hasData(sName) then
local startups = findStartups(disk.getMountPath(sName))
if startups then
tUserStartups = startups
break
end
end
end
end
if tUserStartups then
for _, v in pairs(tUserStartups) do
shell.run(v)
end
end
This patch worked successfully, allowing a Command Computer to boot from disk.
It is by no means a permanent solution and the whole game should be rewritten
from scratch in Python in spite of the awful compilation process it currently uses.
setting default_computer_settings = "shell.allow_disk_startup=true"
, or manually enabling shell.allow_disk_startup
on your command computers, should do precisely the same thing.
the reason this is disabled by default on command computers is because it creates a massive security hole: all a user has to do is place a disk drive next to a command computer and insert a floppy disk with some malicious code, then reload the chunk. with the option disabled you have to be in creative mode to obtain and use them.
modems calling functions on other computers without an RPC program of some kind is disabled for similar security reasons. surely your DFU mode can implement an RPC interface?
also, everything you're doing with this mod could be done better as a separate addon mod for CC:Tweaked - which decreases the amount of work you have to do; as-is, rebasing your changes on later commits from the main CC:T repo will be very time-consuming.
(now, if you're just using this for one or two singleplayer projects that's fine; if you intend to release this to the wider public (as it seems you do) then i suggest addressing these issues very quickly.)
I'm not sure why but it didn't work for me. This is just my version which also happens to be public facing. I also intend on keeping it as stable as the original seems to be kept, issues and all. There may be a better version to be had but a lot more has to change for that to happen.