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...
Logic of dsb_text2map dsb_get/set_cell etc.
Forum rules
Please read the Forum rules and policies before posting.
Please read the Forum rules and policies before posting.
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
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)
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)
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
- Parallax
- DMwiki contributor
- Posts: 424
- Joined: Mon Aug 28, 2006 7:56 pm
- Location: Back in New Jersey
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.
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.
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
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.
That, and I wrote a bunch of Lua code this weekend and I'd have to change it all...
So... I'm not sure.
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
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.
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.