make /mars_lightup more reliable

[SwissalpS]

Sometimes nothing happens when standing at a certain pos. With rounded pos, standing at the same position it works perfectly.

e.g. standing at -2450.001953125 15005.5 1672.8519287109 doesn't work.
rounding coordinates results in: -2450 15006 1673 and lightup works fine.

Maybe this is cause for similar unreliable results in other functions that use VoxelManip()/core.get_voxel_manip()

[SwissalpS]

possibly similar change could help:
woodcutting { seems safe }
jumpdrive.is_area_empty(), jumpdrive.move_mapdata(), jumpdrive.clear_area(), jumpdrive.fleet.find_engines() { is OK as it converts all coords to int first }
boost_cart:is_rail() { passes integer pos, so no problem here }
ropes.destroy_rope() { seems unafected, passes int in on normal usage }
find_nodes_in_area_cache.create_entry() { seems safe }
vacuum.flush_airpump() {unafected as sends pos from formspec}

-- I didn't check yet if these round beforehand, just keeping a pre-purged list. They don't all use the same method for retrieving index hash. Purge == leave out those instances where VoxelManip is only used to force-loald an area.

[BuckarooBanzay]

you might be on to something: i had that issue a few times already in various other projects and just shrugged it off as a minetest-thing, but it looks like some of the engine-api surface doesn't like non-rounded floats (non-ints?) :/

[SwissalpS]

Yes, it may seem an engine issue on first sight. On second thought it makes sense to have mod developers round coordinates where there is no need for decimals.
There is no reason to have decimals when working on placed nodes and it's theoretically faster to calculate true ints over floats.
It also keeps pos_hash short and simple and avoids rounding errors in the process, which is possibly what is causing the issue.

[SwissalpS]

from https://github.com/minetest/minetest/blob/5d0b18a0d0bd02a9b77b8948d6887bb661a385da/doc/lua_api.txt#L4330

x, y and z must be integers to avoid an incorrect index result.