Pop-rivet my skull, please.

[Xoid]

Check out corescendata2.txt - terrain #172 and terrain #173 are obviously fences, yet are named windows. Jeff used the import = whatever; feature to great effect I see. sigh... Is this one of these things that will get fixed, or does BoA get similar support to BoE?

[Poit]

I think someone comiled a list of bug fixes a while ago and sent it to Jeff. Seeing as Avernum 4 is the new cash cow I doubt anything will come of it.

[Xoid]

This is one of these 'oh my god, that is so easy to fix!' kinds of bugs.

 

By simply adding

Code:

te_name = "Fence"

to those two entries, it is fixed. Nothing more than an oversight really.

[Lilith]

The trouble isn't in the fixing; it's in the updating. Jeff's main excuse for not updating is that he doesn't want to make people download updates. (Yes, I'm sure you can think of several ways in which this doesn't make sense, both in general and for this particular example. Try telling that to Jeff.)

[Kelandon]

Fortunately, this is also one that we can fix ourselves. Just make a custom objects script that fixes all the errors in corescendata and always start with that when you make a new scenario.

 

In fact, I imagine that once the BoA Editor Re-make is finished, we can just make the editor automatically generate a fixed custom objects script with each new scenario.

[KernelKnowledge12]

Quote:

Originally written by Kelandon:
In fact, I imagine that once the BoA Editor Re-make is finished, we can just make the editor automatically generate a fixed custom objects script with each new scenario.

Actually it'd be easier to create a base custom object script and package it with the 3D editor, as is done with the warrior's grove data. I'd have to add a few extra lines to the code to automate copying, which I won't be able to do for a week or two, but after that is done it would only be neccessary to update the base script. Of course someone will have to build the OS X version.

[Kelandon]

That's what I meant. I just wasn't able to say it correctly.

[Xoid]

This little bit of code is really giving me a headache...

 

Code:

begindefineterrain 434;	clear;	te_name = "Fence";	te_which_sheet = 717; // te_which_sheet = 788;	te_which_icon = 6; // te_which_icon = 1;	te_ed_which_sheet = 688;	te_ed_which_icon = 99;	te_icon_offset_x = 20; // te_icon_offset_x = 0;	te_icon_offset_y = 13; // te_icon_offset_y = 0;	te_move_block_e = 1;	te_can_look_at = 0;	te_draw_on_automap = 1;	te_beam_hit_type = 1;

When I press 'L' to look, this terrain feature comes up as selectable. I have tried it with te_can_look_at = x; as 0, I've tried it as 1, I've tried it without that line altogether. Same result every time. What exactly am I doing wrong here?

[Swimmin' Salmon]

Is using terrain number 434 acceptable for a non-searchable terrain? I've got nothing else, since I'm at work, working hard, and can't be bothered to not work.

 

Really.

 

*this message sponsored by work*

[Ephesos]

I've had that same problem, actually. Somehow, one group of trees just keeps coming up as searchable (it's in DoK), and I never did figure out why.

[Xoid]

In an older thread: "te_can_look_at strangeness", spiderbytes mentioned that "te_can_look_at" was dodgy, only working properly in conjunction with a terrain script. In a different thread, The Creator mentioned that "te_can_look_at" either didn't work at all or didn't work properly. Has anyone actually been able to lock down the idiosyncracies of this pesky little call?

[Lilith]

My suspicion is that there are some terrain properties which automatically make a terrain look-at-able, overriding the te_can_look_at property. Try deleting lines one by one from the terrain definition and seeing if the terrain can still be looked at after each line is removed.