Or he's just been busy in life:

However now he works 10 hours a day, 60 hours a week

Not sure what's going to happen but for now...

There are multiple ways to solve all of the puzzles, since you gain so much freedom with the explosives.  And yeah, currently the objects are not part of the level code, they have to be coded into the executable.  Also I believe the game loads the level from an appvar created by the level creator, so if you don't have that it might not run.

Also that rope issue might be caused by many different things, but I was probably in the middle of working on the code, or maybe the length of the rope is merely too long, not sure

It looks like the program to check is MAPLD, and to add an object use sub(ADD,X,Y,Width,Height,Mass,Sprite).  I believe those arguments are correct, but I'm not 100% sure.

There is not the same type of code for ropes though, but the area it is currently found is in program A:

:1→{L1+300}
:35*256→{L1+308}r
:0→{L1+310}r
:35*35→{L1+312}r
:35→{L1+314}
:2→{L1+315}
And it looks like you already found the arguments that these represent

EDIT: Also, if a list of objects starts at RAM location N, {N} holds the number of objects, with the first object starting at N+L where L is the length of each entry.  For object addition and removal, I use general purpose routines that are present in ZEDD that work for all of the lists in the game.  Object removal works by copying the last element of the list onto the element to be removed, so you don't need to worry about any object addresses changing unless they are the last, in which case I don't know

For the object input, it inflates them itself, for the rope however you need to inflate the anchor location yourself, or write a sub to handle it.  I believe there is also 1 more list to handle graphical effects that is located at L1+400, with entries of 8 bytes. 

For the sprite numbers, the number is an offset from a global sprite buffer.  0 is the first sprite in the buffer, 1 is the second ect... 

The first byte of object data starts at L1, while first byte of rope data starts at L1+300.  Each is 16 bytes.  300/16 rounds down to 18.  So, due to size.

For the sprites, it looks like I would add on to Str3?  (looking at the hex code at least, [C0C060...])

Does the game become unplayable at that number of objects, or simply slower?

That's an interesting way of doing it. How'd you do that?