Jump to content

Gah!! (Where I bemoan my editor inexperience.)


Balladeer
 Share

Recommended Posts

So, I'm taking a look at the BoA editor for the first time using Issac's 3D editor. Just playing around a little trying to get a feel of it and my first (of which I'm sure I will have many) problem, is placing a cave entrance on the side of a hill. I have my hill but the cave entrance will only be placed on flat ground which has given me a good 15 minutes of frustration in trying to figure out how to get it on there. I'm sure there's some simple thing I'm missing but if someone would explain the trick to me, I'd be most grateful.

 

Thanks in advance for the tons and tons of help I'll inevitably be getting from y'all.

Link to comment
Share on other sites

Exactly which version of the 3D Editor was it, please? Also, can you explain further what you were doing and how the editor responded? If there truly is a bug, at least affecting the version I maintain, I would like to squash it.

 

More specifically: By cave entrance do you mean a town entrance rectangle or the terrain which looks like the entrance to a cave? There's no reason that I know of that autohills should affect either of these.

Link to comment
Share on other sites

As I said in the first post, it's Issac's 3D version, though I didn't mention I'm on windows. It's not your build, Niemand. I was trying to put a terrain that looks like a cave onto an already made hill and the editor just wouldn't respond. It would let me put the cave on the flat ground but not on the hill.

Link to comment
Share on other sites

Ah. It sounds like Dahak has the answer, so I guess I learned something new. Also my build probably is affected, but this sounds like an intentional, if misguided feature. Part of the reason I inquired again about the build is that as I recall Isaac's original version was a Mac program, was ported to Windows by Notus, and both versions are obsolete, replaced by the BoaEdRemake versions. Thus my confusion. Amusingly, it's not that the editor doesn't respond; it makes your change but then immediately overwrites it with one of its own.

 

Whether this as a deliberate choice Jeff or someone else made when writing the auto hills correction code, I'd like to remove it. Unfortunately, this will require entering the madness that is town_fix_hills(). Once again, we learn that autohills is evil.

 

EDIT: I'll still try to fix the editor's behavior, but thanks to the bug in corescendata2 such that the cave hill cave entrances import the wrong base terrain types, even if the editor works right these two terrains still won't be placable as expected. Gah!

Link to comment
Share on other sites

Originally Posted By: Niemand (important part highlighted)
I recall Isaac's original version was a Mac program, was ported to Windows by Notus, and both versions are obsolete, replaced by the BoaEdRemake versions.

Some enlightenment needed here. I thought the Notus port was the most up-to-date version of the 3D editor available.
Link to comment
Share on other sites

Originally Posted By: Niemand
Whether this as a deliberate choice Jeff or someone else made when writing the auto hills correction code, I'd like to remove it. Unfortunately, this will require entering the madness that is town_fix_hills(). Once again, we learn that autohills is evil.

EDIT: I'll still try to fix the editor's behavior, but thanks to the bug in corescendata2 such that the cave hill cave entrances import the wrong base terrain types, even if the editor works right these two terrains still won't be placable as expected. Gah!


It is deliberate as this existed for the original editor Jeff released.
Link to comment
Share on other sites

To clarify a couple of points:

 

  • The most up-to-date versions of the editor to my knowledge are the ones I listed in the 'Which Editor' thread. The windows version was improved by the BoAEdRemake team after being ported by Notus. Unfortunately there has been a historical trend of failing to update the editor's about screen and similar information to make clear which build it is.
  • The more I look at this behavior, the more I think it was laziness rather than intention. The code does date back to Jeff, but it mostly appears that he didn't want to bother doing a little more work to handle a somewhat minor special case. There's nothing in the code that actually suggests it was intended to wipe out other types of hills; it just blindly assumes that only terrains from the two basic hill sets are to be used.
  • There is a bug in corescendata2.txt which relates to the problem, but is not the cause. The cause is the overly simplistic coding of town_fix_hills() and out_fix_hills() which overwrites terrains even if they provide the correct slope to match the hills around them. The corescendata bug is such that even if the editor code is altered it will still reject the two cave hill cave entrance terrains (331 and 332) due to the fact that these terrains are based on the wrong hills for their intended uses; this is why the grid lines the 3D Editor draws for these terrains look odd. Examination shows that this bug is already listed in the BoA bugs thread.
Link to comment
Share on other sites

I've started reading through the BoA Editor Docs v1.2, but it reads rather rough (like it was written by someone who's been programming for a couple decades and can't think like a beginner any more) and I was wondering if anyone's made a more easily understandable guide or one that focuses more on the differences between BoE and BoA and what you have to do differently in designing.

 

If not, subsequent recommended readings are welcome.

Link to comment
Share on other sites

Blah. That wikibook is just a poor transcription of the appedices; don't waste your time with it. You may want to take at Erik Westra's Cookbook, it takes a somewhat different approach, giving recipes for common tasks rather than enumerating all of the available building blocks of the system. You can find it hosted on Kelandon's site.

 

By the way, the Editor Docs actually aren't bad at all in terms of basics, they're just in a rather poor order. I'd recommend sections 1.1 through 1.3, section 2.1, and section 2.8 when you're ready to get started writing scripts. Sections 1.4 through 1.7 and 2.2 through 2.7 really should have been appendices or something; their mostly just lists of information that you refer to while working, not text you want to read before starting.

 

As far as I know, no one has really written a "BoA for BoE designers" sort of document. However, section 3.1 of the Docs might be helpful, as it describes how many objects or concepts from BoE can or can't be ported to BoA.

Link to comment
Share on other sites

I'll second what Niemand said. Cookbook == good. Wiki == sux. Kel has some articles on his site as well; they vary in scope, but I think he has some pretty broad ones that might be good for learning to script.

 

The docs aren't too bad. Section 2 covers basic scripting fairly well, with the exception of 2.2 - 2.7 (which are useful but do indeed belong in the appendices-- which is why I moved them there on my computer.)

Link to comment
Share on other sites

Is there something wrong with my view of the editor? The last line is partially cut off and there is no big example of the terrain/floor that I have selected. It's rather annoying to have to put a terrain into my town to see what it really is.

 

As far as I can tell, I can't make it any bigger.

 

PS. Pay no heed to the terrain, I'm just putzing around with it.

Link to comment
Share on other sites

I can live with the bottom line being cut off. I just thought maybe I was missing a preview of the selected terrain, like BoE had. Of course, it kinda makes sense that it's not included since Jeff originally made the editor in 2D. It wouldn't have looked right anyway.

 

An extra 'Thank You' to those who worked on the 3D editor since it's obviously 100x easier than it used to be.

 

Edit: Is there a way to double up terrains (ie. walls or columns that are twice as high) without making custom graphics?

 

And is there a graphic to make indoor rises not look like dirt cliffs?

 

Edit2: Gah! Stupid walls that look like they only take up a sliver of a space but really take up a whole square...

Link to comment
Share on other sites

Originally Posted By: Jewelz
Edit: Is there a way to double up terrains (ie. walls or columns that are twice as high) without making custom graphics?

te_second_icon can be used, but the problem is that both icons have to be within the same sheet. Of course, for what you're describing, that shouldn't be a problem.

Also, for walls, Select Town from the menu bar across the top, and select Town Details from the list of options that shows up. Then simply input the desired height for the wall you wish to double up.

Quote:
And is there a graphic to make indoor rises not look like dirt cliffs?

In the Town Details box, simply input the number of the sheet you want in Cliff Sheet. A small list of possible options is there within the dialog box, and a full list can be found in the BoA Appendices.

Originally Posted By: Nikki.
Sorry to prove you wrong, Nioca, but:

http://i37.tinypic.com/2ccqpmp.jpg

Maybe it's an issue with XP?

Maybe it is. But there's nothing Jewels and I can do about it.
Link to comment
Share on other sites

I might add that in my experience, if you want to port a BoE scenario to the BoA world you will find that a lot of BoE features don't exist in BoA.

 

Return party to start is one example. Ditto fear effects on weapons. Then you can only move to another town via a special rectangle placed on the ground.

Link to comment
Share on other sites

Originally Posted By: Ishad Nha
I might add that in my experience, if you want to port a BoE scenario to the BoA world you will find that a lot of BoE features don't exist in BoA.

Return party to start is one example. Ditto fear effects on weapons. Then you can only move to another town via a special rectangle placed on the ground.


...right, which is why most of us don't bother trying to port pre-existing Exile scenarios. Well, that and the whole "originality" thing.
Link to comment
Share on other sites

Right then, I'm trying to define my first custom terrain graphic (animated statue fountain) and was thinking it'd be handy to import the waterfall since it's what I used to make it, but I'm not really seeing a number anywhere (editor, docs, appendix, cookbook) to distinguish it from the rest. Am I supposed to just count down from the top in the editor or what?

 

Edit: Me found it. smile

Link to comment
Share on other sites

If you really want to understand the differences between Exile and Avernum, you can't go past porting a BoE scenario to the BoA world.

 

Redwall might be problematic here because the Windows editor has a porting process that is meant for totally plain vanilla scenarios, where walls occur only in slots 5-19 and 122-169.

 

The porting for the Windows editor has all sorts of idiosyncracies and flaws but it will give you a very good feel for the differences.

Link to comment
Share on other sites

Whilst I'm not doubting that porting a scenario will help a designer see the differences in the two engines, I think that spending an hour or two just painting terrain will let you get the hang of how terrain now works in BoA in a much more constructive way.

 

When you're starting out, it's important to grasp what looks good in the new engine, and that can only be done by trying things out, not by porting old scenarios - when I tested the import tool, I ended up having to change over half, and I'd say closer to three-quarters, of the terrain. For any designer that's a waste of time. Unless you desperately want to import an old scenario (and I'm assuming Jewels isn't trying to import Redwall, since the scenario she's working on is for Dahak's contest), and it's heavy on the towns/outdoor areas, it's probably much easier to just start from scratch.

Link to comment
Share on other sites

Yeah, I must be blind for missing it the first time I looked.

 

In other news I now have a pretty, pretty bathhouse and a good feel for how (at least terrain) graphics work. Looking at the code for a different scenario helped the most. Learn by example.

 

Edit: I wasn't planning on porting Redwall at all mostly because it's not really my story. That and I suck at 3D graphics and Redwall needed a lot of custom ones.

Link to comment
Share on other sites

The import tool is almost a joke when the original BoE scenario is full of customized terrain, items and creatures. It is easy to customize the translation tables used for these objects. (There are quite a few mistakes in the porting tool, omissions and outright clangers. Some can be fixed by hex editing the editor but many can't.)

 

But the snag is the walls. Many designers had walls outside of the standard 122:169 place, or had non-wall terrain inside this. Here I would need to create a special version of the scenario with specially translated walls before the porting happened.

(Edit: this is easy to do with the use of custom-designed translation spreadsheets.)

 

Porting will especially enable you to see how BoE nodes are turned (or not turned) into BoA script states. The real engine differences are found here.

(Edit: the engine differences that involve a lot of subtle detail, the ones that are not immediately apparent.)

 

Looking at the Redwall graphics, many of them are just color edits, no great problem there. Creature graphics could be used at a pinch.

 

Link to comment
Share on other sites

It is not only the terrain or the calls it is the subtler things. While playing the game, I can't seem to place an item on an adjacent table or into a container. In BoA any time an item is dropped it will end up on the floor in the same square as PC doing the dropping. Thus there seems to be no directional dropping as in Exile.

 

For placing items on tables, you would need to use a terrain script, that would subtract an item of type # from the player's inventory then place another such item on top of a table.

 

Putting an item away into a container? No call can make the item contained.

Link to comment
Share on other sites

Originally Posted By: Ishad Nha
It is not only the terrain or the calls it is the subtler things. While playing the game, I can't seem to place an item on an adjacent table or into a container. In BoA any time an item is dropped it will end up on the floor in the same square as PC doing the dropping. Thus there seems to be no directional dropping as in Exile.

For placing items on tables, you would need to use a terrain script, that would subtract an item of type # from the player's inventory then place another such item on top of a table.

Putting an item away into a container? No call can make the item contained.



Yeah, but that's why the BoA docs say "play BoA! A lot!" (paraphrasing.) It's why any prospective new designer is told to "play BoA! A lot!" by the community. Anybody who's been through, at the very least, the 4 pre-packaged scenarios will know that there's no directional dropping, that you don't have to go into combat-mode to fight, the differences in the dialogue engine, hills, and so on.

I, for one, can see that importing an old scenario might, might, help with terrain design. It might even help with scripting - seeing how old nodes are now written out, without having to do it yourself. But, there are tutorials (the cookbook, for one) for scripting - and learning to write code yourself, and understanding what the code does, is much easier than letting the engine translate it - especially in the long run. Example: TM recently helped Nicothodes with some code in her scenario. There was a tiny error in it, but since he'd said "oh put this in", without explaining the call, or how it works, she had no idea how to fix it. She knew what was happening to a player when the call was triggered, but it was only when I went and commented the code, and explained, that she got what was happening with the code.

I just feel I'm flogging a dead horse. And yes, Ishad, I know you've successfully ported a BoE scenario (so have I incidently, and it was only useful for giving me an outline of the map), but I still stand by what I'm saying - playing the game, and just spending a little time drawing terrain, maybe placing a one-shot special or two, is much better for a designer than importing.
Link to comment
Share on other sites

In summary, the biggest single difference is the need to learn scripting to do anything advanced. Avernum script is quirky and limited, so you need to be ready for programming circumlocution.

 

A lot of things that are easy in BoE are convoluted or impossible in BoA. See the Codex in the Lyceum for various solutions to scripting problems. Eventually I figured out how to script timers, that took trial and error.

Link to comment
Share on other sites

That'd be easy too. You could just, depending on how close together the events are supposed to happen, use the same SDF countdown, and call different things then the flag equalled different amounts.

 

For linked counters, of more than 255 turns, there are two ways. Firstly, you could just set a whole bunch of SDFs to 255, and then decrease them one at a time, triggering the next in the chain when the current flag had reached zero.

 

Secondly, you could just use two flags, and do something like this:

 

Code:
 if(get_flag(1,0) > 0) {       inc_flag(1,0,-1);} else {       set_flag(1,0,250);       inc_flag(1,1,1);}

 

The flag (1,0) is the actual counter, whilst flag (1,1) will count how many times the counter has reset. This would allow you to pinpoint when events happen - suppose you want an explosion after 600 turns - check that flag (1,0) equals 150, and that (1,1) equals 2.

 

 

 

Link to comment
Share on other sites

Shouldn't (1,1) be 3 at 600 since it will be 1 at the initial setting?

 

From turn 1-250, (1,0) has had 250 added to it once

From turn 251-500, (1,0) has had 250 added to it twice

From turn 501-750, (1,0) has had 250 added to it 3 times

 

Unless you're gonna initially set (1,0) to 250 in a different code.

 

I like math, it's so logical.

Link to comment
Share on other sites

No, this is pseudo-base 250 math, if I understand correctly.

(2*250^1) + ((250-150)*250^0) = 500 + (250-150) = 600

So you want flag 1,1 == 2 and flag 1,0 == 150

 

The best way to do long timers in my opinion is to use base 256 math with a pair of flags. See this post for a compact way to do the math to pack a full sized integer into two SDFs and then unpack it again. Using that, you can just store a number like 1000, and steadily reduce it until it hits zero.

Link to comment
Share on other sites

I struck problems with the timers. I forget what the problems were. It seemed that the Start State could not reliably handle two SDFs at once. Chaining worked okay if you were always using the same interval.

 

If you were using arbitrary intervals, see my post here:

http://thelyceum.yuku.com/topic/1902/t/BoA-Timers-v1-0.html

Link to comment
Share on other sites

Originally Posted By: Ishad Nha
I struck problems with the timers. I forget what the problems were. It seemed that the Start State could not reliably handle two SDFs at once. Chaining worked okay if you were always using the same interval.


Are you sure you didn't make a programming error? People have put very long blocks of code involving multiple SDFs in the START_STATE and had it work perfectly.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...