Code Discussion Thread

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I don't see any reason to load the entire outdoors at once.

What i wanted to suggest was that an array pointing to every outdoor section could be good think (to avoid navigating using universe shift up/down/left/right)

The only thing is, this requires having all the outdoor sections in memory at the same time. On the other hand, it may be acceptable. That would take up 414,600 bytes of memory, or almost 405 kB – barely a scratch for people who have more than 256 MB (ie 262,144 kB or 268,435,456 bytes) of RAM available. And that's only if there are 100 outdoor sections. Most scenarios have less, and if the array was dynamically allocated then

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

With the map hiding for town, I'm making it a property of the town. So, one town may have a hidden map while another doesn't. If we also make it a property of the outdoor section, we can't use the same code, because there are 4 sections loaded at once, not all of which have hidden maps. So we'd still have to draw something to the map, that is, the terrain of the adjacent sections whose maps are not hidden.

Can't we make a check to see if the party is in a section to be hid (see party.i_w_c) ?

So, if they're in the section that's hidden, they can't even see the map of the area outside that section? That's really the thing I'm having a bit of an issue with...

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Okay, yet another thing for me to fix...

I've provided a possible fix in the Edit section of the previous post

Yes, I did in fact see that.

EDIT: A very minor note: the string displayed should begin with two spaces rather than one – that's how much strings are usually indented in the transcript.

[Lilith]

I don't think the Heal Target ability should be fixed: it's supposed to be used for cursed items, so it's not meant to have a beneficial effect.

[Celtic Minstrel]

Then again, why would anyone shoot themselves? Especially if they don't know that the arrows have that ability? (I'd think arrows with the ability are likely to have it concealed.)

[Lilith]

I always thought Heal Target was an ability for wands, though, not missiles. Is there a missile version that I forgot about?

[Celtic Minstrel]

Yeah, ability 128, a Spell Usable, is Strengthen Target (used by Wand of Carrunos); and ability 176, a Missile Ability, is Heal Target. I'm not sure if they do the same thing, but they at least have in common that they do something beneficial to the target, which usually is not desirable.

 

 

The Missile Ability is the one that's been changed.

[Chokboyz]

Originally Posted By: Celtic Minstrel

I'm not sure if they do the same thing, but they at least have in common that they do something beneficial to the target, which usually is not desirable.

Strengthen Target heals 20 HP to a monster (whatever the ability strength) and Heal Target heals a random number of HP (influenced by the ability strength) to the target (previously monster only, it was damaging the pc. The Strengthen effect gives a "Nobody here" response if used on a pc).

Chokboyz

[Slarzahl]

I think there were some cursed arrows made at some point designed to heal instead of hurt, without making that explicit. So I wouldn't call that a bug either, just poorly advertised.

[Chokboyz]

Quote:

I think there were some cursed arrows made at some point designed to heal instead of hurt, without making that explicit. So I wouldn't call that a bug either, just poorly advertised.

When used on PC such arrows would damage them instead of healing them. The question is to fix that or not (as it always heals monsters)

Chokboyz

[Slarzahl]

The intention is a curse, so that makes sense. If they allowed you to heal any targetable PC for far fewer action points than spells consume, they would actually be quite a good item.

[Chokboyz]

Ok, i guess we will revert it back to the original behavior then ...

 

Chokboyz

[Celtic Minstrel]

*sigh*

 

I understand your point that it's supposed to be a curse, but it still doesn't make sense that it does two different things depending on who it hits...

[Slarzahl]

Why not? Anyway, the point is it's that way for a reason, whether or not you like the reason. By all means create a new special ability that does what you're suggesting, but leave the old one; somebody might have used it as it was intended.

[Celtic Minstrel]

I'm not disputing the reason for it; I'll even remove it from my code. I'm just saying it doesn't make sense.

[Celtic Minstrel]

For example, I'd be happier if the game would simply cause heal target missiles to always miss if targeted at a PC.

 

 

...Anyway... the point of this double post is: SDF rows 300 through 303 seem to be completely unused! And the same for 307 through 309! Why are we restricting ourselves to row 305 when there are seven rows completely empty? Next time we need an SDF for internal use, we can pick one from a different row.

[Slarzahl]

Originally Posted By: Celtic Minstrel

...but it still doesn't make sense that it does two different things depending on who it hits...

Originally Posted By: Tri-Consonantal Rout

Why not?

Originally Posted By: Celtic Minstrel

I'm just saying it doesn't make sense.

Not to belabor the discussion, but I really am curious why it doesn't make sense.

[Niemand]

His point, I think is that the behavior of the ability is inconsistent, literally having opposite effects at different times. This doesn't fit well with the general theme that an item ability does some simple this, the same way, to anything that it is used on.

 

On the other hand, I think the reason that you are viewing it differently, Slarty, is that you are seeing the action as a curse with limited intelligence so that its action is not to heal the target, but rather to do whatever is least convenient for the user. It seems to me that there may still be an inconsistency in that the curse, as it appears to currently be implemented, is only an annoyance to the party, but this won't matter much if a hostile NPC is never armed with such an item. (Further side-note: Full consistency would really only be achieved if the curse differentiated between NPCs on different sides, but that's likely more complicated than anyone cares about.)

[Celtic Minstrel]

I've reverted that particular change, by the way.

 

And Niemand puts it quite well.

 

Originally Posted By: Niemand

(Further side-note: Full consistency would really only be achieved if the curse differentiated between NPCs on different sides, but that's likely more complicated than anyone cares about.)

Especially when there are actually three potential sides if you take Hostiles A and B into consideration...

[*i]

Quote:

I don't see any reason to load the entire outdoors at once. I don't think it would really provide any significant advantage, and it would be difficult to change; and also if the outdoors is large enough it may even be a bad idea (not sure though). If we decided to do it, though it would have no effect on the scenario format. Maybe the savegame format, but not the scenario format.

When I still had time for this, I tried to modify the source to get it to hold the entire outdoors in memory. I cannot remember the exact reason except that it did help with the new, more flexible, scenario format I was working on.

[Celtic Minstrel]

In monst_check_special_terrain(), when checking is_force_barrier(), there's a check for the town number being greater than 20, which means that a monster can't break down a force barrier in towns 0 through 19 but can in towns 20 and up. This seems utterly pointless, so I've removed it.

 

A comment in that section of the code implies that the intention may have been to prevent monsters from breaking barriers in large towns, so it could be an E3 relic. The question, then, is: should we simply remove it, as I have, or should we replace it with a check for town size?

 

Ishad, do all large towns in E3 have a town number less than 20? Not including the module towns, that is.

[*i]

As far as I know, this should not break compatibility with any scenarios, so it should probably be removed. There is no reason for something like this and is probably an E3 relic.

[Chokboyz]

Originally Posted By: Celtic Minstrel

In monst_check_special_terrain(), when checking is_force_barrier(), there's a check for the town number being greater than 20, which means that a monster can't break down a force barrier in towns 0 through 19 but can in towns 20 and up.

That's also present in the Windows code. That ought to be a relic, since with this code monsters with Permanent Martyr's Shield won't mind getting in fire walls (why not ...) and monsters with Paralysis Ray won't mind getting in ice walls (that's weirder) ...

Originally Posted By: Celtic Minstrel

The question, then, is: should we simply remove it, as I have, or should we replace it with a check for town size?

That mainly depends on Ishad Nha's response. I would remove it since i doubt that breaks any compatibility (don't hesitate to correct me here) or at least do as you proposed : change the check to large town ...

I've finally found the real cause of the torches and campfire squares appearing as colored dots on the map, and that is another relic of Exile III ...
The main culprit was the boom_space() function. That function copied the field effect to a temporary location combining it with terscreen.bmp blank effect (for transparency), then draw it back into the game. The bmp it was copied to was mixed.bmp.
Unfortunately, mixed.bmp changes from Exile III to BoE and the (once) white square there has been filled with the last animated terrains. So each time you boom a space (hit a monster, cast a fireball, walk on a "zap" floor, ...) this part of the bmp (in the memory) will be overwritten, hence the colored dots.
I've removed the copying and adapted the function (the transparency function had already been fixed). That fixed the bug.

By the way, I don't think this problem appears on Mac (as no copying is done as far i can tell).

Hope it helps,
Chokboyz

[Ishad Nha]

"Ishad, do all large towns in E3 have a town number less than 20? Not including the module towns, that is."

Look at my reference spreadsheet for any questions here,

http://www.freewebs.com/ishadnha/E3ScenarioDataRecords.zip

What we see is that towns 0 thru 19 are the five main towns, Krizsan, Shayder, Sharimik, Lorelei and Gale. Each of the five main towns has four versions, each version is more wrecked than the previous one.

Town 20 is the town I call Module Town. Towns 21 thru 38 are the large size towns. Town 39 is large size and blank.

(Towns 40 thru 79 are the medium size towns. 80 thru 119 are the small towns. 120 thru 199 are the module towns, all of which are medium size.)

[Celtic Minstrel]

Okay, so all towns < 20 are large then, but there are other large towns > 20.

 

Interesting that all the module towns are medium sized...

[Celtic Minstrel]

In do_combat_cast(), there are several "if((summon < 0) || ..." lines. Since summon is an unsigned char (though I've changed it to unsigned short), this will always be false. However, since I'm pretty sure summon holds the ID of the monster to summon, I changed these to compare equal to zero rather than less than (since 0 is not a valid monster). I doubt this particular code could have been responsible for any appearance of Empties, since I'd assume Empties have a summon type of "no summon", but it was wrongly considering 0 to be a valid monster.

 

EDIT: In monst_fire_missile(), the skill parameter is unused. Surely it should be used?

[Lilith]

Originally Posted By: Celtic Minstrel

In monst_check_special_terrain(), when checking is_force_barrier(), there's a check for the town number being greater than 20, which means that a monster can't break down a force barrier in towns 0 through 19 but can in towns 20 and up. This seems utterly pointless, so I've removed it.

A comment in that section of the code implies that the intention may have been to prevent monsters from breaking barriers in large towns, so it could be an E3 relic. The question, then, is: should we simply remove it, as I have, or should we replace it with a check for town size?

Removing it is a good idea, but replacing it with an option in Town Details is a better idea. Having a town in which monsters can't break through force barriers would be useful for some purposes.

Originally Posted By: Celtic Minstrel

EDIT: In monst_fire_missile(), the skill parameter is unused. Surely it should be used?

Not sure. If you gave something 0 skill and the Good Archer ability, presumably you wanted it to be great with missile attacks but unable to hit worth a damn in melee.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Since summon is an unsigned char

Interestingly enough, Windows code declares

Code:

short summon;

And that may interest you (straight from the Mac code)

Code:

short get_summon_monster(short summon_class){	short i,j;		for (i = 0; i < 200; i++) {		j = get_ran(1,0,255);		if (scenario.scen_monsters[j].summon_type == summon_class) {			return j;			}		}	ASB("  Summon failed.");	return -1;}

Seems like summon was supposed to be signed after all (and yes, the Empties are "No summon" type).

Originally Posted By: Celtic Minstrel

monst_fire_missile(), the skill parameter is unused. Surely it should be used?

If i'm not mistaken, the missiles damages are fixed ...
The skill parameter is oddly (again) inexistant in Windows code ...

Hope it helps,
Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Seems like summon was supposed to be signed after all (and yes, the Empties are "No summon" type).

Well, not really. It refers to a monster type, which is a number greater than 0. So, I think I'll change that return statement to return 0 instead of -1. Otherwise we might get random occurences of Monster #255 appearing (or worse, Monster #65535, which most likely doesn't even exist). It also seems to me that the "Summon failed" message in that function is somewhat redundant...

Originally Posted By: Chokboyz

If i'm not mistaken, the missiles damages are fixed ...
The skill parameter is oddly (again) inexistant in Windows code ...

Okay, so I've removed the parameter.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Well, not really. It refers to a monster type, which is a number greater than 0. So, I think I'll change that return statement to return 0 instead of -1. Otherwise we might get random occurences of Monster #255 appearing (or worse, Monster #65535, which most likely doesn't even exist). It also seems to me that the "Summon failed" message in that function is somewhat redundant...

Indeed, it doesn't need to be signed (and even shouldn't) ...
If you intend to left summon as unsigned short and correct the return value, in the function monst_cast_mage(), the r1 value in summon checks must also be correct.
The "summon failed" message seems to be in fact redundant ...

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Indeed, it doesn't need to be signed (and even shouldn't) ...
If you intend to left summon as unsigned short and correct the return value, in the function monst_cast_mage(), the r1 value in summon checks must also be correct.

Geh, okay, I'll fix that too then.

Originally Posted By: Chokboyz

The "summon failed" message seems to be in fact redundant ...

I'm not entirely sure though – you'd need to check every place where the function is called and make sure it displays the message if the function returns 0.

[Ishad Nha]

Monster type 0 is a null monster, the char was unsigned, so there is no possible way to record "-1" for a non-existant monster, so 0 is used instead.

[Celtic Minstrel]

Note: Anywhere an unsigned char variable is used to store a terrain type or a monster type it must be changed to unsigned short! Otherwise we won't be able to extend the limit on the numbers of monsters and terrains. Local variables in particular should be looked out for.

[Celtic Minstrel]

Argh, nothing seems to work right. The first sign of trouble is a special failing to trigger. This must be some kind of failure to transfer the special's existence to the fields variable, since the scenario editor still displays the icon on the square. And then checking that reveals that for some reason the scenario editor isn't handling keypad input properly nor displaying the centre position correctly. And I'm not even sure whether the problem lies in the load functions or in the actual logic, though I suspect the former is at least partly to blame.

 

On a slightly brighter note, the game can now load an old-format savegame that's not in a scenario. I haven't tested for when the party is in a scenario, mainly because I have no idea which scenario my parties are in and if they're in any scenario other than the default three it won't find it.

[Chokboyz]

Originally Posted By: Ishad Nha

Monster type 0 is a null monster, the char was unsigned, so there is no possible way to record "-1" for a non-existant monster, so 0 is used instead.

True, but in the Windows code (thus supposely in the Exile III code) the summon type was short and the checks completely valid (if < 0, do nothing).
The problem was that with this code, summoning monster 0 was possible (and summoned monster 0 never disappeared because of the range of the "end of summoning ?" check).
So it should indeed be fixed.

Originally Posted By: Celtic Minstrel

Note: Anywhere an unsigned char variable is used to store a terrain type or a monster type it must be changed to unsigned short! Otherwise we won't be able to extend the limit on the numbers of monsters and terrains. Local variables in particular should be looked out for.

Added to ToDo list ... (idem with gold, food, day (?), ... ?)

Originally Posted By: Celtic Minstrel

the game can now load an old-format savegame

Originally Posted By: Celtic Minstrel

because I have no idea which scenario my parties are in

Load the party in memory and read the party.scen_name field. That won't help if not in a default scenario though

Hope it helps,
Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Note: Anywhere an unsigned char variable is used to store a terrain type or a monster type it must be changed to unsigned short! Otherwise we won't be able to extend the limit on the numbers of monsters and terrains. Local variables in particular should be looked out for.

Added to ToDo list ... (idem with gold, food, day (?), ... ?)

I've changed gold and food to unsigned short already. I didn't make age an unsigned long until just now, but it certainly makes sense to do so. I also changed total_m_killed, total_dam_done, total_xp_gained, and total_dam_taken to be long longs. Does your compiler support 64-bit integers? If not, it soon should, since they've been added to the new C++0x standard which is currently in progress. Should age be 64-bit? It's still long, but I could make it long long. Is there any chance of a scenario lasting more than 4,294,967,295 moves? That'd be about 1,160,801 days, so I guess probably not. Making it long long would increase the number of days a party could be in a scenario to about 498,560,650,640,798,692 days, so I guess that's rather unnecessary.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

the game can now load an old-format savegame

Originally Posted By: Celtic Minstrel

because I have no idea which scenario my parties are in

Load the party in memory and read the party.scen_name field. That won't help if not in a default scenario though

True, true, or I suppose I could open it in the unchanged copy of the game. I don't want to try opening a party in a scenario yet, though – not until I know the scenario loading is working properly.



I don't suppose anyone has time to review my code? Particularly the loading code – I suspect there's a problem somewhere in there, but I'm not sure where. (It's all in fileio.cpp and the various classfiles.)

[Celtic Minstrel]

All evidence seems to point towards me being wrong about the problem being in the loading code. So, if that's the case, the problem must be that the game is not accessing the right data, or something. Possible problem functions include init_town() and the two _move_party() functions. Symptoms include town specials failing to trigger, outdoor strings not displaying (though the debugger indicates that they were loaded perfectly well – maybe the problem is they're being reloaded from the file rather than accessed from memory? Maybe commenting the prototypes for load_outdoor_str() will be enlightening.), and... I forget what else, actually.

 

I also have no idea why the editor wasn't properly responding to the keypad. Maybe if I'm lucky it'll fix itself...

[Celtic Minstrel]

Whoa. Okay, the specials not triggering in town is fixed. There's still a problem with webs appearing where they shouldn't – I'll have to look into that, though it's not that important. I also discovered and fixed a bug whereby loading a party would actually append the characters in that party to the current party, provided there was space available. While something like this would probably be a nice feature, it's not what we want when loading a game.

 

Now I need to determine why webs appear randomly and why outdoor strings display incorrectly.

 

 

P.S. I hope people don't mind the multiple posts?

[The Almighty Doer of Stuff]

Better multiple posts than one huge post. At least this way I only have great difficulty following what's going on, rather than extreme difficulty.

[Celtic Minstrel]

Oh good, someone agrees.

 

Well, outdoor strings partially fixed (signs work, special strings don't). There's a problem with outdoor wandering encounters and special encounters; the latter definitely don't appear and it seems the former don't either.

 

I think those are the last of the major bugs. Once that's fixed, I'll move on to see what I can do about the problem with the Custom Scenarios button not detecting any scenarios, and then I'll write a Save Party function. Then I will (finally) upload a "beta" executable to the site.

 

 

Then I'll probably switch to improving the scenario editor.

[keira]

Here;s a feature request:

 

Have an option to display animated terrain as animated (eg. go through all 4 frames when editing the map) in the scenario editor.

 

I'm assuming it could be possible to just steal the code from the game?

[Celtic Minstrel]

Wow. How do I make these errors? The problem with webs appearing in the wrong spot turned out to apply to all fields and SFX, and was a simple matter of placing them at special_locs[ i ] instead of at preset_fields[ i ].loc.

 

As for animated terrain in the editor, I don't think that's something I'm going to do, simply because there's no real need. Even if I were to do it, it's incredibly low priority.

 

By the way, if you have a feature request which you don't want forgotten, consider posting it here. (Unless it's already in the first post of this thread, in which case there's little point... though you could anyway.)

[Celtic Minstrel]

I forgot to mention, the outdoor strings were fixed last night.

 

 

 

And why does the debugger keep crashing!?

[Celtic Minstrel]

Oh my, this one was a loading problem – I simply forgot to copy the monster lists in the outdoor wandering type.

 

 

Okay, last thing (I think) to fix is town entry. For some reason I'm placed at (0,0). Which does show that the unused room rectangles are placed there, just like in the outdoors, but isn't really helpful for actually entering the town.

 

Oh, another thing – apparently if you're at the extreme edge of town, you can't leave. (Except that you can leave diagonally if you're in the corner.) Not that this is particularly useful though.

[Celtic Minstrel]

*facepalm* Well, that was amazingly simple. I was just a little overzealous in commenting stuff out when I changed something in the conversion functions. Instead of commenting out just the town wanderings code, I also commented the town entry and exit locations.

 

I also discovered and fixed a bug that caused the buttons to do nothing in combat. Presumably this meant you would never be able to end combat mode. It doesn't matter though, since it's fixed. I just had to change a > to >=.

 

SO.

 

• Must fix dialog graphics engine so that the graphics are drawn properly (on a black background instead of a white, for starters).
• Must fix custom scenario button so it can find them.
• Must write Save Party function (and nav_put_party).

 

There are other bugs, though. I went and fought some goblins, and used Fireball against them, but after the fiery explosion I saw them take what appeared to be weapon damage.

[Celtic Minstrel]

Custom scenarios are now detected, and the three default scenarios are excluded from that list. Once I write the Save Party function, it should be ready to release... except for one problem. I can run the program perfectly well through Xcode, but when double-clicking it in the Finder it instantly quits, almost before the icon even appears in the Dock.

 

I'll look into it, but I'm really not sure what could cause this, so any ideas would be welcome. I assume it's something in the initialization.

 

I'm not going to do anything else (other than the Save Party function) until it can be launched by double-clicking in the Finder. If I can't figure it out, I'll start working on the Scenario Editor.

[Chokboyz]

Ok, when party is split the lone pc only will now be affected by Affect Health/SP/Skill Points/Statistics and Give Mage/Priest Spells.

The Kill/Raise Nodeis left untouched for compatibility reasons (although we can implement a "kill only present pc" switch via pic if revelant).

 

Sample of the code used (Affect Health Node) :

Click to reveal..

case 82:

for (i = 0; i < 6; i++)

if(PSD[304][0] > 0 && adven.main_status == MAIN_STATUS_ALIVE) //party split ?

adven.cur_health = minmax(0, (int)adven.max_health,

adven.cur_health + spec.ex1a * ((spec.ex1b != 0) ? -1: 1));

else if (PSD[304][0] == 0 && ((pc < 0) || (pc == i))) adven.cur_health = minmax(0, (int)adven.max_health,

adven.cur_health + spec.ex1a * ((spec.ex1b != 0) ? -1: 1));

break;

 

Originally Posted By: Celtic Minstrel

used Fireball against them, but after the fiery explosion I saw them take what appeared to be weapon damage.

Seems like a problem with boom_space() or add_explosion() ... Speaking of which, in your code, you've merged boom_space() and pre_boom_space() function and commented the type = type % 10 line, but the boom_space() function is called in damage_monst() with type = 51 ... The boom_space() function then does nothing because type is not between 0 and 4.

That doesn't seems to be the cause of the bug mentioned above (it's much likely add_explosion), but that can be a potential glitch ...

 

Originally Posted By: Celtic Minstrel

Custom scenarios are now detected, and the three default scenarios are excluded from that list. Once I write the Save Party function, it should be ready to release...

Good job

 

Hope it helps,

Chokboyz

[Celtic Minstrel]

I shall implement those changes soonish.

 

In the meantime, I've written the save_party function. That doesn't mean saving is functional though, since it relies on writeTo() functions in each class. I also need to rearrange the loading code so that it branches depending on the type of file it encounters. (It would also be nice if the game could load old-format saves from both Windows and Mac.)

 

 

 

Also in the meantime, I have no idea why the program won't run from the Finder, and I don't even think I can debug it when opening it in that way, except I guess by putting in SysBeeps. I'll continue to look into it though.

 

EDIT: From what I can see, out_info_type and the variable expl declared with it are never used, and the out_e variable is used instead. Is that right? I'm thinking I probably don't need to save out_e, out, and expl to the file since the former two are populated in build_outdoors(), called just after loading, and the latter seems to be unused.

 

EDIT2: Or, should I save out and out_e but not save outdoors? This is confusing...

[Chokboyz]

Originally Posted By: Celtic Minstrel

From what I can see, out_info_type and the variable expl declared with it are never used, and the out_e variable is used instead. Is that right? I'm thinking I probably don't need to save out_e, out, and expl to the file since the former two are populated in build_outdoors(), called just after loading, and the latter seems to be unused.

out_info_type is indeed unused.
The only expl used in the Windows code is a local boolean in the draw_map() function.
The out_e array is heavily used and even saved (it holds if an outdoor square has been explored or not), so it should be saved (i think) ...

Neither out , nor outdoors are saved in the original version of the code.

Hope it helps,
Chokboyz

[Celtic Minstrel]

Gotcha. Then I'll save out_e, and not save outdoors. But what about out? Wasn't there a complaint about terrain changes outdoors not surviving save-and-reload? Maybe I should save out.

 

 

Or maybe I should just leave it alone for now, since we may be altering the code to load the entire outdoors at once. I'll definitely save out_e, though.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Wasn't there a complaint about terrain changes outdoors not surviving save-and-reload

That's also an "in town" problem ... To solve that would requires to permanently change the terrain type in the town or outdoor struct (hence writing in the scenario file ...) That's obviously not a reasonable choice ...
Unless saving all towns/outdoors structs or rewriting the outdoor/town loading, fixing that seems pretty hard ... (moreover out only refers to the outdoor section you are in, if i'm not mistaken)
We could also work on a copy of the scenario ...

To answer one of your question a few posts above, my compiler (and c libraries) indeed support 64-bit integers, but i have to use %I64i instead of %lli. I've also adopted your changes from short to unsigned short.

One question, do we have a common bladbase.exs (e.g the one from this thread http://www.ironycentral.com/forum/ubbthreads.php?ubb=showflat&Number=164683#Post164683) ?
I didn't find one in Google Code ...

Originally Posted By: w-dueck

Here's a feature request:

Have an option to display animated terrain as animated (eg. go through all 4 frames when editing the map) in the scenario editor.

I've played a little with the editor code and implemented that (along with the display of the custom graphics).
The animation would play on the town map and in the edit terrain dialog.
Providing the code at this link http://www.freewebs.com/ishadnha/2009BoESESource.zip is Ishad Nha's latest, it works (and i will gladly upload the changes to the Google Repository if Ishad Nha wants so ...).

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Wasn't there a complaint about terrain changes outdoors not surviving save-and-reload

(moreover out only refers to the outdoor section you are in, if i'm not mistaken)

Close – it contains the terrain for all four currently loaded sections, combined into a single array.

Originally Posted By: Chokboyz

One question, do we have a common bladbase.exs (e.g the one from this thread http://www.ironycentral.com/forum/ubbthreads.php?ubb=showflat&Number=164683#Post164683) ?
I didn't find one in Google Code ...

Yes we do. In the Mac version it's called "Blades of Exile Base" instead of "bladbase.exs". Note that I'm not actually using the one from Drakefyre's link at this time.

If you want to fix bladbase errors in the Mac version of it, go right ahead. Or you could just fix them on the Windows side and post them here so I can fix them in the Mac version.

Originally Posted By: Chokboyz

Originally Posted By: w-dueck

Here's a feature request:

Have an option to display animated terrain as animated (eg. go through all 4 frames when editing the map) in the scenario editor.

I've played a little with the editor code and implemented that (along with the display of the custom graphics).
The animation would play on the town map and in the edit terrain dialog.
Providing the code at this link http://www.freewebs.com/ishadnha/2009BoESESource.zip is Ishad Nha's latest, it works (and i will gladly upload the changes to the Google Repository if Ishad Nha wants so ...).

I don't think I'll implement that right now. I'm more interested in getting saving and loading of new-format parties, getting the game to run from the Finder, and then moving on to improve terrain and tool palettes in the scenario editor... and animating the terrain in the editor seems trivial in comparison. Since you've done it, though, you could perhaps mention it in a comment on the issue report.

However, does this also mean you've incorporated some of my changes to the dialog engine? Or did you write the code for displaying custom graphics yourself?

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Wasn't there a complaint about terrain changes outdoors not surviving save-and-reload

That's also an "in town" problem ... To solve that would requires to permanently change the terrain type in the town or outdoor struct (hence writing in the scenario file ...)

Actually, no. At least, I don't think so. The terrain of the current town is stored in the save file.

...Which I should probably add to my new-format save function...