Athough I did not know about the computers' on/off status I can tell that the computer was definitely on each time before unloading. I did not check the computer itself, but the monitors it directs output to: Text on monitors is updated (program is running).

When I logged in this morning, the computer was not running. I had to right-click to get the start script running, but then again, after I restarted the Bukkit server and logged back in, the script started just fine without any interaction.It's really strange, i just can't pinpoint the exact circumstances under which this happens.

What do you mean by "on"? Aren't CC computers always sort of "on"? I can tell that the startup script didnt execute when the chunk loaded, otherwise there would be output on the attached monitors.
When I richt click the computer, i see the CraftOS string and shortly after the startup script executing (which should have already happend on chunk load).

Hello there,

I encountered the problem that under certain conditions (which i was not yet able to determine) the "startup" script in a computer's HDD root directory only runs after i right-click the computer to open the console.
The script is to ensure that the progam is always running when the chunk the comuter is in is loaded. The computer is running on a Bukkit server within a chunk which has a rather complex layout: lots of redstone circuits and machinery with chunk loader. The computer has 3 redstone bundled cables, a wireless modem and 1 peripheral cable (Xfel's peripherals) with 4 monitors and 5 digitals chests connected to it.

My question: Is this a known problem (possibly with a solution) or should I invest more time in finding the cause for it?

I don't need instructions on finding out whether this is caused by a 3rd party mod, I just want to make sure this is not an already known problem.

Cheers,
Umpani

Thanks Coudy, i appreciate this insight into CC's internals. It's useful info: A state save should occur as soon as possible after an event is received to minimize surprises like rogue turtles forming skynet and seeking world domination or your piston printer wasting all your precious wool on 10.000 copies of creeper-butt />

Cloudy, on 07 September 2012 - 06:06 PM, said:

0.05 seconds is a very long time for a CPU, that should be enough, but it raises another question: is event handling synchronous with ticks, meaning that i get an event from pullEvent() roughly at the beginning of a tick?

Your help is appreciated, craniumkid, but just saving the state is not my problem. It's saving the state reliably. When doing

changeState();
saveState();

there is no guarantee that the state is actually saved, because the execution could have been terminated right between those two statements. When changeState() changed something in the world, the program has no way of knowing about this change after restart just by loading the state from a file. It takes some kind of sensory input, like a redstone current. I'm probably a bit too anal with this matter, but i dislike writing programs which only work most of the time by design />

P.S.: About the machine i'm using, its a CC controlled nuclear plant with 4 six-chamber reactors. The program controls the flow of SUC and replacement of reactor components and uranium/isotope cells based on a reactor layout which can be defined for each reactor.

Thats regrettable, because it makes reliable state saving impossible. With the machine I'm currently working on i can circumvent the problem by reading the state from redstone input, but some sort of locking mechanism to postpone program termination until the state has been saved would come in handy someday. I'm not comfortable around machinery in indeterminate state. Especially when it has the potential for violent existence failure />

My apologies if this topic has already been discussed, i failed to find the relevant information in the forums.

I'm interested in whether a program can be interrupted at just any point or are there some sort of guarantees, like at the next pullEvent() or when a function returns?

Thanks in advance,
Umpani

Xfel, on 28 August 2012 - 05:39 AM, said:

How does the special items list work? I've seen the entry in the config file, but i'm not sure what its format and its effects are (sorry if i might have overlooked this information in the documentation you provided).
Eureka! The special items allowed me to circumvent the problem with the empty names! I'll have to enter the items manually in the config file, but at least they get reported now />
In case anyone is interested in the solution:


Concerning the exact list of items: Checking the items manually would be tedious (> 800 different items to check), but i can give you some more examples (all items from IC2, not encountered any items from other mods yet with this behaviour, item IDs might differ from default IC2 install - to resolve conflicts):

Format: Display Name (ID xxxxx) - class name (is that a class name? got it from a NEI item dump)

Uranium Cell (ID 30207) - item.itemCellUran
Tin (ID 30247) - item.itemIngotTin
Copper (ID 30248) - item.itemIngotCopper
Lava Cell (ID 30236) - item.itemCellLava
Water Cell (ID 30218) - item.itemCellWater

when iterating over inventory with

for _, stack in inv:list(true) do ...

the variable 'stack' is nil for inventory slots containing any of those items. Further:

db.getItem("Uranium Cell") returns nil
db.getItem("item.itemCellUran.name") returns nil

For any of the items i listed (not just uranium cells).
I hope this info helps. The real problem isn't that the display names don't work propery (i wouldn't have bothered you if it was just that), its that not even the names like 'item.itemCellUran.name' seem to work for those items.

If you're really willing to attempt a fix, you might want to try using a string with the item ID as fallback if even item.itemCellUran.name isn't available as item name.

Concerning Cricket's post: Being able to access items by ID rather than their name would indeed have an advantage: Item IDs are unique, while (display) names aren't. For example, i have 3 distinct items in my combination of mods which have the name "Wrench". One BC "Wrench" (item.wrenchItem), one IC2 "Wrench" (item.itemToolWrench) and the one "Wrench" from forestry (item.wrench). I'm not sure how ARP handles this, or if there is a way of distinguishing those items (what will db.getItem("Wrench") return?).

Cheers,
Umpani

I would like to do that, but the inventory interface doesn't return a stack object for the slots in question: inv[i] and inv:list(true) both return nil.
However, some IC2 items do work, having a name like "blockMFSU.name" and returning a stack object, while others don't (uranium cells).
When abusing your low-level calls like

local item, count, dmg = peripheral.call("left:blue", "getInventoryContent", i, nil)

i get correct count and damage values, but a nil item. At least i can detect that the slot is not really empty this way ;-)

Umpani

That's a bummer. I guess there is no way to do some sort of raw query of the chest which gives you just item ids and damage values without having you to modify the code? If not, nevermind, my remote access warehouse clerk will just have to remain half blind for a while longer. Btw., the display item names are a featue i particularly like about your mod. They're what players know items by it makes it easy to find what they're looking for in a lua program for example.

Umpani

Thanks for your efforts on the Bukkit Version! The cables seem to work fine now.
Unfortunately I encountered another slight problem: It seems like some items are not reported when iterating over the contents of a digital chest. So far i observed this behaviour only with IC2 items and only when testing the setup on our Bukkit server (see screenshot, uranium cells not reported). In single player the same setup works as expected. I'm using the latest files (Bukkit version and client) of your mod.

Code of LUA script (test.lua):

os.loadAPI("/rom/apis/inventory");
os.loadAPI("/rom/apis/db");
inv = inventory.get("left:blue");
for _, stack in inv:list() do
print (textutils.serialize(stack));
end

Cheers,
Umpani

Screenshot:

sylphio, on 11 August 2012 - 08:56 AM, said:

Same problem here, although i did not try to bypass the problem:
There is a version mismatch of CCCable between arp-client-1.2.5.zip (1.0.1 in mcmod.info/mod_CCPeripheralCable.info) and arp-bukkit-1.2.5.zip (v1.0.2 in in mcmod.info/mod_CCPeripheralCable.info) which prevents clients to connect to the bukkit server when using the provided downloads without modification.

Cheers,
Umpani

Edit:

This portion of the Bukkit server's server.log might help to track down the problem. It seems that the client reports "CCPeripheralCable v1.0" while the server is expecting "mod_CCPeripheralCable v1.0.2".
Also, in my non-existent knowledge about MC modding, i found out that simply adjusting the in mcmod.info and mod_CCPeripheralCable.info seemed to have no effect on the version number the client reports to the server.

2012-08-11 13:57:47 [INFO] Umpani joined with: [CodeChickenCore 0.5.3, MinecraftForge 3.3.8.164, NotEnoughItems 1.2.2.4, ReiMinimap v3.2_04 [1.2.5], IC2 v1.97, IC2AdvancedMachines v4.0, MetallurgyFishing 1.0.0, ComputerCraft 1.33, CCPeripheralCable v1.0, BuildCraftCore 2.2.14, BuildCraftBuilders 2.2.14, BuildCraftEnergy 2.2.14, BuildCraftFactory 2.2.14, BuildCraftTransport 2.2.14, AdditionalPipes 2.1.3 (Minecraft 1.2.5, Buildcraft 2.2.14, Forge 3.0.1.75), RedPowerMachine 2.0pr5b2, ccSensors MC1.2.5 Build017pr1, CCTurtle 1.33, mocreatures v3.6.2 (MC 1.2.5), EnderStorage 1.1.3, ExtraBees 1.2.1, RedPowerWorld 2.0pr5b2, Forestry 1.4.8.6, IC2NuclearControl v1.1.10, ImmibisCore 49.1.1, InvTweaks 1.41b (1.2.4), MAtmos_forModLoader r12 for 1.1.x, ModularForceFieldSystem rev7, IC2_ChargingBench 1.95b, CompactSolars 2.3.2, IronChest 3.8, RedPowerCore 2.0pr5b2, NetherOres 1.2.5R1.2.2, PowerConverters 1.2.5R1.3.4, Railcraft 5.3.3, RedPowerControl 2.0pr5b2, RedPowerLighting 2.0pr5b2, RedPowerLogic 2.0pr5b2, RedPowerWiring 2.0pr5b2, TubeStuff 49.1.2, Balkon's WeaponMod 1.2.5 v8.6.0, WirelessRedstoneCore 1.2.2.3, WirelessRedstoneAddons 1.2.2.3, WirelessRedstoneRedPower 1.2.2.1, ImmiChunkLoaders rev3.2, CCAdvancedResourceProcessing v1.8]
2012-08-11 13:57:47 [INFO] Umpani was disconnected because they are missing the following mods mod_CCPeripheralCable v1.0.2.