BUGS!

[Kelandon]

Time for another incarnation of this topic. (Old incarnations can be found here , here , and for a previous version of BoA, here .)

 

Why revive it, you may ask. I think that keeping a current list of known bugs circulating helps designers, since it helps us know what the limitations on BoA are at the moment, and also it will help us when we need to tell Jeff about these bugs later.

 

I can make a small scenario to demonstrate a number of these bugs if it should become necessary, and I may create a page on my web site or modify the Appendices Wiki in order to make this knowledge more accessible.

 

Known bugs/problems in Mac-BoA v1.1.2 or Win-BoA v1.0.3:

* Set status switches bless/curse and shield/weaken stats when is_forced is one.

* Internal varables such as "shop" or "pay" should be listed in either the Documentation or Appendicies.

* Items don't stack when given via char_give_item (so if you give three potions of the same kind, the character ends up with three different potions). This doesn't happen with reward_give or other item management calls as far as I know.

* Outdoors signs don't work sometimes. (Does this still not work? Jeff claims that he fixed it for v1.1.2.)

* If cursed items are placed on ground/in a container in the editor, they lose their cursed ability.

* The town status calls don't work as described. The void set_town_status and the short town_status apparently work as follows: if and only if the town passed is -1, the calls work for the town the party is in, or, if outdoors, the town the party was in last.

* Enter-combat-end-combat bug: you can get placed in totally nonsensical locations when ending combat. If you enter and then end combat immediately, you get placed one space forward. This allows you to skip special rectangles extremely easily.

* The call move_to_new_town can't be called from an INIT_STATE, a START_STATE, a creature script, or a terrain script, even if you distance the call from the state with set_state_continue, run_town_script, or run_scenario_script.

* Beam projectors malfunction wildly in close quarters, next to walls, in varying heights, etc. I have a small utility scenario to demonstrate a number of ways in which this can occur.

* When a PC is next to a spot and you look at that spot, you search the spot. As far as I can tell, if the joined NPC is next to a spot, however, you don't search the spot. (This turns out to be trivial to fix -- Jeff would have no trouble doing it.)

* On Win98, crashes have been observed when monsters use missile attacks.

* Sometimes searchable terrain breaks. For certain terrain with the searchable and container attribute, they are only searchable if there is something inside the container. (I'm not sure that this is a bug, per se.)

*The call char_take_item (originally described as bugged here ) still doesn't work. It doesn't give an error message anymore, but it still does nothing.

* In corescendata, Augmented Giant (creature 135) ought to have the line "cr_which_sheet_upper = 1618;"

* The default rakshasa image needs realignment -- it has a black line on it.

* The slith avatar, in order to match Avernum 1, should not have the graphic of a gorgon, which is what it should have now. Two calls need to be added: cr_which_sheet = 1532 and cr_icon_adjust = 2, as Bahssikava does.

* The call put_stain_on_space sometimes does nothing when attempting to remove a stain. This is a bit unpredictable, but most of the time that I've tried it, it does nothing. It also works fine putting a stain down, just not removing it.

* Putting a town border right next to the edge of the town causes weird behavior: you can't exit the town, the town doesn't match the edge, etc.

 

Various things cause Unhandled Exception errors on Windows that cause BoA to quit entirely without giving a proper error message. These are extremely hard to debug for Mac designers, since they do not reproduce in the same way on a Mac, except for a few that are noted. Among them:

* Using a terrain or floor graphic that doesn't exist. This is a problem with wallsets that are not complete, for example: if you place a wall with a door from a wallset that doesn't include a door (ie, cave wall), this causes an unhandled exception.

* Setting a creature facing a direction greater than 7 -- ie, set_character_facing(6,8).

* Running the death animation of a creature with cr_small_or_large_template set wrong -- that is, if the creature's graphic is small but cr_small_or_large_template = 1 in the scenario's custom objects script, then BoA crashes without an error message and quits. This happens on Mac, too.

* Over-running the string limit. I got an unhandled exception in Vasskolis when I tried to display a message from the text buffer that was longer than 256 characters. I'm not sure if over-running the text buffer itself was the problem or if trying to display it was the problem, but either way, the over-long string didn't give the over-long string error like it does on a Mac.

* If you try to use a string variable while nothing's in it (i.e., you forgot the get_buffer_text call), BoA dies. On Mac-BoA v1.1.2, it crashes, gives no error message, and quits. I got this with a message_dialog call, but I imagine a print_str or text bubble would give the same response.

 

Others?

[Dahak]

You do not need to be next to a terrain script to search it, and therefore execute it (i.e. doors).

[wz. As]

(edit) Never mind.

[Kelandon]

Quote:

Originally written by Dahak:
You do not need to be next to a terrain script to search it, and therefore execute it (i.e. doors).

I'm having trouble reproducing this. Can you describe to me a situation where it works? Everything I've tried indicates that you do have to be adjacent to a door to close it.

EDIT: Not sure that this is technically a bug, but items don't stack when given via char_give_item and presumably all the other calls. This is annoying when you're trying to give several potions or something like that.

EDIT 2: No, they do in fact stack when given via reward_give, just not when given with char_give_item.

[Dahak]

Try opening a door and then while standing one space away from an adjacent space, search the door to close it. The door closes even though you are not nearby.

[Kelandon]

That's what I did. Are you sure you understand the location of the door? It's actually on the space that it opens into.

 

Or, in a related point, does it work for anything else other than doors? If you put specobj on a box, does this create the same problem?

[Tohubohu]

Quote:

* Enter-combat-end-combat bug: you can get placed in totally nonsensical locations when ending combat. If you enter and then end combat immediately, you get placed one space forward. This allows you to skip special rectangles extremely easily.

I find this bug to be particularly damaging to a scenario. In Diplomacy with the Dead, I was able to bypass several of the high-level traps and special dialog encounters with CENSORED and attack him before he engaged in combat. Several times.

It could be annoying if an unintentional bypass was made on any scenario, especially when concerning SDFs and information vital to directing a scenario. Or when you want the party to hurt.

[Kelandon]

There is a workaround -- change_blocked prevents the party from landing on a space when ending combat, which can prevent the skipping effect, which I think most recent scenarios have done for major special encounters, but it's still kind of annoying that it happens at all.

[DreamGuy]

I've never seen someone able to close a door from a non-adjacent space, or search them for that matter, so I don't know if that's a real bug.

 

The torso-less augmented giants and the black line on the Rakshasa image aren't esxactly bugs but are fixable easily enough and ought to be.

 

Does this list include things on other lists? What about not being able to set missile animations for custom objects?

[Formerly II]

The call put_stain_on_space doesn't remove stains when you set the stain type to -1, as it should.

[Kelandon]

So...

 

* In corescendata, Augmented Giant (creature 135) ought to have the line "cr_which_sheet_upper = 1618;"

 

Black line on the Rakshasa image? I don't see one.

 

And are you saying that it_missile_anim_type doesn't work? If so, that'd be the first I'd heard of it.

 

Also, I can't reproduce the put_stain_on_space bug. As far as I can tell, the call works.

[Overwhelming]

Quote:

Originally written by Dahak:
Try opening a door and then while standing one space away from an adjacent space, search the door to close it. The door closes even though you are not nearby.

Is anyone of your party near the door? It doesn't have to be the lead PC.

[*i]

I have had the put_stain_on_space call randomly break when trying to remove stuff as well.

[Kelandon]

So I guess...

 

* The call put_stain_on_space sometimes does nothing. (Any idea as to when or why?)

[*i]

I'll look into why and try to figure it out. It works fine when adding a stain. Removing it appears to be troublesome.

[DreamGuy]

Quote:

Black line on the Rakshasa image? I don't see one.

It doesn't show up in the editor, but actually playing the scenario shows a very distinct 1 pixel wide black line the entire height on the left side, like the image was positioned wrong.

I was going to check the image in the file and see, but ResEdit is having one of its grumpy "freeze if I try to open a graphic" days.

Quote:

And are you saying that it_missile_anim_type doesn't work? If so, that'd be the first I'd heard of it.

Well, I don't know if it never works, but if I try to put something other than an arrow animation on something that fits in an arrow slot, it doesn't work, it just gives the arrow one. I thought I saw in one of the lists of known bugs that it didn't work at all, but I could have misremembered that. I didn't test it on anything else.

[Lilith]

Quote:

Well, I don't know if it never works, but if I try to put something other than an arrow animation on something that fits in an arrow slot, it doesn't work, it just gives the arrow one. I thought I saw in one of the lists of known bugs that it didn't work at all, but I could have misremembered that. I didn't test it on anything else.

I thought it_missile_anim_type was meant to go on the bow, not the arrows. That's how corescendata does it, anyway.

[The Almighty Doer of Stuff]

It probably is supposed to go on the bow, but that seems kind of silly nevertheless.

[DreamGuy]

Oh, so it may not be a bug, it may just be a very strange design decision. The bow itself can't make all arrows be normal/acidic/whatever, those are controlled in the item description for the ammo. What would be the point of changing the animation of the missiles based upon the thing shooting it instead of what's being shot when the differences are controlled by the missile description? And of course the thrown items can set their own animation because nothing throws them, so why program them so they work differently? That's just bizarre.

[wz. As]

Re town_status:

 

As far as I can tell, the town_status calls work if and only if the town passed is -1; in that case, the calls work for the town the party is in.

 

If used outdoors, with -1 being passed as the town, the calls work for the town the party was in last.

 

(edit)

As far as I can tell, Jeff didn't even make the effort to allow working with statuses of towns other than the one the party is in. I believe he either forgot to add full functionality as is described in the docs, or just couldn't find a good way to make it work and simply left it out.

 

(further edit)

This is valid for Mac v1.1.1. As there are still complaints about the calls not working, I assume it's valid for 1.1.2 as well.

[Kelandon]

Another one. This one's beautiful. If you try to use a string variable while nothing's in it (i.e., you forgot the get_buffer_text call), BoA dies. On Mac-BoA v1.1.2, it crashes, gives no error message, and quits. I got this with a message_dialog call, but I imagine a print_str or text bubble would give the same response.

[*i]

I say we bundle these bugs into a list and send it out right after GF3 is released on the Mac.

[Milu]

I'm not sure if this is a bug or not, but you can't exit a town if the border is at the town edge or 1 space from the edge. If there's a border that's not too close to the edge in that town, you can exit through that side of the town.

 

(This is Mac version 1.1.2.)

[Isaac]

On the enter-combat-end-combat bug (which incidentally prevents ending combat at all sometimes with low amounts of space), a simple (though perhaps not complete, still pretty good) fix would be to not move the party at all if when they end combat they are in a normal party order (i.e. player 1 is next to player 2, 2 is next to 3, etc., except of course dead characters don't need to be anywhere).

[Kelandon]

Another one:

 

* A creature whose graphic is set to the wrong size in the scenario's custom objects script (i.e., a small graphic with cr_small_or_large_template = 1) causes even Mac-BoA to crash and quit without an error message when the creature dies. This falls under the heading of "looking for a graphic that's not there."

 

GF3 for Mac is out -- shall we send this now? I can edit in the few additional bugs into the above list, if we want.

[Old MikeS]

Just as an aside, for Win v1.0.3 BOA, you can read outdoor and indoor signs again (I least I work where I didn't with 1.0.2). Hopefully this was fixed with the Mac release at the same time.

 

Mike

[Kelandon]

The list is updated. I'm not going to send this until around the time when GF3-Windows comes out, unless anyone has any reason to send it now.

[Donald Hebb]

print_big_str_num does not actually print text in color, regardless of what the Editor Tech Support Page states.

[SpineRaker]

This is a WEIRD bug. I am currently working on a scenario, as well as play through Bassikava (great scen. btw ). I just went through a bunch of cinematic bug testings, and got tired of it. I then went back to playing in the scenario with my group of adventurers.

 

I then just realised that I has turned the vision variable to 1 (set_total_visibility(1)). I realised this because now, in Bassikava, I can see everything!!! It turns out that when you turn this variable on, it turns it on for the entire game until turned off. This is, imho, a nasty little bug. Anyone would turn it on in a dump scenario, and then go into another--no walls, no secrets. lol More of a cheat, sure, but it is still a bug . Quitting the game resets this, as I have found out.

 

EDIT: Hmm..it just occured to me. Is this listed in any of the warnings in the documentation? Or perhaps already been listed as a bug? (Just remembered you didn't list them all here...) Sorry if it is in either case ^_^'.

[Kelandon]

Funny, I thought this was mentioned in the docs, but I can't find it. The place that I've found was this: "If you set every space as visible, be sure to set them as not visible before ending the cutscene," but he really ought to mention that the total visibility resets to zero only when specifically reset with set_total_visibility(0) or when the player quits and restarts.

[Lilith]

Quote:

Originally written by SpineRaker:
This is, imho, a nasty little bug. Anyone would turn it on in a dump scenario, and then go into another--no walls, no secrets. lol More of a cheat, sure, but it is still a bug .

Considering that it's trivial to open up the scenario script and enable debug mode, having another way to do an aspect of that isn't a huge issue. And it'd be pretty uncommon for a player to trigger this bug accidentally as you did.

Still, it is of course a bug and should be fixed.

EDIT: Hmm. As a workaround to prevent this bug being triggered accidentally in your scenarios, you could always put a set_total_visibility(0) call in the LOAD_SCEN_STATE.

[PoD person]

It was, in fact, accidentally triggered many times in Undead Valley. Of course, that's Undead Valley.

[Lilith]

I said it was hard for a player to accidentally trigger it, not a designer.

[PoD person]

Well, if one were to recoil in terror from the cutscenes in Undead Valley and move on to another scenario...

[Lilith]

Maybe. Strictly speaking, though, UV doesn't exist yet.

[Kelandon]

Another head-scratcher: the call fl_ed_icon_adjust was taken out of the docs at some point after v1.0, and it never worked in the editor, but it still does work on the automap in the game itself.

 

That means that we just need Jeff to put the call back in the docs, and we need to fix the editor ourselves.

 

I'm assuming that the same is true for te_ed_icon_adjust, but I haven't tried it.