Page 1 of 1
Logic of dsb_text2map dsb_get/set_cell etc.
Posted: Fri Nov 02, 2007 2:00 am
by Joramun
Ok, here is what I observed :
dsb_text2map takes 0 for wall and 1 for open tile.
dsb_set_cell takes 0,nil or false for wall, and anything else (including 1 and true) for open tile
BUT :
dsb_get_cell returns : true for wall, and nil (=false) for open tile
AND it returns : nil(=false) for wrong (out of bound) cell coordinates.
Question :
- Is it possible to reverse the results of dsb_get_cell to match the logic of the other two functions ?
EDIT: 'nil' for wall or out of bounds and 'true' for open tile.
- Would anyone complain or any base code be broken in this case ? (I think inserting a 'not' isn't too difficult though...)
I made a very cool looking magic map, and it wouldn't be difficult for me to correct my code, and I think it would more coherent...
Posted: Fri Nov 02, 2007 5:57 pm
by Sophia
Sort of... not quite.
dsb_get_cell and
dsb_set_cell are actually consistent with each other (true/1 = wall, 0/false = open), but this is the reverse of
dsb_text2map, so it's a bit counter-intuitive.
So, I think I might just reverse the logic of both of them anyway.
If anyone has any major objections, speak now!
(Internally, DSB actually does use a 1 for a wall and a 0 for open space. That part of it is way too far gone to change, but I'll just negate it for the Lua system calls)
Posted: Sun Nov 04, 2007 4:49 pm
by Parallax
Well, reversing this is going to break something I'm doing, although I don't have much time to do it these days. So I'm not saying I'm opposed to it, but I'd like to know when (in terms of DSB versions) the change will be effective.
Posted: Sun Nov 04, 2007 6:22 pm
by Remy
Well, why it's generally a bad idea to override
dsb_*s - in fact, I don't know if it's possible because DSB may re-register those functions (overriding your overrides), you might be able to gat away with it here, instead of rewriting alot of code.
Code: Select all
old_get_cell = dsb_get_cell
old_set_cell = dsb_set_cell
function dsb_get_cell(level, x, y)
return not old_get_cell(level, x, y)
end
function dsb_set_cell(level, x, y, value)
old_set_cell(level, x, y, not value)
end
Posted: Sun Nov 04, 2007 6:31 pm
by Joramun
Yeah, knowing that dsb_get/set_cell actually have the same logic actually made my proposition less appealing...
But it's up to Sophia in the end.
Posted: Sun Nov 04, 2007 8:02 pm
by Parallax
Thanks RemyR, but I get dizzy imagining what else this change might break. Which is, just about anything else that uses get_cell and set_cell. If I make my item like this and it gets put in a dungeon that has a lot of calls to these functions, mayhem might ensue.
Anyways, considering how long it takes me every time I add a line to degub it properly, I think I'll be fine changing my functions around when this change becomes active, if it has not already.
Posted: Sun Nov 04, 2007 9:33 pm
by Sophia
I haven't actually done anything yet, and sort of left this topic open, because to be honest I'm not sure. One way is more consistent, but on the other hand, it's the sort of thing that's likely to confuse people, and there's really nothing wrong with the way it is now-- with everyone using RemyR's editor, people might not even pay attention to the syntax of
dsb_text2map.
That, and I wrote a bunch of Lua code this weekend and I'd have to change it all...
So... I'm not sure.
Posted: Mon Nov 05, 2007 6:33 pm
by Sophia
Parallax makes a good point, and RemyR's fix, while well-intentioned, shows me the perils of this kind of thing--
I've decided that changing the meaning of a core
dsb_ function in a very backward-incompatible, particularly a reversal like this, isn't something I should do unless I
absolutely have to (like, to fix a bug or something), and that doesn't really apply here.
So, in other words, just assume none of this ever happened.
We'll just live with the inconsistency.
Posted: Mon Nov 05, 2007 6:49 pm
by Joramun
*Jumps through the nearest window*