Jump to content




SimpleSandbox - A simple, ASCII sandbox


6 replies to this topic

#1 Quartz101

  • Members
  • 141 posts
  • Location/dev/nvme0n1

Posted 19 December 2015 - 04:19 PM

SimpleSandbox - Fun and simple!
Screenies:
Spoiler

I'm not good at explaining, sorry!

Controls:
P - pause/unpause
X - exit
R - toggle replace mode
left click/drag - place
right click/drag - remove
scroll - select block
S and L - save and load
H - help screen
A - switches between ASCII and Pixel mode.
G - toggles gravity
B - switches into boom mode, so you can explode stuff with a click!

Pastebin:
pastebin run GE0CCrzp

Premade maps!
Spoiler

Blocks:
Normal(white) - Just a normal block. Obeys gravity.
Stone(gray) - A gray normal block! Good for mountains!
TNT(red) - BOOM!
Boom(orange) - TNT uses this block for the particle effects. It goes up, not down.
Bacteria(purple) - Replaces adjacent blocks with itself
Steel(light gray) - Doesn't obey gravity.
Rainbow(rainbow) - RAINBOWS!!!
Redstone Dust(orange or red) - Sorta glitchy redstone
Redstone Block(red) - Powers RS dust.

WARNING: Save files are quite large! The one used in the screenshot is 33 KB, and has 3017 lines! Save files are now compressed!

Edited by Quartz101, 28 December 2015 - 11:07 PM.


#2 Anavrins

  • Members
  • 775 posts

Posted 19 December 2015 - 06:29 PM

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.

#3 Quartz101

  • Members
  • 141 posts
  • Location/dev/nvme0n1

Posted 19 December 2015 - 06:35 PM

View PostAnavrins, 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.

Will fix savefile size soon!

View PostAnavrins, 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.

hm weird, I can't get that error

Edited by Quartz101, 19 December 2015 - 06:53 PM.


#4 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 20 December 2015 - 01:12 AM

View PostQuartz101, on 19 December 2015 - 06:35 PM, said:

View PostAnavrins, 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.

#5 Quartz101

  • Members
  • 141 posts
  • Location/dev/nvme0n1

Posted 20 December 2015 - 01:23 AM

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

View PostQuartz101, on 19 December 2015 - 06:35 PM, said:

View PostAnavrins, 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.

I just realized why I didn't crash. I added abunch of if checks LOCALLY. Will upload to PB soon.

Guess what? Version 1.1 came out!
* Save files are now compressed, thank you Anavrins for the fix! (Old save files STILL work!)
* Auto-updating

To get the game:
pastebin run b8Z4RrJu

Actually, 1.1.1 is now out! It fixes the TNT crash bug!

#6 Quartz101

  • Members
  • 141 posts
  • Location/dev/nvme0n1

Posted 25 December 2015 - 12:57 AM

1.2 has been released! Same pastebin link, it should autoupdate if you are on 1.1 or 1.1.1

Changelog:
Added redstone blocks and dust
Added 'boom mode', which is like instant tnt, with a click! Toggle it w/ B.

Bugs:
Redstone dust/bacteria fails to spread sometimes. (Since 1.1/1.0)

Edited by Quartz101, 28 December 2015 - 12:28 AM.


#7 Quartz101

  • Members
  • 141 posts
  • Location/dev/nvme0n1

Posted 28 December 2015 - 12:29 AM

1.2.1 has been released! You must redownload! There was a bug in the installer AND updater that made it download 1.0 always!





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users