Temporal Slow-Down

Hey Pro's n' Bro's

I mentioned a temporal slow-down and don't know how to fix that. Looking at a clock, using os.time, shows me, that my time is running about 5-6 real-seconds until the Minecraft time advances a second.
It's also showing in the celestial movement. The complete Sky is moving as usual, but when it checks it's new positions, it jumpes back to where it calculated should be, so it moves normaly (with normal speed), but jumps back. Starting a new game makes everything normal, as usual. Loading my world does like mentioned above.

I'm using Minecraft 1.4.7
-Redpower2 for 1.4.7
-Buildcraft 3.4.3
-Industrialcraft2 for 1.4.7
-forestry 2.0.0.11
-Computercraft 1.4.8
-OpenCCSensors 0.1.4c
Optifine, CraftGuide and Rei's Minimap

My Computer is a DualCore D930Presler 3000 Mhz with 4 GB-Ram at 333Mhz. (ok, its now very new)

I have 20 Computers running, 4 of them just showing time, 16 of those have startup-files, 4 of the 16 are managing Nuklear-Reactors.
9 of them use OpenCCSensors peripherals, 5 of this 9 even use 2 sensors at the same time.

Dont know if "lag" is the right name for this problem. Minecraft is running smooth, no bucking, stopping, pausing, dont know to name that right but it has this unusual time-retardation.
Could it come from accessing the sensors all the time? Do I expect too much from the Hardware? What could be the problem, could it be fixed?


Greets

Could it be caused by an extensive use of getTargets and getTargetDetails ???

Oh sorry, double Post

I've never even heard of this bug before. I'm not sure as to the internal mechanics of Minecraft, but have you checked your system time to ensure that it's not doing anything funky? This is quite strange, and I doubt that it would be caused by polling OpenCCSensors too often (they shouldn't affect time like this). Have you tried using more recent versions of Minecraft and gotten the same bug?

Try putting down water and see how long it takes for it to flow, then do the same in a clean world. If it takes 6 times as long in your slow world, then I believe you are experiencing tick lag.

Bubba, on 18 August 2013 - 11:50 AM said:

have you checked your system time to ensure that it's not doing anything funky?

My system Time is running normal.

Bubba, on 18 August 2013 - 11:50 AM said:

Have you tried using more recent versions of Minecraft and gotten the same bug?

No I did not, but i shutted down every computer inside the game and renamed the startup files so they are not loaded at restart and - dadaaa my problem is getting better, but its not quite vanished. The best result came by shutting down my reactor software, I use a inventory sensor, to check the damagevalue of each component and use the IndustrialCraft sensor, to check the heat of the core. I have this software running on 4 Computers, checking 4 reactors. Shutting them down made the most result. It's like, pulling the sensors data is pausing minecraft ticks. Of course, i don't know if the problem occurs on newer versions of minecraft and mods, I'm using 1.4.7. Maybe it depends on my slow system performance. But maybe, this slow performance shows a bug, that faster systems don't run into because you will never detect that. Maybe you would need 400 of my reactors to discover that on a i7.

Yevano, on 18 August 2013 - 12:53 PM said:

Try putting down water and see how long it takes for it to flow.

Putting down my water is like, - go make coffee, drink coffee, oh - drink another coffee, come back and play…

Yevano, on 18 August 2013 - 12:53 PM said:

you are experiencing tick lag.

I think so, and now, I'm able to better it by shutting down all computers and just start them, when i need them, but i think this is not as defined by the inventor.
Ok, I know my system is very slow, time for a new one and the problem is not freaking me out, i can live with that.

I thought, someone could go handy with the information.

Just one thing,

shutting down all computers makes a normal celestial movement. Running just one Reactor-Manager makes a noticeable "Jump Back" on the sky.

Could it be due to bad programming calling the sensors? I just get sensor data of the core with IC2-Card, make a sorted table of that, then get sensor data of the inv-card, show component damageValue and table with core data. Values, that go out of controll can shut down the running and that's all.?!?!

I always wondered about the celestial movement but even my Buildcraft Quarry was dropping less items and that brought me to the point of research. When i shut down all computers, my Quarry, of course, gives a rod of items, dropping into my pipes, with all software running, its a dripping faucet.

This is indeed server lag.
Since Minecraft 1.3, singleplayer works as if you're on a private server, and the server part (which handles most gameplay) runs separately from the client part (which handles display, and player movement). That's why Minecraft seems smooth.

Pastebin your program, we might be able to tell you which part of it is causing the problem.

I now tested a little further and noticed a "celestial - jump back", only with this little piece of code here, running on just one computer:

monitor = peripheral.wrap("top")  
monitor.setTextScale(0.5)
term.redirect(monitor)
os.loadAPI("ocs/apis/sensor") 
local inventory = sensor.wrap("left")
while true do
invdetails = inventory.getTargetDetails('0,0,-5')
sleep(0)
end

sure I can't measure, how much time i loose with it, but it does. The more time I loose, the bigger is the "Jump-Back" on the sky.
Sounds funny I know, it is funny indeed. And sort of strange, there has to be a problem much worse i think but what???

ZagKalidor, on 19 August 2013 - 07:26 PM said:

I now tested a little further and noticed a "celestial - jump back", only with this little piece of code here, running on just one computer:

monitor = peripheral.wrap("top")  
monitor.setTextScale(0.5)
term.redirect(monitor)
os.loadAPI("ocs/apis/sensor")
local inventory = sensor.wrap("left")
while true do
invdetails = inventory.getTargetDetails('0,0,-5')
sleep(0)
end

sure I can't measure, how much time i loose with it, but it does. The more time I loose, the bigger is the "Jump-Back" on the sky.
Sounds funny I know, it is funny indeed. And sort of strange, there has to be a problem much worse i think but what???

Never ever ever use sleep(0) in an infinite loop. Sleep(0) is basically a hack to make a program run as fast as possible.
Because your program told your (real) computer to keep checking target details as fast as possible, that's exactly what it's doing, instead of running the rest of Minecraft.

sorry for the bad example,

but it`s the same with this: less small than the other

monitor = peripheral.wrap("top")   --this prog requires a monitor min. size of 3x3
monitor.setTextScale(0.5)
term.redirect(monitor)
os.loadAPI("ocs/apis/sensor")   --be sure to place your computer and sensors in a range of max. 7 blocks to the back-block of the reactor-core, due to the sensor range
local inventory = sensor.wrap("left")  --put the inventory sensor card to a sensor at the left side
local ic2 = sensor.wrap("right")
term.clear()
local counter = 0
local menergy = {}
TextColor = 1
menergy =  {valuenew = 0,
   valueinc = 0 }
function drawbar (PosCol, PosRow, BarWidth, BarCol, BarValue)
local digit = {}

for x = PosCol, PosCol + (BarWidth) do
  term.setCursorPos (PosCol + x , PosRow) print (" ")
end

term.setCursorPos ( PosCol, PosRow )	  term.setTextColor (colors.white) print (">")
term.setCursorPos ( PosCol + (BarWidth+2) , PosRow )   term.setTextColor (colors.white) print ("<")

TextPos= math.ceil(BarWidth /2) - 2

if BarValue >= 101 then BarValue = 100 end

if BarValue ~= 0 then
  BarPos =  ((BarWidth / 100) * BarValue )	
  term.setCursorPos ( (PosCol+1) + BarPos, PosRow )   term.setBackgroundColor (BarCol) print (" ") term.setBackgroundColor(32768)
 
  for freespace = PosCol + 1 , BarPos + 2  do
    term.setBackgroundColor(BarCol)
    term.setTextColor(TextColor)
    term.setCursorPos (freespace, PosRow) print (" ")
    term.setBackgroundColor(32768)
  end
else
  term.setBackgroundColor(colors.black)
  term.setCursorPos(PosCol + 1, PosRow) print (" ")
  BarPos = 0
end
 
  for z = 0 , 3 do
 
   if BarPos >= TextPos + z then  digit[z] = { digit = string.sub(BarValue, z+1, z+1), TextColor = 32768,  BColor = BarCol }  
   else	    digit[z] = { digit = string.sub(BarValue, z+1, z+1), TextColor = 1,   BColor = 32768 } end
  
   if BarPos >= TextPos + 3 then   digit[3] = { digit = "%", TextColor = 32768, BColor = BarCol}  
   else		   digit[3] = { digit = "%", TextColor = 1,    BColor = 32768 } end
  
   term.setCursorPos((TextPos+PosCol+(z+1)), PosRow)
   term.setBackgroundColor(digit[z].BColor)
   term.setTextColor(digit[z].TextColor) print(digit[z].digit)
   term.setBackgroundColor (32768)
  end
end
			
while true do
-- draw loadingdevice
chargingdeviceinventory = inventory.getTargetDetails('-3,0,0')
chargingdevicedetails   = ic2.getTargetDetails  ('-5,0,0')

menergy = { valuenew = chargingdevicedetails.Stored,
    valueinc = (chargingdevicedetails.Stored - (tonumber(menergy.valuenew)))  }

term.setTextColor (colors.orange)
term.setCursorPos (2,2)  print ("Charging Device = ")
term.setCursorPos (2,3)  print ("Energy Stored   = ")
term.setCursorPos (29,3) print ("=")
term.setCursorPos (35,3) print ("%")
term.setCursorPos (2,4)  print ("Charging Rate   = ") 


term.setTextColor(colors.lightBlue)
term.setCursorPos (20,2)  print ("				 ")
term.setCursorPos (20,2)  print (chargingdevicedetails.Name)
term.setCursorPos (20,3)  print ("	    ")
term.setCursorPos (20,3)  print (chargingdevicedetails.Stored)
term.setCursorPos (30,3)  print ("	 ")
term.setCursorPos (31,3)  print (chargingdevicedetails.StoredPercentage)
term.setCursorPos (20,4)  print ("				 ")
term.setCursorPos (20,4)  print (menergy.valueinc)
term.setTextColor(colors.white)

drawbar ( 2, 6, 31, 32, chargingdevicedetails.StoredPercentage )

-- draw upper slot

  term.setTextColor(colors.white)
  term.setCursorPos (2,9)  print   ("Charging-Slot:")
	 term.setCursorPos (2,10)  print   ("----------------------------------")
 
  term.setTextColor(colors.lightGray)
  term.setCursorPos (2,11)  print   ("Input		   = ")
  term.setCursorPos (2,12) print   ("Loading Value   = ")
  term.setCursorPos (2,13) print   ("Load.Percentage =")

if  chargingdeviceinventory.Slots[1].Name ~= "empty" then
 
  term.setTextColor(colors.lightBlue)
  term.setCursorPos (19, 11)  print ("				 ") term.setCursorPos (20,11)  print (chargingdeviceinventory.Slots[1].Name) 
	 term.setCursorPos (19, 12) print ("				 ")  term.setCursorPos (20,12) print (chargingdeviceinventory.Slots[1].DamageValue)
 
  loadingpercentage = math.abs(((100/25)* (chargingdeviceinventory.Slots[1].DamageValue - 1 )*-1)+100 )
 
  term.setCursorPos (19, 13) print ("				 ")  term.setCursorPos (20,13) print (loadingpercentage)   
 
 
  drawbar (2, 15, 31, 32, loadingpercentage )
  
else
  term.setTextColor(colors.lightBlue)
  term.setCursorPos (20,11) print   ("EMPTY		    ")
  term.setCursorPos (20,12) print   ("-----   ")
  term.setCursorPos (20,13) print   ("-----	 ")
  term.setCursorPos (2 , 15) term.clearLine()
 
  end
-- draw lower slot
  term.setTextColor(colors.white)
  term.setCursorPos (2,17)  print   ("Decharging-Slot:")
	 term.setCursorPos (2,18)  print   ("----------------------------------")
 
  term.setTextColor(colors.lightGray)
  term.setCursorPos (2,19) print   ("Input		   = ")
  term.setCursorPos (2,20) print   ("Loading Value   = ")
  term.setCursorPos (2,21) print   ("Load.Percentage = ")
 
if  chargingdeviceinventory.Slots[2].Name ~= "empty" then

  term.setTextColor(colors.lightBlue)
  term.setCursorPos (19, 19) print ("				 ")  term.setCursorPos (20,19) print (chargingdeviceinventory.Slots[2].Name) 
	 term.setCursorPos (19, 20) print ("				 ")  term.setCursorPos (20,20) print (chargingdeviceinventory.Slots[2].DamageValue)
  loadingpercentage = math.abs(((100/25)* (chargingdeviceinventory.Slots[2].DamageValue - 1 )*-1)+100 )
  term.setCursorPos (19, 21) print ("				 ")  term.setCursorPos (20,21) print (loadingpercentage)   
	
  if loadingpercentage == 104 then loadingpercentage = 0 end
 
  drawbar (2, 23, 31, 32, loadingpercentage )
 
else
  term.setTextColor(colors.lightBlue)
  term.setCursorPos (20,19) print  ("EMPTY			 ")
  term.setCursorPos (20,20) print  ("-----   ")
  term.setCursorPos (20,21) print  ("-----	 ")
  term.setCursorPos (2, 23) term.clearLine()
  end

end
term.restore()

inbetween your "while true do" and the end statements you do not allow your script to yeild. Basically it will try to run as fast as possible without giving up processing time to other programs…

You must have a way of making the program yeild… eg sleep(0.1) This may be why you are getting problems with "microlag" while using the computers.

sorry to bother you with that,

even sleep(0.5) does a noticeble "jump back"

I think its time for a new computer. One more question: is this "Microlag" as you call it, a common problem or just with my slow computer? Does it occur on fast systems too?

Edit: Tested today on Minecraft 1.5.2 - it's the same ???!!!

I have had problems with MC having microlag. But mine was caused by me forgetting to make my programs yeild. It basically started, ran the program. Crashed the CC computer. Then the lag finished. (few tweaks later in my programs and my Mc no longer lagged). * I run Minecraft with 2gb of ram. in the java enviroment. (8gb system ram).

I must admit i have never seen it effect the sky though and I have basically all the mods you have except :-

-OpenCCSensors 0.1.4c
Optifine, CraftGuide.

I have 97 mods in total on my version of minecraft. But it was assembled by my old server admin. ( we closed our server untill Redpower2 is updated to a newer minecraft version now. )

i do not understand why the following does not have a similar effect to my world

-it has a loop without yielding, like Albrat said
-it has the sleep(0) like Immibis said, runs as fast as it can, giving no space for other tasks.
everything goes fine

mon = peripheral.wrap("top")
mon.setTextScale(2)
term.redirect(mon)
while true do
   term.setTextColor(8) term.setCursorPos (1,1) print ("--------------")
   term.setTextColor(8) term.setCursorPos (1,5) print ("--------------")
 
   term.setTextColor(2048) term.setCursorPos(6,3) write(textutils.formatTime(os.time(),true))
   sleep(0)
end
term.restore()

It takes some time to get information from the sensors. Again, don't use sleep(0) (or worse, no sleep)! Sleep for an appropriate amount of time. Half a second is good, a second or two is better. There's absolutely no need to run the program as fast as it possibly can. If you keep doing this, you will keep having tick lag.

The sensor calls probably have a similar effect as sleep(0) as a side effect of how they're implemented.
A loop with no sleep(), pullEvent(), read() etc calls (any call that wait for something to happen) is worse than a loop with sleep(0), but ComputerCraft won't let you make such a loop (it crashes your program with "Too long without yielding").
sleep(0) means "run everything else, but get back to me as soon as possible".
A loop with sleep(0) is like a loop that never pauses, but it sometimes gives chances for other things to run. In practice, it's even worse because ComputerCraft won't kill your program.

Or if you didn't understand any of that, just remember that ComputerCraft will run your programs as fast as your real computer can run them - so add pauses to avoid wasting all your real computer's time.

About your last example, I don't know for certain, but it might be because the program doesn't interact with anything outside ComputerCraft.

Bam! That was a explanation, i had heped to get.

Thank you sir's