SimpleSandbox - A simple, ASCII sandbox

Spoiler

Pixel mode:

pastebin run GE0CCrzp

pastebin get Je0585aj sandbox.sav

pastebin get abAMv9eb sandbox.sav

Anavrins, on 19 December 2015 - 06:29 PM said:

This is pretty sweet, I like it :P/>
However, I get "sandbox.lua:240: invalid key to 'next' " when TNT particles are rising up.
A little quick tip to reduce the savefile saves would be to do textutils.serialize():gsub("\n%s*", ""), which will get rid of unnecessary newlines.

Anavrins, on 19 December 2015 - 06:29 PM said:

This is pretty sweet, I like it :P/>
However, I get "sandbox.lua:240: invalid key to 'next' " when TNT particles are rising up.
A little quick tip to reduce the savefile saves would be to do textutils.serialize():gsub("\n%s*", ""), which will get rid of unnecessary newlines.

Quartz101, on 19 December 2015 - 06:35 PM said:

Anavrins, on 19 December 2015 - 06:29 PM said:

However, I get "sandbox.lua:240: invalid key to 'next' " when TNT particles are rising up.

hm weird, I can't get that error

    for k = 1, table.maxn(world) do
      local v = world[i]

                    world[k].y = h
                    v.y = h

Bomb Bloke, on 20 December 2015 - 01:12 AM said:

Quartz101, on 19 December 2015 - 06:35 PM said:

Anavrins, on 19 December 2015 - 06:29 PM said:

However, I get "sandbox.lua:240: invalid key to 'next' " when TNT particles are rising up.

hm weird, I can't get that error

Eye-balling the code, it's because you're attempting to remove keys from a table you're actively iterating through. "pairs" can't handle that - you must not remove keys until the loop started on 240 has completed!

Say you've got "tnt" being ticked. It eventually explodes and is vaporised, becoming "boom". 15-25 ticks of "boom" and it's removed from the world table. That's a crash.

Keep in mind many ComputerCraft emulators are not 100% accurate to the behaviour you'll actually see in game. I've no idea how tolerant "pairs" is in other versions of Lua.

If I were you, I'd switch the loop to operate something like this:

	for k = 1, table.maxn(world) do
	  local v = world[i]

Since you're already performing existence checks on v, this should work just fine regardless as to what gets removed from the table while the loop is running.

Mind you, you're performing a few more such checks than you need to… line 245 for eg is checking for the existence of v.y, despite the fact that 241 has already ensured that it's there. And is it even possible for v.y not to exist if v does?

A note on tables: When you assign one to a variable, what you're actually sticking in that variable is a pointer which leads to the actual table. Copy the variable and you end up with two pointers leading to the same table. Stuff like this:

					world[k].y = h
					v.y = h

… is hence redundant, as both lines are targeting the exact same bit of memory. Functions (and coroutines) are assigned in the same manner.

pastebin run b8Z4RrJu