Stains don't stack
| Author | Topic: Stains don't stack |
|---|---|
|
Law Bringer
Member # 2984
|
written Sunday, May 20 2007 13:21
Profile
Homepage
From the way stains are described in the appendix - -1 removes all stains (and stains are in fact stored in binary form, so 1=small blood, 2=medium blood, 4=large blood, 8=small slime, 16=large slime, etc.), the rest places a certain stain - it would appear that placing multiple different stains should be possible. Nope. Putting, for example, a slime stain removes all blood stains from the square. Should this happen, or am I doing something wrong here? -------------------- Encyclopaedia Ermariana • Forum Archives • Forum Statistics • RSS [Topic / Forum] My Blog • Polaris • I eat novels for breakfast. Polaris is dead, long live Polaris. Look on my works, ye mighty, and despair. Posts: 8752 | Registered: Wednesday, May 14 2003 07:00 |
|
Guardian
Member # 5360
|
written Sunday, May 20 2007 13:27
Profile
Well, from what Nalyd has seen, this happens in-game as well, so it's probably supposed to happen. -------------------- May the fires of Undeath burn in your soul, and consume it. Posts: 1636 | Registered: Wednesday, January 5 2005 08:00 |
|
Shaper
Member # 7472
|
written Sunday, May 20 2007 13:38
Profile
Homepage
Are you placing them with code or the editor? Because you can stack any sort of stain you can imagine in the editor, assuming you don't hit the total stain limit. You can only have a certain number of stains in a single town. -------------------- I tried to think of something witty to put here. Needless to say, I failed. Posts: 2686 | Registered: Friday, September 8 2006 07:00 |
|
Lifecrafter
Member # 6193
|
written Sunday, May 20 2007 16:26
Profile
Homepage
Some experiments I did: Firstly, stains indeed don't stack, unless placed in the editor. I'll also point out that the numbers are actually 1-8, not 0-7 (so small blood is 1, not 0) Objects and fields do not have this problem. Objects are numbered as usual, and do stack. Fields are numbered as usual, but they don't appear to stack. The way this is handled is a bit odd-- if there are multiple fields on a spot it isn't the last field placed that remains, but rather BoA figures it out using some kind of heirarchy. Antimagic appears to have the highest rank, but I don't know the heirarchy below that. My verdict-- fields at first appear to be a terrible option because of the odd heirarchy they use, but on second look they might not be so bad. Putting an out of range number for field number doesn't result in an error, and since they don't stack, and aren't meant to stack, you (hopefully) wouldn't have to worry about the stupid binary form problem. Stains are apparently broken. Objects would work, but you'd still have to deal with inputting stuff in binary form, which would suck. Fields look promising, but ideally we'd just get terrain/floor to work. Edit: No wait, stains don't stack. Doh. Edit2: As a matter of fact, they seem to be completely broken. Small blood-large slime work fine (although off by 1 still) but 6 (dried blood) instead places rocks and blood. 7 (bones) works. 8+ does nothing. [ Sunday, May 20, 2007 16:39: Message edited by: Lazarus. ] -------------------- Guaranteed to blow your mind. Frostbite: Get It While It's...... Hot? Posts: 900 | Registered: Monday, August 8 2005 07:00 |
|
Infiltrator
Member # 3040
|
written Sunday, May 20 2007 19:47
Profile
What version of the BoA app (not the scenario editor) are you guys using? I remember a while back that placing stains via script calls was broken as of 1.1.2, and I posted a fix on the Lyceum. The fix was eaten by ezBoard, unfortunately, and I don't have a record of it. Are you still getting the error for 1.2? EDIT: Okay, I figured it out again. The blood/rocks for "dried blood" is actually a feature; it's what the dried blood is supposed to look like. Through black magic I have figured out that it is impossible to make stains stack with script calls, although setting stacked stains in the editor should work fine (via OR-ing together the various values; 1 for small blood, 2 for medium blood, 4 for large blood, etc). Furthermore, the behavior Aran described is correct: as long as only blood is placed, it increases in amount; the same goes for slime. Putting blood on slime or slime on blood erases whatever was underneath. Dried blood, bones, and rocks are each in their own category and erase anything underneath them. Or rocks would, if one could actually place them. I have also uncovered a secret ritual that would allow one to use scripted calls to place rocks as well (i.e. fix the limit to include 8), as well as optionally fix the numbers to reflect those stated in the docs. Unfortunately this secret ritual is way too profane to state on these boards, and is so difficult that only experts in the dark arts can perform it (as well as anyone with access to certain kinds of file editors, the name of which is forbidden here; such persons would also have to perform the ritual on only the Mac OS X Universal version of BoA 1.2). If anyone is still interested, let me know. Unfortunately, BoA 1.2 fixed a script call that in previous version lacked bounds checking; that loophole might have provided a workaround. P.P. Just to confuse matters, if you want to use is_stain_on_space, I think you should use the values as stated in the appendix. [ Sunday, May 20, 2007 21:48: Message edited by: wz. As ] -------------------- 5.0.1.0.0.0.0.1.0... Posts: 508 | Registered: Thursday, May 29 2003 07:00 |
|
Law Bringer
Member # 2984
|
written Sunday, May 20 2007 22:40
Profile
Homepage
We have a topic over at Shadow Vale about this (which actually triggered my question here), regarding the set_terrain/floor/stain/field calls and the lack of boundary checking. Arsenic, your talk of black BoAmancy makes me think you have something to contribute there. :) -------------------- Encyclopaedia Ermariana • Forum Archives • Forum Statistics • RSS [Topic / Forum] My Blog • Polaris • I eat novels for breakfast. Polaris is dead, long live Polaris. Look on my works, ye mighty, and despair. Posts: 8752 | Registered: Wednesday, May 14 2003 07:00 |