Robots fail to persist and become corrupted.

[Aoxo 0]

I am not an expert programmer!  I'm toying around with OpenComputers to learn more and have some fun with it.

 

I'm running a Forge 10.13.0.1180 server with MC 1.7.10.  Hosting and playing on the same Windows 7 machine.  I regularly get "can't keep up" messages.  I've upped the process priority, given the server 4GB of RAM, tweaked the LAN adapter for performance.  I can't seem to make the lag messages stop, though I haven't yet disabled any of the addons I use to see which one might be contributing to the problem.  This isn't the reason I'm posting here, but it's relevant perhaps so I'm mentioning it.  That being said, I won't turn down any suggestions on that front.  I'll describe the OC problem below, but might as well get some details about the situation out of the way.

 

I updated to OC 1.3.3 two days ago, I don't recall any serious problems with robots prior, though I've never left three running at once before now.

 

I'm running the following mods currently:

 

1.7.10-MB_Battlegear2-Bullseye-1.0.5.6.jar

Decocraft-1.10_1.7.2and1.7.10.jar.zip

OpenComponents-MC1.7.10-0.2.0.14-universal.jar

OpenComputers-MC1.7.10-1.3.3.54-universal.jar

Pam's HarvestCraft 1.7.10a.zip

PlayerAPI-1.7.10-1.0.jar

RedstonePasteMod-1.7.10-1.6.2.jar

SmartCore-1.7.10-1.0.jar

SmartMoving-1.7.10-15.2.jar

SmartRender-1.7.10-2.0.jar

 

I posted the relevant part of the log, showing the OC errors here:

http://pastebin.com/a4WWA8Az

 

The program I was running at the time is posted here (yes I'm a bad programmer!):

http://pastebin.com/nKEPp6eq

 

I created a robot, and placed that robot in the world 3 times, equipped them similarly, named them differently, and gave them all the same program to run.  It just makes them roam around somewhat randomly bumping into obstacles, attack entity obstacles, not cross a given block, climb another given block.

 

Twice now, when I leave them running and reconnect hours later, I find that all three bots are bugged, each in a slightly different way.  One appears off, and when I click on it the interface is missing a screen.  The power button does noting.  Next, one appears on, and does have a correct looking interface, but no text appears on the screen.  I can hear the hard drive during boot however.  The last robot appears even less bugged.  It has a screen, and the screen even has prompt, but typing produces no input.

 

This happened once, I replaced and re-equipped the bots, then it happened again.  Exact same results.

 

I'm not ruling out "user error", but if it's bug related I thought I should mention it.

 

I'm enjoying OC alot, thanks for all the hard work!

 

 

[Sangar 92]

Please try the latest dev build (http://ci.cil.li). There was an issue where an executor thread could trigger a chunk load. That was fixed a few builds ago, and seems to be exactly what's going in on this error log.

[Aoxo 0]

I will try that, thank you.

 

Currently I''m testing things in a fresh new world, and the terrible, "can't keep up", messages have stopped.  I've added a couple bots, running that same program.  I really wanted to resolve the performance issues with the server before I blame anyone's nice Mod.  I'll give it a day or two to see how it goes, then I'll grab the current dev build and see how that goes too.

[Molinko 43]

Question: Are you placing the exact same robot 3 times in the same world? If so, that may be causing weird errors to occur.

[ingie 6]

none of this is related to your issue, but i just wanted to comment on this :

 

 

The program I was running at the time is posted here (yes I'm a bad programmer!):

http://pastebin.com/nKEPp6eq

 

 

 

you're certainly not a bad programmer, your code is clear and logical.... but you're maybe an inexperienced programmer, as we all have been... and that's no critique. 

 

there's nothing fundamentally wrong with the code, but i'll mention a couple of things to "level you up", perhaps.

 

where you do: 

local det,mat = robot.detect()
local detDn,matDn = robot.detectDown()
local detUp,matUp = robot.detectUp()
local getSelect = robot.select()

at the start, you may as well miss out entirely, as you're not using those initial values except inside functions... it's more "correct" to only define these local to each function as you use them, as you don't need them global to the main program. 

 

e.g. for 

function checkGravity ()
    detDn,matDn = robot.detectDown()
    while detDn==false or matDn=="entity" do

change to

function checkGravity ()
    local detDn,matDn = robot.detectDown()
    while detDn==false or matDn=="entity" do

etc...

i.e. just define them [with local] the first time you use them within the function where you need them.

this way the variables are local to the function only, and therefore lua should garbage-collect [clear up the used memory] at the end of the function [or soon after, once it gets chance] 

it's not vital for a small program like yours, but as programs evolve, it's good practice and habit to keep variables as closely "scoped" to the section of code you're using them in as possible - as it makes the function more reusable and memory efficient... of course, it could be argued that constantly regenerating the variables is slower, but let the compiler worry about that 

 

 

the other point i'd say will make your code more efficient/standard/quicker to type is your use of booleans...
if a value is returning boolean true/false, you don't need to compare it to anything.  
e.g. in your code:

    if robot.compareDown()==true then

etc...

may as well be the more concise:

    if robot.compareDown() then

and for false, instead of :

    while n>0 and det==false and robot.compareDown()==false do
        print(n .. " ")

etc...

use:

    while n>0 and not det and not robot.compareDown() do
        print(n .. " ")

finally, i'd recommend using local before your function names if they're only to be used in the program they're in... lua functions are a type of normal variable, so you can treat them as such in all ways... including using local to ensure their names don't pollute the global variable space

 

e.g.

local function randTurn ()

etc...

[ a side effect, or rather, the nicest effect of functions being variables - or "first class values" which is the more correct term - is that you can assign them to other variables, so that you could also say - at the top, in the main code after the "requires section" - 

-- note, no brackets at the end, 
-- this is just assigning one value to the other value for shortness later
local equip = component.inventory_controller.equip  

and then whenever you would have used the long form later in the code, just call "equip()" as your local "equip" now points to the original function, and will act as such ]

 

but as i say, none of these make your code bad - certainly not for your task - it's more a matter of "programming style" experience. 
and none of these points are criticism, as your code reads pretty much as logically as it could, but i hope you see the use in the suggestions. 

[ingie 6]

Question: Are you placing the exact same robot 3 times in the same world? If so, that may be causing weird errors to occur.

 

indeed... i noticed that a creative hard disk is shared across machines if creative middle-click-duplicated from another machine... which was nice, i assumed it was a feature, but it worried me a little with regard to concurrency.. i'll have to test to see how breakable it is... 

[Sangar 92]

The file systems should be synchronized in all the relevant places, so even though this particular case is... "unsupported" it should work fine (shouldn't be different from multiple computers accessing the same floppy in a disk drive).

[ingie 6]

aye, in my experiments i purely found that - due to me not paying attention and building a floppy into the robot rather than as an upgrade slot - it seemed random whether one of my "clone army" would boot from disk [most of the time] or floppy - some of the time... oddly, this seemed to be persistent - in that, if i placed a cloned robot down and it booted of floppy, it would _never_ boot of the HDA, and in face couldn't see the HDA...  which i think is possibly a bug... [ unrelated to this though ]

 

 

related to the OP, and using that pastebin - my army did successfully wander off into the distance [it's ace in a flatland tiaga biome, you can see the puffs of snow as they plough through it from miles away even after you can't see the robots themselves anymore ] and even when i tried to make them unload, they all seemed happy when i came back.