Jump to content

Code Discussion Thread


Celtic Minstrel

Recommended Posts

Quote:
Has the bug where conveyor belts stop working when reloading a saved game also been fixed?


I didn't encounter the bug, but will investigate ... (seems like a belt_present being reset when loading)


Quote:
Drop chances almost certainly are affected: there are documented cases of items with a 100% drop rate failing to drop.


Ok, on to-do list wink

Chokboyz
Link to comment
Share on other sites

  • Replies 990
  • Created
  • Last Reply

Top Posters In This Topic

Originally Posted By: Ishad Nha
Quick fix may be the only thing happening any time soon, going by Chokboyz post: #163872 - Apr 10, 2009 2:36 PM
If you're still on the topic of an external terrain types file, it's not really worth it. It would be quite simple to alter the struct to use a vector rather than an array, and then you just need to modify the code that uses the vector accordingly. Writing code to read from an external file which will be scrapped soon after doesn't seem worthwhile.

Originally Posted By: Ishad Nha
What might be useful is a display mode that shows the numbers of placed specials&. I was able to do this for the floor and terrain numbers in the BoA 3D Editor. All I had to do was adapt the height numbers.
Yes, I know. I don't think it would be useful as a display mode, but perhaps you could look into the code that tells the location of a clicked square and create an alternate branch that tells the list of specials on a clicked square.

Keep in mind that there may be more than one special on a given square!

Originally Posted By: Ishad Nha

I had a go at showing a "boat" icon to indicate where a scenario boat is, not so successful, you get a column of half a dozen boat icons.
...How are you getting half a dozen boats?

Originally Posted By: Chokboyz

Which leads to an aesthetic question : should swamps play no sound when walking on them (like Exile III and original BoE) or the squish (trash) sound (default sound on the BoE editor) ?
Well, the squish sound makes perfect sense to me, so I say leave it (at least as the default). If someone doesn't like it, they can change it for their scenario.
Link to comment
Share on other sites

I don't know how I am getting half a dozen boat icons for just the one boat, I am not a serious programmer, my programming is glorified Avernumscript level. I used the same code as for the Start icons, of course the boat coordinates are part of an array not scalars like the Start coordinates. Here is the code:

 

 

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

if ((scenario.scen_boats.which_town == cur_town) &&

(scenario.scen_boats.boat_loc.x == cen_x + q - 4) &&

(scenario.scen_boats.boat_loc.y == cen_y + q - 4)) {

from_rect = boat_button_from;

to_rect = tiny_to;

to_rect.left -= 14;

rect_draw_some_item(editor_mixed,from_rect,ter_draw_gworld,to_rect,0,0);

OffsetRect(&tiny_to,0,-7);

}

 

As for an external file, Chokboyz agrees with me that it is going to be a while before the formats are overhauled.

Link to comment
Share on other sites

But I haven't seen him agree that an external file is a good idea. And I certainly don't agree.

 

Though, one way of overhauling the scenario format would be to make it a package format. That basically means that the scenario is stored in several files in a folder that is disguised as a file. (Since this is a Windows game as well as a Mac game, the ideal way to disguise a folder as a file is to zip it with ... zlib, I think? ... and give it a .exs file extension.)

 

Anyway, your code...

 

Code:
for (i = 0; i < 30; i++)    if ((scenario.scen_boats[i].which_town == cur_town) &&      (scenario.scen_boats[i].boat_loc.x == cen_x + q - 4) &&      (scenario.scen_boats[i].boat_loc.y == cen_y + q - 4)) {        from_rect = boat_button_from;        to_rect = tiny_to;        to_rect.left -= 14;        rect_draw_some_item(editor_mixed,from_rect,ter_draw_gworld,to_rect,0,0);        OffsetRect(&tiny_to,0,-7);    }

So... you're iterating through the boat array, which presumably has 30 entries.

 

If the boat is set to appear in the current town, AND the boat is set to have coordinates (x + q - 4, y + q - 4), you draw something to the screen.

 

Question time.

 

What is q?

What's boat_button_from? What's tiny_to?

Why do you offset tiny_to by 7 each time a boat is found?

 

Next, I'm a little confused about why this is necessary. Doesn't the editor already show the location of boats? I get the impression that you're trying to display a little icon, like the Special icon, but my editor shows the full-size boat icon on a square with a boat.

Link to comment
Share on other sites

From plowing through page 5 of this thread... the blue text is stuff that is particularly important.

 

Originally Posted By: Ishad Nha

"(ADoS,CM)Fix the bug that prevents the use of the small Alien Beast graphic."

(This is a matter for the Scenario Editor, it has been done.)

Line 557 of Scenario.cpp reads: “147,148,149,150,151,152,152,154,155,159,”

The two 152s here refer to the normal Mind Crystal graphic, the line should thus read: “147,148,149,150,151,152,153,154,155,159,”. Alien Beast graphic will need to be manually changed to the proper one, currently it will still use the Pack Leader variety.

I have integrated this fix into the Mac version.

 

Originally Posted By: w-dueck
Hey, you know what would be sweet? If the editor could show the animations in animated terrain, not just the first frame. Also, it would be nice if the dialog for choosing a graphic included custom graphics, or maybe there was a 'Custom Graphic...' button.
Good idea, perhaps that can be looked into.

 

Originally Posted By: Ishad Nha

(ADoS)Fix the Add/Lose Sanctuary item ability. (Done)

(Milla)Fix the acid weapon doubles as living saving charm deal. (Done)

There was a problem with both Add/Lose Sanctuary and Add/Lose Martyr's Shield. That can be fixed by adding "case 78: case 80:" to line 496 of specials.cpp. Hex-editing allowed me to alter the exs file to create items with the desired properties so that I could verify that there was a problem and also verify that the problem had been fixed.

Now there is something about Acid Weapons..

(Milla)Fix the acid weaspon doubles as living saving charm deal.

Line 28 of PC.cpp, "i = hasAbilEquip(9);", should read "i = hasAbilEquip(48);".

The first of these changes has been integrated into the Mac version; however, I couldn't find the place to fix the Acid Weapon problem. Can you give more specific info?

 

Originally Posted By: Ishad Nha
(Milu)When "Custom Scenario" is clicked and then cancelled, the following message appears: "This scenario was created by BoE v2.0 or later and can't be run using this copy..."

This is a legitimate message if you don't have v2.0 or later. Why it is being called wrongly I don't know.

I suspect that this has been fixed in my version, though I can't be sure until I can get the program to actually recognize that there are some scenarios in the folder.

 

In startup.c, in the function handle_startup_press(Point the_point), case 4:

 

Right after "scen = pick_a_scen();", there are two if statements. Remove the second one – if(scen >= 0){ – and its accompanying closing brace, but leave the contents of the if statement (the sprintf call and the put_party_in_scen call). And dedent that section by one tab, of course. Then add "if(scen < 0) break" on a new line just after "scen = pick_a_scen();". Let me know if that works.

 

Originally Posted By: Ishad Nha

(Crynsos)Fix the Conceal Ability flag so that it actually conceals the ability.

This requires the creation of an isConcealed() item ability, currently there is a broken link between the BoE Scenario Editor's item editing screen and what the BoE game displays in its item information screen. I have amended this, concealed ability is now represented by "? ? ?". Infodlgs.cpp line 274 was amended.

Could you be a little more specific about what you did here?

 

Originally Posted By: Ishad Nha
"(Crynsos)Make it possible to make an item call a scenario special when used. (Implemented)"

Is this supported in the Windows Scenario Editor? As far as I can tell it is not.

Stareye implemented it in his version of the Mac editor; however I don't think that version is online.

 

Originally Posted By: Ishad Nha
Possible bugs:

Life saving items protect against:

Icy touch,

Experience draining touch,

Icy and draining touch

Slowing touch

 

Petrification touch causes disease

Yes, these are bugs that should be fixed.

 

Originally Posted By: Ishad Nha
(CM)Make the waterfalls work in town.

This has been done, I have yet to test it though. In Actions.cpp the waterfall exists in the outd_move_party function but not in the town_move_party counterpart.

I have implemented this as well, and tested it. I also made the game show exactly how much food you have lost when you go over the waterfall (the maximum seems to be 50 food, in which case it says "Many supplies lost.").

 

Near the end of outd_move_party, the following code:

Code:
else if (party.food > 1800)    party.food -= 50;else party.food = (party.food * 19) / 20;

was replaced with:

Code:
else if (party.food > 1800){    add_string_to_buf("  (Many supplies lost.)");    party.food -= 50;}else {    int n = party.food;    char s[25];    party.food = (party.food * 19) / 20;    sprintf(s,"  (%d supplies lost.)",n - party.food);    add_string_to_buf(s);}

 

In town_move_party, I added the following code (the first line and the last two lines were already present):

Code:
if (party.in_boat >= 0) {    // Waterfall!!!    while (scenario.ter_types[t_d.terrain[destination.x][destination.y + 1]].special == 15) {        add_string_to_buf("  Waterfall!                     ");        destination.y += 2;        c_town.p_loc.y += 2;        update_explored(party.p_loc);        initiate_redraw();        print_buf();        if ((cave_lore_present() > 0) && (get_ran(1,0,1) == 0))            add_string_to_buf("  (No supplies lost.)");        else if (party.food > 1800){            add_string_to_buf("  (Many supplies lost.)");            party.food -= 50;        }        else {            int n = party.food;            char s[25];            party.food = (party.food * 19) / 20;            sprintf(s,"  (%d supplies lost.)",n - party.food);            add_string_to_buf(s);        }        put_pc_screen();        play_sound(28);        pause(8);    }    party.boats[party.in_boat].boat_loc = c_town.p_loc;    party.boats[party.in_boat].which_town = c_town.town_num;}

 

 

While I was looking into this, I also made a small change with regards to the world's edge. In outd_move_party(), I simply changed:

Code:
if ((real_dest.x < 4) && (party.outdoor_corner.x <= 0)) {    ASB("You've reached the world's edge.");    return FALSE;}if (((real_dest.x > 92) && (party.outdoor_corner.x >= scenario.out_width - 2)) ||    ((real_dest.x > 44) && (party.outdoor_corner.x >= scenario.out_width - 1))) {    ASB("You've reached the world's edge.");    return FALSE;}

to check "(real_dest.x < 1 /*4*/)", "(real_dest.x > 95 /*92*/)", and "(real_dest.x > 47 /*44*/)" instead. I have yet to test the effects of this, though. Similarly with the real_dest.y checks.

 

The only problem is that you see cave wall beyond the edge of the section; that's fine when underground, but on the surface it would be better to show "high mountains" (the snowcapped mountain that cannot be flown over). Any ideas how to do this?

 

Originally Posted By: Chokboyz
(ADoS)Fix recording of dialogue nodes which result from a special node sequence. (fixed)

 

This was a simple typo in the INFODLGS.cpp file.

In function put_talk(), line 1059, replace the line :

party.talk_save[store_page_on].str2 - 2000 + 20,(char *) place_str);

by :

party.talk_save[store_page_on].str2 - 2000,(char *) place_str);

[...]

Unfortunately, I haven't been able to check if this bug was present in the Mac version of BoE. Should it be the case, the fix would be the same.

Done. smile
Originally Posted By: Chokboyz
Another bug fix post.

Note: when i say a bug is present in the mac version, i refer to the latest sources of OBoE on Khoth's site (but i may be wrong since i can't compile or even test mac version of the game ...)

 

  • (CommonGenius)Apparently the Defence skill rather than the Thrown Missiles skill is checked when firing missile weapons. (present on windows, present on mac)
  • "Sleeping Ray" trap wasn't working (present on windows, present on mac)
  • Petrification touch causes disease (Ishad Nha, others ?) (present on windows, present on mac)

I fixed these. I just made one change to the petrification touch, for consistency of indent and for proper grammar:

Code:
add_string_to_buf("  Petrifying touch!");
Originally Posted By: Chokboyz
Another quick bug-fix :

 

 

 

To do so, open file SPECIALS.cpp, find function townmode_spec() and insert the line

draw_map(modeless_dialogs[5],10);

after lines 2337, 2344 and 2349 (the lines saying *redraw = 1;, in case 171, 172 and 173).

Done.
Link to comment
Share on other sites

And from pages 6 and 7 of this thread... I didn't put important bits in blue this time...

Originally Posted By: Ishad Nha

I have fixed the monster 0 problem so that M1 thru M5 display monsters 1 thru 255. Monster editing is displaying monsters 0 thru 254, for no apparent reason I can't get 255 to display. It can however be accessed via the left, right buttons.

So they display correctly in the menu but incorrectly in the list of monsters? I'll look into that at some point...

 

Originally Posted By: Ishad Nha
I will bolster Delete Monster so that it gives type 0 and location 0,0 for all deleted monsters.
Good plan. Have you done that yet? I'll look into it at some point...

 

Originally Posted By: Ishad Nha
If currently editing an outdoor zone, Ctrl + J loads the previous zone while Ctrl + K loads the next zone.
This does not appear to consider the fact that the outdoors is a 2-dimensional array... not to mention that those are a horrible choice of shortcuts (Ctrl + arrow keys would be better).

 

Originally Posted By: Chokboyz

On the bug-fixing side,

Quote:
(Milu?)Fix Destroy Items node so that it works for rectangles as well as a single space.
has been fixed (incidentally, the same bug for the Move Items node when fixed).

 

In SPECIALS.cpp, in rect_spec(), the same index (i) is used to list the successives x positions and to list all the monsters in town, wrecking havoc in the Destroy Items (case 213) and Move Items (case 212) functions, as soon as there is more than one square to check.

Done.

 

Originally Posted By: Chokboyz
The bug where town couldn't be hid is fixed (assuming that won't break any compatibility with legacy scenarios ; why would would one try to hide a critical town knowing that the function doesn't work as intended ?).

 

The problem was that the value in 2a was checked instead of the value in 1b.

 

In SPECIALS.cpp, in town_spec, case 17 replace the line

else party.can_find_town[spec.ex1a] = (spec.ex2a == 0) ? 0 : 1;

by

else party.can_find_town[spec.ex1a] = (spec.ex1b == 0) ? 0 : 1;

Done. For some obscure reason the function is called general_spec in the Mac version.

 

 

Originally Posted By: Chokboyz
The Appear/Disappear on day X feature has been fixed ...

 

All the monsters are placed in a town the first time you enter it and won't be until the town is reinitialized (by the debug function or other). They are not placed again when you reenter the town to save time.

 

The first problem was that the part of the code checking if there's a monster to Appear/Disappear on day X in the town, was done during the first time placement of the monsters and subsequently ignored (in TOWN.cpp, line 197 of Ormus' build). The checks needs to be put outside of the if (monsters_loaded == FALSE) loop.

 

The second was that setting c_town.monst.dudes[ i ].active to 0 may work in the previous loop, but out of it, it must be set to 1.

[...]

The Disappear on day X part is the same (adapted) problem.

 

Sometimes Appears Here A/B/C should works, but I don't know if Appear/Disappear on Events does.

I have implemented this fix, but I have two questions. First, in the loop you altered just before of the if (monsters_loaded == FALSE) statement, why is case 6 commented out? Second, what (if anny) changes did you make to the switch statement inside the if (monsters_loaded == FALSE) conditional (just after "// Now, if necessary, fry the monster.")?

 

Originally Posted By: Chokboyz
Boolean day_reached(unsigned char which_day, unsigned char which_event)

// which_day is day event should happen

// which_event is the party.key_times value to cross reference with.

// if the key_time is reached before which_day, event won't happen

// if it's 8, event always happens

// which_day gets an extra 20 days to give party bonus time

{

short what_day = (short) (which_day) + 20;

 

if ((which_event != 8) && (party.key_times[which_event] < what_day))

return FALSE;

if (calc_day() >= what_day)

return TRUE;

else return FALSE;

 

}

That's odd, the Mac code's version of the function has two notable differences:

Code:
if (which_event > 10)    return FALSE;if ((which_event > 0) && (party.key_times[which_event] < which_day))    return FALSE;if (calc_day() >= which_day)    return TRUE;else return FALSE;

 

On an almost-related note, could someone possibly inform me what SDF(306,x) are used for?

 

Originally Posted By: Ishad Nha
Yes, scenario header flags are currently 10,20,30,40 (Mac) and 20,40,60,80 (Windows), so there is a lot of room for custom formats being recorded in the header.
In fact, we could probably unify it into a single format for Mac and Windows, if (as that implies) it is not already.

 

Originally Posted By: Chokboyz

Moreover, the editor was incorrectly preventing the designer to use the 10 major event (in fact, both -1 and 0 values don't do a thing, but the error text was saying to choose value between 0 and 9, -1 being do nothing). That has been corrected.

Fixed.

Originally Posted By: Chokboyz

Edit : and a nifty one to finish : a character without the nimble trait is actually better at disarming trap than a nimble one

Fixed.

 

Originally Posted By: Chokboyz

Last bug fixes (i will post the code when i return) :

 

  • Placed conveyor resulting from place/swap/transform terrain when no prior conveyor was present weren't functional. Fixed.

    Just needs to put a belt_present = true if the terrain is a conveyor when changing the terrain.

  • No Step on sound option was taken in account. Fixed

    In fact there were no code using the step_sound variable from the terrain struct. All the sound were hardcoded, so i wrote the missing code.

    Which leads to an aesthetic question : should swamps play no sound when walking on them (like Exile III and original BoE) or the squish (trash) sound (default sound on the BoE editor) ?

  • Affect Statistic Node probability check was wrong. It draws a number between 0 and 100 and if the number is strictly less than pic the stats were changed. Obviously even a 100 percent chance had 1 chance on 101 to fail. There may be others functions (dropping chances ?) affected by this glitch, will check it when i returns.

I await your code for these. smile

 

Finally, I have disabled the password check in the editor – it was a simple matter of commenting out an if block in load_scenario(). I'm not sure if the Windows editor has disabled this – you might want to check.

Link to comment
Share on other sites

Packages, whatever does the trick. You can just have a porting function that converts old exs formats with char terrain to new formats with short terrain.

 

What is "q"? I don't know, I only work here, I am iterating the offset?! "boat_button_from" is an icon which I drew up myself. No, the editor does not currently show where the boats are, open a scenario with boats and check their location in Scenario > Edit Boats. Then check that location in the relevant town, you won't see any boats.

 

"The first of these changes has been integrated into the Mac version; however, I couldn't find the place to fix the Acid Weapon problem. Can you give more specific info?" Starting at line 15 in PC.cpp in the unaltered version of Ormus's code:

void pc_record_type::kill(short type)

{

short i = 24;

bool dummy, no_save = false;

location item_loc;

if (type >= 10)

{

type -= 10;

no_save = true;

}

if (type != 4)

i = hasAbilEquip(9);

Now the "AbilEquip(9)" is the problem, that is item ability for Acidic Weapons, the game is looking for "AbilEquip(48)" which is the life-saving ability.

 

Conceal Ability, the alterations made to line 273 of Infodlgs.cpp are shown in bold:

if (s_i.ability > 0) {////

if (s_i.isConcealed() == false) {

GetIndString(desc_str,23,s_i.ability + 1);

cd_set_item_text(998,12,(char *) desc_str);

}

else {

cd_set_item_text(998,12,(char *) "? ? ?");

}

}

Edit:

Other alterations were needed elsewhere, for instance these two lines were added to Item.h:

#define ITEM_PROP_CONCEALED 32

bool isConcealed() const; /* properties of item are always concealed. */

This was added to the end of Item.cpp:

bool item_record_type::isConcealed() const

{

if (item_properties & ITEM_PROP_CONCEALED) return true;

else return false;

}

 

 

 

Link to comment
Share on other sites

Originally Posted By: Ishad Nha
No, the editor does not currently show where the boats are, open a scenario with boats and check their location in Scenario > Edit Boats. Then check that location in the relevant town, you won't see any boats.
In fact, I did exactly that, and I did see the boat.

It didn't appear immediately, though. Did you have the town open to that location when you set the boat location?


Thanks for the other info. It appears the acid/lifesaving was already fixed. The concealed ability thing I have implemented (with "???" instead of "? ? ?") and will test right away.

EDIT: On second thoughts, it seems it will be more complicated than it looks. I'll test tomorrow instead.

EDIT: Oh wait, you edited. I'll just go add that bit as well...
Link to comment
Share on other sites

Tomorrow I'll try to find the code in my version that displays the boat. If I forget, remind me.

 

 

Your fix hasn't worked yet; it's not helped by the fact that your code is quite different in that area. I think I've made the change necessary, but it didn't work when I tested it. Have you tested it?

 

I also discovered that the password is also checked in save_scenario, so I had to comment out another block of code there to disable password checking.

 

By the way, in (char *) "? ? ?" the (char *) is redundant.

Link to comment
Share on other sites

I am using the Ormus build and there is no Mac equivalent, the code could be very different indeed. I tested the Conceal Ability fix and it did produce the three question marks.

Edit:

Where should you put references to Conceal Ability? I don't know so I have just used the search all files option to look for occurences of "isIdent()", this is meant to give me clues as to where isConcealed() is meant to go, it seems that I have not made any obvious errors. Certainly the Conceal Ability function works in the inventory of a PC.

What code are you using and where can I download it?

Link to comment
Share on other sites

Quote:
Well, the squish sound makes perfect sense to me, so I say leave it (at least as the default). If someone doesn't like it, they can change it for their scenario.

The default is no sound when walking on swamps wink (it plays one big splash then nothing for a while)

Quote:
(Milu)When "Custom Scenario" is clicked and then cancelled, the following message appears: "This scenario was created by BoE v2.0 or later and can't be run using this copy..."
This is a legitimate message if you don't have v2.0 or later. Why it is being called wrongly I don't know.

Didn't encountered this bug ... Does it happen on Windows build ?

Quote:
I also made the game show exactly how much food you have lost when you go over the waterfall (the maximum seems to be 50 food, in which case it says "Many supplies lost.").

I prefer the original version though smile

Quote:
I just made one change to the petrification touch, for consistency of indent and for proper grammar

I will correct this when i will be back home.

Quote:
For some obscure reason the function is called general_spec in the Mac version.

Odd, even on the (windows) scenario editor the Hide Town Node is in town spec ...

Quote:
First, in the loop you altered just before of the if (monsters_loaded == FALSE) statement, why is case 6 commented out? Second, what (if anny) changes did you make to the switch statement inside the if (monsters_loaded == FALSE) conditional (just after "// Now, if necessary, fry the monster.")?

By memory, the case 6 wasn't commented in windows code (correspond to sometimes appears here C). I did some changes to the second switch statement, but i don't have access to my code right now smile

Oh and the
if (which_event > 10) // if major event specified is > to 10 returns because it isn't assigned in the code (the major event array is 100 long but only the 10 first are initialized at 30000)
return FALSE;
if ((which_event > 0) && (party.key_times[which_event] < which_day)) // if events to cross checks hasn't happens return
return FALSE;


It is an (undocumented ?) feature : events happens on day time_code if event "second field" has happened (0 always happens). The 8 check on Windows code is to be corrected.

Originally Posted By: Celtic Minstrel
On an almost-related note, could someone possibly inform me what SDF(306,x) are used for?


Originally Posted By: Celtic Minstrel
I don't really see the point of this...
Originally Posted By: Chokboyz
How is the game supposed to know what option is activated ? (preferences for example is array party.stuff_done[306])

wink
Quote:
Your fix hasn't worked yet; it's not helped by the fact that your code is quite different in that area. I think I've made the change necessary, but it didn't work when I tested it. Have you tested it?

The Conceal Ability fix has been tested and worked. The function IsIdent() or IsConcealed() or even ITEM.cpp doesn't exists on mac (i think this is ormus' C++ conversion process). So the fix must be adapted but works.

Hope it helps,
Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz

I prefer the original version though smile
Well, it's a change that's easily reverted.

Originally Posted By: Chokboyz

By memory, the case 6 wasn't commented in windows code (correspond to sometimes appears here C). I did some changes to the second switch statement, but i don't have access to my code right now smile
Okay, I'll wait.

Originally Posted By: Chokboyz
Oh and the
if (which_event > 10) // if major event specified is > to 10 returns because it isn't assigned in the code (the major event array is 100 long but only the 10 first are initialized at 30000)
return FALSE;
if ((which_event > 0) && (party.key_times[which_event] < which_day)) // if events to cross checks hasn't happens return
return FALSE;


It is an (undocumented ?) feature : events happens on day time_code if event "second field" has happened (0 always happens). The 8 check on Windows code is to be corrected.
I think that might be documented...

Originally Posted By: Chokboyz
How is the game supposed to know what option is activated ? (preferences for example is array party.stuff_done[306])
...Wait... SDF(306,x) is already used for several of the preferences. See the pick_preferences() function in your equivalent of dialogutils.c.

Originally Posted By: Chokboyz
The Conceal Ability fix has been tested and worked. The function IsIdent() or IsConcealed() or even ITEM.cpp doesn't exists on mac (i think this is ormus' C++ conversion process). So the fix must be adapted but works.
Yes, I adapted the fix but it didn't work, so I still need to investigate that.

Currently I'm going through the code to make use of your consts.h. I added a #define TRAP_FALSE_ALARM 6 to the file, since that's what trap 6 is officially supposed to be.
Link to comment
Share on other sites

Quote:
...Wait... SDF(306,x) is already used for several of the preferences. See the pick_preferences() function in your equivalent of dialogutils.c.

That was my point here confused

Quote:
Yes, I adapted the fix but it didn't work, so I still need to investigate that

Post your code if you need help, that one we will know wink

Quote:
Currently I'm going through the code to make use of your consts.h. I added a #define TRAP_FALSE_ALARM 6 to the file, since that's what trap 6 is officially supposed to be.

Nice to see that, I would have to do the same with my code smile
In the last (not posted) version of CONSTS.h, i set the trap 6 to TRAP_NO_TRAP_AFTER_ALL if i remember correctly (either we use one or another is not important, we need to use the same) and added the terrain specials. I will, of course, post it as soon as i get back.

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz
Quote:
...Wait... SDF(306,x) is already used for several of the preferences. See the pick_preferences() function in your equivalent of dialogutils.c.

That was my point here confused
...I thought you were useing that for compatibility fixes?

...Or was that SDF(309,x) or something? Sorry, it's probably just my memory at fault here. rolleyes

Anyway, constants for SDF(306,x) would be nice.

Originally Posted By: Chokboyz
Quote:
Yes, I adapted the fix but it didn't work, so I still need to investigate that

Post your code if you need help, that one we will know wink
I will if I get stumped when I return to that problem. I was fiddling with svn recently and commiting the changes so far, and I have to re-checkout because I did an import (or something). And I'm also getting a GUI because I made a zillion mistakes with the command line interface.

So basically that problem is on hold for a little longer.

Originally Posted By: Chokboyz

Nice to see that, I would have to do the same if my code smile
In the last (not posted) version of CONSTS.h, i set the trap 6 to TRAP_NO_TRAP_AFTER_ALL if i remember correctly (either we use one or another is not important, we need to use the same) and added the terrain specials. I will, of course, post it as soon as i get back.
I prefer TRAP_FALSE_ALARM for two reasons. One is that it's significantly shorter. The other reason is purely aesthetic, really – I like the sound of "false alarm" better than "no trap after all".

I've also added constants to consts.h for various rect variables that are used mainly in blxactions.c. And I filled out the overall_mode set of constants (several were missing).

...I should really get around to changing the names of the files, shouldn't I...
Link to comment
Share on other sites

The corrected list seems fine to me except i don't know what

Quote:
(Miramor)Fix up time passage as per this post and this post .
refers to ...

Speaking of which, are there any fixes done to the mac version that hasn't been applied to the windows one ?

 

Quote:
And I filled out the overall_mode set of constants (several were missing).

Nice, thanks for that wink I will merge the CONSTS.h if the changes are in the svn.

 

Quote:
Or was that SDF(309,x) or something?

That was 309 indeed smile Will post the preferences corresponding to [306][x] when i returns (i can already say that [306][3] is "show room description more than once", never called in the code and replaced by a "Show start picture and music" in my code smile )

 

And TRAP_FALSE_ALARM is adopted.

 

Chokboyz

Link to comment
Share on other sites

Originally Posted By: Chokboyz
The corrected list seems fine to me except i don't know what
Quote:
(Miramor)Fix up time passage as per this post and this post .
refers to ...
Speaking of which, are there any fixes done to the mac version that hasn't been applied to the windows one ?
I fixed all the links in the post (since the forum's current link format is totally alien to the previous one, they now go to PPP), and it seems that that bug wasn't fixed.

I don't know of any fixes applied to the Mac version that aren't in the Windows version. You could look back at my recent mammoth posts – there are a few things I did that weren't based on things you and Ishad did – but prior to that I have no idea.

What do you mean by "Show start picture and music"?
Link to comment
Share on other sites

Quote:
I don't know of any fixes applied to the Mac version that aren't in the Windows version. You could look back at my recent mammoth posts – there are a few things I did that weren't based on things you and Ishad did – but prior to that I have no idea.

Ok, i will. Thanks ...

Quote:
What do you mean by "Show start picture and music"?

If the option is activated, show the picture with the guy wielding a sword and looking to a tumulus-like structure and play the intro music. If not, just show the spiderweb logo and prompt to the main menu (a shortcut; the intro picture and music were desactivated by Ormus to quicken the loading and the test of the modificitions ...)

Quote:
(CM)When the party is split up, Affect PC special nodes should only affect the active PC.

That would be easy to fix, but wouldn't it break some legacy scenario compatibility ?

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz

Quote:
What do you mean by "Show start picture and music"?

If the option is activated, show the picture with the guy wielding a sword and looking to a tumulus-like structure and play the intro music. If not, just show the spiderweb logo and prompt to the main menu (a shortcut; the intro picture and music were desactivated by Ormus to quicken the loading and the test of the modificitions ...)
And you're using a Stuff Done flag for that? That seems like a bad idea, actually. The SDF preferences are (presumably) stored in the savegame file, rather than the preferences file, but that setting has nothing to do with the savegame; rather, it affects startup. So I'd recommend changing that preference to be stored in another global variable (like some of the other preferences) rather than an SDF.

I do think that setting is a good idea, though.

Originally Posted By: Chokboyz

Quote:
(CM)When the party is split up, Affect PC special nodes should only affect the active PC.

That would be easy to fix, but wouldn't it break some legacy scenario compatibility ?
I doubt it, but if you're worried you could probably incorporate some kind of switch into the node.

Currently, an Affect Party node will affect the whole party even if the party is split up (if I recall correctly). That makes no sense at all. Unless someone knows a scenario that relies on this entirely counterintuitive behaviour, I don't think it would be an issue.
Link to comment
Share on other sites

Quote:
The SDF preferences are (presumably) stored in the savegame file, rather than the preferences file, but that setting has nothing to do with the savegame; rather, it affects startup.

In the Windows build there is no preferences file (to the best of my knowledge). Bladmisc.dat has been replaced by blades.ini .
The SDF array is an 310x10, the 300 first being the one you use in the editor (0 to 299) and the last 10 being the "system" protected one (for example, preferences is the array SDF[306][x]). I don't know if this is the original behavior (but i think so) or an Ormus' change. Besides, in the Ormus' build an ini file is used to store the preferences/compatibilities (to not relies on the savefile. Note that all the 3100 values of the SDF array is stored in the savefile). Each time you load a game/begin a scenario/End a scenario, the preferences are reloaded from the ini file. The SDF [306][x] is used to store the value (to prevent reading the ini file over and over), but the ini file is where preferences are really located.
What i did was to transform an useless (never used anywhere) option (and index in the SDF array) into a potentially useful one.
Finally, note that the SDF array is initialized to 0 (every 3100 values) each time a new scenario is loaded.

Hope that clarifies the situation smile

Quote:
I doubt it, but if you're worried you could probably incorporate some kind of switch into the node.

Ok, temporary or not, that will be done wink

Quote:
Currently, an Affect Party node will affect the whole party even if the party is split up (if I recall correctly). That makes no sense at all. Unless someone knows a scenario that relies on this entirely counterintuitive behaviour, I don't think it would be an issue.

Upon my differents testing, i found that damage/health reduce/spell points reduce did only affect the lone pc. But give skills points affect the whole party. Not sure about the rest of the Affect PC nodes ...

Concerning the conveyor freezing upon loading, did anyone knows a scenario where this happens ? (i couldn't reproduce this with a scenario of mine) ...

Thanks,
Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz
Quote:
The SDF preferences are (presumably) stored in the savegame file, rather than the preferences file, but that setting has nothing to do with the savegame; rather, it affects startup.

In the Windows build there is no preferences file (to the best of my knowledge). Bladmisc.dat has been replaced by blades.ini .
The SDF array is an 310x10, the 300 first being the one you use in the editor (0 to 299) and the last 10 being the "system" protected one (for example, preferences is the array SDF[306][x]). I don't know if this is the original behavior (but i think so) or an Ormus' change. Besides, in the Ormus' build an ini file is used to store the preferences/compatibilities (to not relies on the savefile. Note that all the 3100 values of the SDF array is stored in the savefile). Each time you load a game/begin a scenario/End a scenario, the preferences are reloaded from the ini file. The SDF [306][x] is used to store the value (to prevent reading the ini file over and over), but the ini file is where preferences are really located.
What i did was to transform an useless (never used anywhere) option (and index in the SDF array) into a potentially useful one.
Finally, note that the SDF array is initialized to 0 (every 3100 values) each time a new scenario is loaded.
Hmm... some of the preferences make sense to store in the save file. "Don't save maps", "Show room descriptions more than once", "Make game easier", and "Fewer wandering monsters" make sense in the save file. (Of course, one of those doesn't even do anything.) It also makes some sense to store "No sounds" in the save file, but it also makes sense not to.

I think for the few that it makes sense for, a two-tier system could be used. If the SDF is 0, use the value from the preferences (in a global variable). Otherwise, use the value of the SDF (which could be 1 for true, 250 for false, or something).

Originally Posted By: Chokboyz

Upon my differents testing, i found that damage/health reduce/spell points reduce did only affect the lone pc. But give skills points affect the whole party. Not sure about the rest of the Affect PC nodes ...
I think it was experience or skill points where I encountered that.



I have implemented something like Ishad's "display the name of the current town". In order to do this, I used an additional string, and moved the terrain area up about 6 pixels so that it can be fully seen (changed #define TER_RECT_UL_Y 25 to be 19).

Click to reveal.. (The Code!)

In start_town_edit(), I replaced

set_lb(0,2,"Editing town",0);
set_lb(NLS - 2,1,"Click border to scroll view.",0);
set_lb(NLS - 1,11,"Back to Main Menu",0);


with

char message[50];
sprintf(message,"Editing Town %d",cur_town);
set_lb(0,2,message,0);
set_lb(NLS - 3,1,data_store->town_strs[0],0);

set_lb(NLS - 2,1,"(Click border to scroll view.)",0);
set_lb(NLS - 1,11,"Back to Main Menu",0);



In start_out_edit(), I replaced

set_lb(0,2,"Editing outdoors",0);
set_lb(NLS - 2,1,"Click border to scroll view.",0);
set_lb(NLS - 1,11,"Back to Main Menu",0);


with


char message[50];
sprintf(message,"Editing outdoors (%d,%d)",cur_out.x,cur_out.y);
set_lb(0,2,message,0);
set_lb(NLS - 3,1,data_store->out_strs[0],0);

set_lb(NLS - 2,1,"(Click border to scroll view.)",0);
set_lb(NLS - 1,11,"Back to Main Menu",0);


I shall commit that change now.
Link to comment
Share on other sites

Quote:
Hmm... some of the preferences make sense to store in the save file. "Don't save maps", "Show room descriptions more than once", "Make game easier", and "Fewer wandering monsters" make sense in the save file. (Of course, one of those doesn't even do anything.) It also makes some sense to store "No sounds" in the save file, but it also makes sense not to.

I wasn't really precise in my explications smile
Not all preferences are stored in the ini file : only the give intro hint (start-up tips), play sounds, first time launch ?, display mode and instant help are stored in the ini file, the others options are stored in the savegame file. The option I replace (intro picture/music at start-up) has been added to the ini file, the sdf being used only for storage of the value. So it seems to me we agree on this one wink

Should the need for a two-tier system arise (i.e people posting for this peculiar feature), i would gladly implement it, but for now i don't think it is needed (don't hesitate to say so if i'm wrong) ...

Quote:
I think it was experience or skill points where I encountered that.

Ok, i will check all the nodes to be sure ...

Quote:
I have implemented something like Ishad's "display the name of the current town". In order to do this, I used an additional string, and moved the terrain area up about 6 pixels so that it can be fully seen (changed #define TER_RECT_UL_Y 25 to be 19).

Isn't this a Scenario Editor change ? If so, i'm okay with all of this (Ishad Nha is the one maintening/improving it) wink

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz

Quote:
I have implemented something like Ishad's "display the name of the current town". In order to do this, I used an additional string, and moved the terrain area up about 6 pixels so that it can be fully seen (changed #define TER_RECT_UL_Y 25 to be 19).

Isn't this a Scenario Editor change ? If so, i'm okay with all of this (Ishad Nha is the one maintening/improving it) wink
Yes, that was a Scenario Editor change.
Link to comment
Share on other sites

Ok, so here is my code for the Appears/Disappears on day X/event Y fix (include before and after the monster_loaded check).

 

Click to reveal..
for (i = 0; i < 4; i++)

if (town_number == party.creature_save.which_town) {

c_town.monst = party.creature_save;

monsters_loaded = TRUE;

 

for (j = 0; j < T_M; j++) {

if (loc_off_act_area(c_town.monst.dudes[j].m_loc) == TRUE)

c_town.monst.dudes[j].active = 0;

if (c_town.monst.dudes[j].active == 2)

c_town.monst.dudes[j].active = 1;

c_town.monst.dudes[j].m_loc = t_d.creatures[j].start_loc;

c_town.monst.dudes[j].m_d.health = c_town.monst.dudes[j].m_d.m_health;

c_town.monst.dudes[j].m_d.mp = c_town.monst.dudes[j].m_d.max_mp;

c_town.monst.dudes[j].m_d.morale = c_town.monst.dudes[j].m_d.m_morale;

for (k = 0; k < 15; k++)

c_town.monst.dudes[j].m_d.status[k] = 0;

if (c_town.monst.dudes[j].summoned > 0)

c_town.monst.dudes[j].active = 0;

monst_target[j] = 6;

}

 

// Now, travelling NPCs might have arrived. Go through and put them in.

// These should have protected status (i.e. spec1 >= 200, spec1 <= 204)

for (j = 0; j < T_M; j++) {

switch (c_town.monst.dudes[j].monst_start.time_flag){

case 4: case 5 : case 6:

if ((((short) (party.age / 1000) % 3) + 4) != c_town.monst.dudes[j].monst_start.time_flag)

c_town.monst.dudes[j].active = 0;

else {

c_town.monst.dudes[j].active = 1;

c_town.monst.dudes[j].monst_start.spec_enc_code = 0;

// Now remove time flag so it doesn't get reappearing

c_town.monst.dudes[j].monst_start.time_flag = 0;

c_town.monst.dudes[j].m_loc = t_d.creatures[j].start_loc;

c_town.monst.dudes[j].m_d.health = c_town.monst.dudes[j].m_d.m_health;

}

break ;

 

// Now, appearing/disappearing monsters might have arrived/disappeared.

case 1:

if (day_reached(c_town.monst.dudes[j].monst_start.monster_time, c_town.monst.dudes[j].monst_start.time_code) == TRUE)

{

c_town.monst.dudes[j].active = 1;

c_town.monst.dudes[j].monst_start.time_flag=0; // Now remove time flag so it doesn't get reappearing

}

break;

case 2:

if (day_reached(c_town.monst.dudes[j].monst_start.monster_time, c_town.monst.dudes[j].monst_start.time_code) == TRUE)

{

c_town.monst.dudes[j].active = 0;

c_town.monst.dudes[j].monst_start.time_flag=0; // Now remove time flag so it doesn't get disappearing again

}

break;

case 7:

if (calc_day() >= party.key_times[c_town.monst.dudes[j].monst_start.time_code]){ //calc_day is used because of the "definition" of party.key_times

c_town.monst.dudes[j].active = 1;

c_town.monst.dudes[j].monst_start.time_flag=0; // Now remove time flag so it doesn't get reappearing

}

break;

 

case 8:

if (calc_day() >= party.key_times[c_town.monst.dudes[j].monst_start.time_code]){

c_town.monst.dudes[j].active = 0;

c_town.monst.dudes[j].monst_start.time_flag=0; // Now remove time flag so it doesn't get disappearing again

}

break;

case 0:

break;

default:

break;

}

}

 

for (j = 0; j < town_size[town_type]; j++)

for (k = 0; k < town_size[town_type]; k++) { // now load in saved setup,

// except that barrels and crates restore to orig locs

temp = setup_save.setup[j][k] & 231;

 

misc_i[j][k] = (misc_i[j][k] & 24) | temp;//setup_save.setup[j][k];

}

}

 

if (monsters_loaded == FALSE) {

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

if (t_d.creatures.number == 0) {

c_town.monst.dudes.active = 0;

c_town.monst.dudes.number = 0;

c_town.monst.dudes.monst_start.time_flag = 0;

c_town.monst.dudes.m_loc.x = 80;

}

else {

// First set up the values.

monst_target = 6;

c_town.monst.dudes.active = 1;

c_town.monst.dudes.number = t_d.creatures.number;

c_town.monst.dudes.attitude = t_d.creatures.start_attitude;

c_town.monst.dudes.m_loc = t_d.creatures.start_loc;

c_town.monst.dudes.mobile = t_d.creatures.mobile;

c_town.monst.dudes.m_d = return_monster_template(c_town.monst.dudes.number);

 

c_town.monst.dudes.summoned = 0;

c_town.monst.dudes.monst_start = t_d.creatures;

 

if (c_town.monst.dudes.monst_start.spec_enc_code > 0)

c_town.monst.dudes.active = 0;

 

// Now, if necessary, fry the monster.

switch (c_town.monst.dudes.monst_start.time_flag) {

case 1:

if (day_reached(c_town.monst.dudes.monst_start.monster_time,

c_town.monst.dudes.monst_start.time_code) == FALSE)

c_town.monst.dudes.active = 0;

break;

case 2:

if (day_reached(c_town.monst.dudes.monst_start.monster_time,

c_town.monst.dudes.monst_start.time_code) == TRUE)

c_town.monst.dudes.active = 0;

break;

case 3:

// unused

break;

case 4: case 5: case 6:

if ((((short) (party.age / 1000) % 3) + 4) != c_town.monst.dudes.monst_start.time_flag) {

c_town.monst.dudes.active = 0;

c_town.monst.dudes.monst_start.spec_enc_code = 50;

}

else {

c_town.monst.dudes.active = 1;

// Now remove time flag so it doesn't keep reappearing

c_town.monst.dudes.monst_start.time_flag = 0;

}

break;

case 7:

if (calc_day() < party.key_times[c_town.monst.dudes.monst_start.time_code])

c_town.monst.dudes.active = 0;

break;

 

case 8:

if (calc_day() >= party.key_times[c_town.monst.dudes.monst_start.time_code])

c_town.monst.dudes.active = 0;

break;

case 9:

if (c_town.town.town_chop_time > 0)

if (day_reached(c_town.town.town_chop_time,c_town.town.town_chop_key) == TRUE) {

c_town.monst.dudes.active += 10;

break;

}

c_town.monst.dudes.active = 0;

break;

case 0:

break;

default:

break; }

}

}

I fixed the day_reached function so that it is equivalent to the (correct) mac one.

 

Quote:
On an almost-related note, could someone possibly inform me what SDF(306,x) are used for?

[306]

[0] is Don't Save Maps

[1] is No Sounds

[2] is No graphics frills (lose special effects)

[3] is (by default) Show room description more than once

[4] is Never show instant help

[6] is the game speed

[7] is Make game easier (monsters much weaker)

[8] is Fewer wandering monsters

[9] is Turn off terrain animation

 

[296][0] is Turn off frills on shore (yup, it's an unprotected index ... you can change this option by having a set flag node setting the [296][0] to 0 (turn off) or whatever else (turns on) ... Should be fixed in my opinion )

 

[305]

[6] is No targeting line (use if getting crashes)

[5] is Fewer sounds (use if getting crashes)

 

display_mode is the variable storing the display mode.

 

Quote:
I await your code for these.

I will post it shortly, now i have access to the code.

 

Quote:
Finally, I have disabled the password check in the editor – it was a simple matter of commenting out an if block in load_scenario(). I'm not sure if the Windows editor has disabled this – you might want to check.

That was one of the very first thing Ormus did wink

 

Chokboyz

Link to comment
Share on other sites

If I may comment on the room descriptions switch, I kind of liked that feature in Exile III. Maybe instead of replacing it, we could make one of the Extra fields in the One-Time Display Message node determine whether the message is a room description, and then attach it to that switch?

Link to comment
Share on other sites

Originally Posted By: Chokboyz

[296][0] is Turn off frills on shore (yup, it's an unprotected index ... you can change this option by having a set flag node setting the [296][0] to 0 (turn off) or whatever else (turns on) ... Should be fixed in my opinion )
We could use SDF(306,5) for that? It wouldn't really break compatibilty since it's only a preference.

Originally Posted By: The Almighty Doer of Stuff
If I may comment on the room descriptions switch, I kind of liked that feature in Exile III. Maybe instead of replacing it, we could make one of the Extra fields in the One-Time Display Message node determine whether the message is a room description, and then attach it to that switch?
I like this idea. It shall be added to the suggestions in the first post.
Link to comment
Share on other sites

Quote:
We could use SDF(306,5) for that? It wouldn't really break compatibilty since it's only a preference.

I thought the same. Turn off frills on shore is now SDF[306][5] in my code.

Quote:
I like this idea. It shall be added to the suggestions in the first post.

Yup, we only need to agree on what Extra field to use wink

Chokboyz

Edit : seems like disarming wasn't the only thing that Nimble Fingers makes harder ... In fact, everytime a check is done involving Nimble Fingers, having the trait penalizes you ..
This is easily fixed (i choose to give bonus to Nimble ones rather than penalizing those without the trait) :
find the check if (adven[pc_num].traits[3] == FALSE) and replace FALSE by TRUE. Delete eventual previous fix : the adjustement to r1 must be substracting(i.e -= 6). In my version of the code, there were only 3 times this check was done : disarming trap, lockpicking and putting poison on weapon ...

Concerning the 100% problem, the monsters radiates field (COMBAT.cpp) abilities, the monster special summon abilities (must take a random between 0 and 99, not 100 to be accurate), the placement of fields (fire, ice, force ...) and the dropping chances (place_glands function) were affected by the glitch (to fix, get a random number between 1 and 100 and checks if less or equal).

On a lighter side, more cleaning must be done to the code : browsing it i found that having the PSD[4][0] set to 3 was making you a member of the anama (Exile III relic wink ) and then gives you a significant bonus (+25 to damage) when casting ravage spirit on a demon. If the right dialog was present (the sound plays though smile ), you could even be penalized if you spend xp in mage spell !!!
Click to reveal.. (proof)
if (which_skill == 9) { // mage spell skill
if (PSD[4][0] == 3) { //member of the anama ?
if (FCD(3049,1010) == 2) {//display dialog : Are you sure ? Anama won't be pleased, etc ...
FCD(3050,1010); //display dialog : Ok, you asked for it ...
PSD[4][0] = 1; party.spec_items[39] = 0; // no more a member, remove the Anama rings
for (i = 0; i < 6; i++) {adven.max_sp -= 6; adven.skills[10] -= 2; //remove 6 spell points and 2 priest spell skill
for (j = 30; j < 62; j++) {if (get_ran(1,0,2) < 2) adven.priest_spells[j] = 0;} //randomly remove high level priest spells
}
}


Finally, the Change/Swap/Transform rectangle function must be adapted to make working conveyor appearing. Here my proposition of such code (tested and worked) : (function rect_spec(), file SPECIALS.cpp ; notice the corrected get_ran wink )
Click to reveal..
case 214:
if (get_ran(1,1,100) <= spec.sd2){
set_terrain(l,spec.sd1);
if(scenario.ter_types[spec.sd1].special >= 16 && scenario.ter_types[spec.sd1].special <=19)
belt_present = TRUE;
}
break;
case 215:
if (coord_to_ter(i,j) == spec.sd1){
set_terrain(l,spec.sd2);
if(scenario.ter_types[spec.sd2].special >= 16 && scenario.ter_types[spec.sd2].special <=19)
belt_present = TRUE;
}
else if (coord_to_ter(i,j) == spec.sd2){
set_terrain(l,spec.sd1);
if(scenario.ter_types[spec.sd1].special >= 16 && scenario.ter_types[spec.sd1].special <=19)
belt_present = TRUE;
}
break;
case 216:
ter = coord_to_ter(i,j);
set_terrain(l,scenario.ter_types[ter].trans_to_what);
if(scenario.ter_types[scenario.ter_types[ter].trans_to_what].special >= 16 && scenario.ter_types[scenario.ter_types[ter].trans_to_what].special <=19) belt_present = TRUE;

Link to comment
Share on other sites

Originally Posted By: Chokboyz
Ok, so here is my code for the Appears/Disappears on day X/event Y fix (include before and after the monster_loaded check).
So, as far as I can tell, you didn't alter any code after the monster_loaded check...

Originally Posted By: Chokboyz

On a lighter side, more cleaning must be done to the code : browsing it i found that having the PSD[4][0] set to 3 was making you a member of the anama (Exile III relic wink ) and then gives you a significant bonus (+25 to damage) when casting ravage spirit on a demon. If the right dialog was present (the sound plays though smile ), you could even be penalized if you spend xp in mage spell !!!
Presumably you deleted that code? It doesn't appear to be in the Mac version, but I commented out the two lines in combat.c that give you a bonus if you're in the Anama.

Originally Posted By: Chokboyz
Finally, the Change/Swap/Transform rectangle function must be adapted to make working conveyor appearing. Here my proposition of such code (tested and worked) : (function rect_spec(), file SPECIALS.cpp ; notice the corrected get_ran wink )
What about cases 217 and 218? Do they need the belt_present check too? I'd guess they do...

Also, I changed all instances of get_ran in that switch statement to the corrected version. That's correct, right?

Originally Posted By: Chokboyz
Edit : seems like disarming wasn't the only thing that Nimble Fingers makes harder ... In fact, everytime a check is done involving Nimble Fingers, having the trait penalizes you ..
This is easily fixed (i choose to give bonus to Nimble ones rather than penalizing those without the trait) :
find the check if (adven[pc_num].traits[3] == FALSE) and replace FALSE by TRUE. Delete eventual previous fix : the adjustement to r1 must be substracting(i.e -= 6). In my version of the code, there were only 3 times this check was done : disarming trap, lockpicking and putting poison on weapon ...
Okay... but is that actually equivalent? What were the chances of disarming a trap before and after this fix, with and without the Nimble trait?

Originally Posted By: Chokboyz
Concerning the 100% problem, the monsters radiates field (COMBAT.cpp) abilities, the monster special summon abilities (must take a random between 0 and 99, not 100 to be accurate), the placement of fields (fire, ice, force ...) and the dropping chances (place_glands function) were affected by the glitch (to fix, get a random number between 1 and 100 and checks if less or equal).
Oh wait, this answers one of my questions above, doesn't it...?
Link to comment
Share on other sites

Quote:
So, as far as I can tell, you didn't alter any code after the monster_loaded check...

If i remember correctly i changed a > to >= (or < to <=) in one of the check so that the monster appears on day X and not day X+1. I may have flipped a 0 to 1 also, i don't remember exactly.

Quote:
Presumably you deleted that code? It doesn't appear to be in the Mac version, but I commented out the two lines in combat.c that give you a bonus if you're in the Anama

Commented it for nostalgia value grin The windows version seems to be a straight adaptation of the Exile III engine (not that is a bad thing of course), hence the numerous leftovers.

Quote:
What about cases 217 and 218? Do they need the belt_present check too? I'd guess they do...

Nop, locking/unlocking rectangle have nothing to do with conveyor as far as i can tell. wink

Quote:
Also, I changed all instances of get_ran in that switch statement to the corrected version. That's correct, right?

It is indeed wink

Quote:
Okay... but is that actually equivalent? What were the chances of disarming a trap before and after this fix, with and without the Nimble trait?

Not having the Nimble trait were giving you bonus (-6 when poisoning weapons, disarm traps, -8 when lockpicking), being Nimble then makes you more clumsy.

The two possible approachs are :
  • Ok, so he tried to penalized characters not having the nimble traits. Correct the - in + and that's ok (the "base" roll to succeed in lockpicking/disarm trap/put poison correctly, becomes de facto the one a nimble character needs to make; this makes the game harder)
  • Ok, so he put FALSE instead of TRUE; must be a leftover of an older function. Correct FALSE to TRUE and that's ok (the "base" roll to succeed in lockpicking/disarm trap/put poison correctly, becomes de facto the one a non-nimble character needs to make; this makes the game easier)

Why did I choose the second approach ? Mainly becauses it makes more sense to me to give bonus to someone nimble rather than penalizes a normal one and, more esoteric, if you tries to lockpick with thieving item equipped, 12 is substracted to r1. Add the -8 you would supposely get if nimble and that makes a nice, round 20 substracted to r1. I thought i would be the initial intention of Jeff when he wrote the function smile As always, this is open to discuss ...

Quote:
Oh wait, this answers one of my questions above, doesn't it...?

Well, yes wink

On a side note, i've reverted "Show room description more than once" to the original (useless) behavior so that, when we will agree on the sdf to use, it can be made into a working option. "Show startup picture/music" has been moved to the (unused) SDF[305][4].

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz
Quote:
So, as far as I can tell, you didn't alter any code after the monster_loaded check...

If i remember correctly i changed a > to >= (or < to <=) in one of the check so that the monster appears on day X and not day X+1. I may have flipped a 0 to 1 also, i don't remember exactly.
Gotcha. I'll look over it again to catch those changes.

Originally Posted By: Chokboyz
Quote:
What about cases 217 and 218? Do they need the belt_present check too? I'd guess they do...

Nop, locking/unlocking rectangle have nothing to do with conveyor as far as i can tell.
Oh, that's what those are? I probably could have looked that up somewhere...

Originally Posted By: Chokboyz
Quote:
Okay... but is that actually equivalent? What were the chances of disarming a trap before and after this fix, with and without the Nimble trait?

Absolutely not : not having the Nimble trait were giving you bonus (-6 when poisoning weapons, disarm traps, -8 when lockpicking), being Nimble then makes you more clumsy.

The two possible approachs are :
  • Ok, so he tried to penalized characters not having the nimble traits. Correct the - in + and that's ok (the "base" roll to succeed in lockpicking/disarm trap/put poison correctly, becomes de facto the one a nimble character needs to make; this makes the game harder)
  • Ok, so he put FALSE instead of TRUE; must be a leftover of an older function. Correct FALSE to TRUE and that's ok (the "base" roll to succeed in lockpicking/disarm trap/put poison correctly, becomes de facto the one a non-nimble character needs to make; this makes the game easier)

Why did I choose the second approach ? Mainly becauses it makes more sense to me to give bonus to someone nimble rather than penalizes a normal one and, more esoteric, if you tries to lockpick with thieving item equipped, 12 is substracted to r1. Add the -8 you would supposely get if nimble and that makes a nice, round 20 substracted to r1. I thought i would be the initial intention of Jeff when he wrote the function smile As always, this is open to discuss ...
Well, the approach you've chosen means that a non-nimble character has an unchanged chance, right? So I guess that's fine.

Originally Posted By: Chokboyz
On a side note, i've reverted "Show room description more than once" to the original (useless) behavior so that, when we will agree on the sdf to use, it can be made into a working option. "Show startup picture/music" has been moved to the (unused) SDF[305][4].
I should probably implement that. It would require delving into the DITL resource and attempting to add another LED, then adding code support for it if necessary (I would assume it is).

I suppose the change is simply that you don't call the plop_fancy_startup() function on startup?

And I should add the preferences in SDF(306,x) to consts.h, too... have you done so? If so, what did you call them?


I'm in the process of gathering the dialog code into a single place. Currently the code is mostly duplicated across the three programs, so merging the various versions of it will (hopefully) help when improving the code. I'm also splitting out common graphics functions as well as the sound code (which I think it mostly the same in all three programs).

By the way, I've been wondering – if you change the name of a file that's under SVN version control, will it be included in the next commit or would you have to remove it (under the old name) and re-add it?
Link to comment
Share on other sites

Quote:
Well, the approach you've chosen means that a non-nimble character has an unchanged chance, right? So I guess that's fine.

Actually no, both approach modifies the non-nimble chance to succeed (remember that the bonus was applied to the non-nimble characters). The approach I choose is to suppose that non-nimble characters are the norm and that nimble ones should have a bonus when trying to lockpick/poison/disarm. With theses changes, non-nimble characters would have (at same skill, items, ...) the same chance of succeeding than a nimble character has in the buggy version (on opposite, nimble characters would be more efficient, exactly as a non-nimble character in the old buggy version).

Quote:
I should probably implement that. It would require delving into the DITL resource and attempting to add another LED, then adding code support for it if necessary (I would assume it is).

That's an easy change. Once you've figured out how the dialog/ressources works (hint : study pick_preferences() and prefs_event_filter() in dialogutils.c of your code), all you have to do is, indeed, to tweak the plop_fancy_startup() function to check if the SDF[305][4] (or whatever you use) is set or not.

Quote:
I suppose the change is simply that you don't call the plop_fancy_startup() function on startup?

You can do that. I tweaked the function so that it only display briefly the Spiderweb Software logo (with no sound) then prompt the menu. It's all up to you wink

Quote:
And I should add the preferences in SDF(306,x) to consts.h, too... have you done so? If so, what did you call them?

No, i didn't, but i've added items specials skills, monsters skill, etc ... that the consts.h in the google code repository lacks. A copy of this consts.h (may not be up-to-date) can be found in one of the recent posts.

Quote:
I'm in the process of gathering the dialog code into a single place. Currently the code is mostly duplicated across the three programs, so merging the various versions of it will (hopefully) help when improving the code. I'm also splitting out common graphics functions as well as the sound code (which I think it mostly the same in all three programs).

It would be nice (and maybe a start to cross-platforming). Having take a look at the code, good luck with that though wink

Quote:
By the way, I've been wondering – if you change the name of a file that's under SVN version control, will it be included in the next commit or would you have to remove it (under the old name) and re-add it?

Unfortunately, i don't know, since i haven't tried it ...

Chokboyz

Edit : finally the three pieces of code that i had to post :

Quote:
Placed conveyor resulting from place/swap/transform terrain when no prior conveyor was present weren't functional. Fixed.

Function town_mode_spec() in SPECIALS.cpp
Click to reveal..
case 171:
set_terrain(l,spec.ex2a);
if(scenario.ter_types[spec.ex2a].special >= 16 && scenario.ter_types[spec.ex2a].special <=19)
belt_present = TRUE;

*redraw = TRUE;
draw_map(modeless_dialogs[5],10); // previous bug fixes : redraw map when terrain has changed
break;
case 172:
if (coord_to_ter(spec.ex1a,spec.ex1b) == spec.ex2a){
set_terrain(l,spec.ex2b);
if(scenario.ter_types[spec.ex2b].special >= 16 && scenario.ter_types[spec.ex2b].special <=19)
belt_present = TRUE;
}
else if (coord_to_ter(spec.ex1a,spec.ex1b) == spec.ex2b){
set_terrain(l,spec.ex2a);
if(scenario.ter_types[spec.ex2a].special >= 16 && scenario.ter_types[spec.ex2a].special <=19)
belt_present = TRUE;
}
*redraw = 1;
draw_map(modeless_dialogs[5],10); break;
case 173:
ter = coord_to_ter(spec.ex1a,spec.ex1b);
set_terrain(l,scenario.ter_types[ter].trans_to_what);
if(scenario.ter_types[scenario.ter_types[ter].trans_to_what].special >= 16 && scenario.ter_types[scenario.ter_types[ter].trans_to_what].special <=19)
belt_present = TRUE;

*redraw = 1;
draw_map(modeless_dialogs[5],10);
break;

This has previously (a few post above) been done on the change/swap/transform rectangle terrain. I forgot to apply the draw_map fix to the rectangle functions though. This has been fixed.

Quote:
Affect Statistic Node probability check was wrong. It draws a number between 0 and 100 and if the number is strictly less than pic the stats were changed. Obviously even a 100 percent chance had 1 chance on 101 to fail.

Find case 98 in the affect_spec() function (SPECIALS.cpp) and replace the get_ran(1,0,100) < spec.pic with get_ran(1,1,100) <= spec.pic. Similar fix has to be applied to monster radiate field, field placement (to CM : you already did this) and monster dropping (place_glands() ). The monster summon ability get_ran must be taken over 0 and 99 to be accurate (i.e 50% means not 50/101 chance).

Quote:
No Step on sound option was taken in account. Fixed

Replace the move_sound() function in EXLSOUND.cpp by something like that :
Click to reveal..
void move_sound(unsigned char ter,short step)
{
short pic,spec;

pic = scenario.ter_types[ter].picture;
spec = scenario.ter_types[ter].special;

if ((monsters_going == FALSE) && (overall_mode < 10) && (party.in_boat >= 0)) {// is on boat ?
if (spec == 21) //town entrance ?
return;
play_sound(48); //play boat sound
}
else if ((monsters_going == FALSE) && (overall_mode < 10) && (party.in_horse >= 0)) {//// is on horse ?
play_sound(85); //so play horse sound
}
if(scenario.ter_types[ter].special == 5) //if poisoned land don't play squish sound : BoE legacy behavior, can be removed safely
return;
// if(scenario.ter_types[ter].special == 6) //if diseased land do the same
// return;
else switch(scenario.ter_types[ter].step_sound){
case 0:
if (step % 2 == 0) //footsteps alternate sound
play_sound(49);
else play_sound(50);
break;
case 1:
play_sound(55); //squish
break;
case 2:
play_sound(47); //crunch
break;
case 3:
break; //silence : do nothing
default:
if (step % 2 == 0) //safety footsteps valve
play_sound(49);
else play_sound(50);
}
}


Note that, this code preserve the legacy BoE behavior (i.e no sound when walking on swamp, except the first big splash). Remove the poisoned land lines and the squish sound will be used.
Link to comment
Share on other sites

Originally Posted By: Chokboyz
Quote:
Well, the approach you've chosen means that a non-nimble character has an unchanged chance, right? So I guess that's fine.

Actually no, both approach modifies the non-nimble chance to succeed (remember that the bonus was applied to the non-nimble characters). The approach I choose is to suppose that non-nimble characters are the norm and that nimble ones should have a bonus when trying to lockpick/poison/disarm. With theses changes, non-nimble characters would have (at same skill, items, ...) the same chance of succeeding than a nimble character has in the buggy version (on opposite, nimble characters would be more efficient, exactly as a non-nimble character in the old buggy version).
It's almost as if the chances of the two are reversed then...

Originally Posted By: Chokboyz
Quote:
I should probably implement that. It would require delving into the DITL resource and attempting to add another LED, then adding code support for it if necessary (I would assume it is).

That's an easy change. Once you've figured out how the dialog/ressources works (hint : study pick_preferences() and prefs_event_filter() in dialogutils.c of your code), all you have to do is, indeed, to tweak the plop_fancy_startup() function to check if the SDF[305][4] (or whatever you use) is set or not.
The hard part is actually adding the LED without the ability to preview the dialog. The code changes shouldn't be too difficult. I probably can't do it until tonight at the earliest – I have an exam to write.

Originally Posted By: Chokboyz
Quote:
And I should add the preferences in SDF(306,x) to consts.h, too... have you done so? If so, what did you call them?

No, i didn't, but i've added items specials skills, monsters skill, etc ... that the consts.h in the google code repository lacks. A copy of this consts.h (may not be up-to-date) can be found in one of the recent posts.
In that case, I'll create my own set of constants for that purpose. If you could send me your current version of consts.h by PM or email, that would be nice.

Originally Posted By: Chokboyz
Quote:
I'm in the process of gathering the dialog code into a single place. Currently the code is mostly duplicated across the three programs, so merging the various versions of it will (hopefully) help when improving the code. I'm also splitting out common graphics functions as well as the sound code (which I think it mostly the same in all three programs).

It would be nice (and maybe a start to cross-platforming). Having take a look at the code, good luck with that though wink
I've gotten it to the point where the scenario editor compiles with this change, but I'm running up against a plethora of link errors that I'll have to fix somehow.

Originally Posted By: Chokboyz
Quote:
By the way, I've been wondering – if you change the name of a file that's under SVN version control, will it be included in the next commit or would you have to remove it (under the old name) and re-add it?

Unfortunately, i don't know, since i haven't tried it ...
I was hoping someone who knows about SVN would answer. If not, perhaps the SVN documentation will say something on the subject...

EDIT:
Originally Posted By: Chokboyz
Note that, this code preserve the legacy BoE behavior (i.e no sound when walking on swamp, except the first big splash). Remove the poisoned land lines and the squish sound will be used.
I will implement these changes at some point. For now, I'd like to mention that this could be another addition to the Preferences dialog, and also that it probably should be applied to disease land.
Link to comment
Share on other sites

Quote:
It's almost as if the chances of the two are reversed then...

It's exactly that smile The other approach would have let the nimble one with the same chance, but heavily (+12) penalized the non-nimble.

Quote:
The hard part is actually adding the LED without the ability to preview the dialog. The code changes shouldn't be too difficult

Inspire yourself from the already existing ressources files ... I can't help you unfortunately, i can't even open .rsrc crazy

Quote:
In that case, I'll create my own set of constants for that purpose. If you could send me your current version of consts.h by PM or email, that would be nice.

Done

A final bug fix (thanks Thuryl) :
Quote:
Conveyer Freezes upon loading fixed.


In load_file() in FILEIO.cpp, find the lines
if (town_restore == FALSE) { and add the lines :
Click to reveal..
if (town_restore == FALSE) {
center = party.p_loc;
load_area_graphics();
}
else {
load_town(c_town.town_num,2,-1,NULL);
load_town(c_town.town_num,1,-1,NULL);
for (i = 0; i < T_M; i++)
{monster_targs.x = 0; monster_targs.y = 0;}

town_type = scenario.town_size[c_town.town_num];
// Set up field booleans
for (j = 0; j < town_size[town_type]; j++)
for (k = 0; k < town_size[town_type]; k++) {
// Set up field booleans
if (is_web(j,k) == TRUE) web = TRUE;
if (is_crate(j,k) == TRUE) crate = TRUE;
if (is_barrel(j,k) == TRUE) barrel = TRUE;
if (is_fire_barrier(j,k) == TRUE) fire_barrier = TRUE;
if (is_force_barrier(j,k) == TRUE) force_barrier = TRUE;
if (is_quickfire(j,k) == TRUE) quickfire = TRUE;
if ((scenario.ter_types[t_d.terrain[j][k]].special >= 16) &&
(scenario.ter_types[t_d.terrain[j][k]].special <= 19))
belt_present = TRUE;
}
force_wall = TRUE;fire_wall = TRUE;antimagic = TRUE;scloud = TRUE;ice_wall = TRUE;blade_wall = TRUE;
sleep_field = TRUE;
center = c_town.p_loc;
load_area_graphics();
}

so that each time the game is loaded while in town, it checks if there is a conveyor and acts accordingly.

Chokboyz
Link to comment
Share on other sites

Thanks. I'll grab that soonish.

Originally Posted By: Chokboyz

Quote:
The hard part is actually adding the LED without the ability to preview the dialog. The code changes shouldn't be too difficult

Inspire yourself from the already existing ressources files ... I can't help you unfortunately, i can't even open .rsrc crazy

In truth I don't think it will be especially difficult; the hardest part will be choosing the framing rect. I'll probably have to base it on the framing rect of previous elements.

 

...You know, perhaps it would be a good idea to decompile the resource files into .r (Rez) files so that non-Mac-users can at least see what's in them (pictorial data excluded)...

Link to comment
Share on other sites

I'm not sure what you meant about lock/unlock terrain not involving conveyor belts, but I think it does, unless I misunderstood what you meant. When you lock or unlock a terrain, it changes it to a different terrain. For instance, I could have a motionless conveyor belt terrain which has the terrain type "Lockable terrain", "Unlockable terrain", or "Unlockable/bashable". When a lever is pulled, it calls a Lock (or Unlock, depending on which terrain type I chose for it) Terrain (or Lock/Unlock Rectangle Terrain), and change the motionless conveyor belt terrain into moving conveyor belts. The program should check for this happening, as well as the Crumbling Terrain type (Move Mountains/Shatter spells) and Can Be Used type.

Link to comment
Share on other sites

Indeed, it does change (having the help file on hand is essential when using this editor rolleyes ). I think i should check the "Change when step on" status too wink

 

Oh, by the way, your "Show room description more than once" option is back. We only needs to agree on what special to check and hop, it's implemented.

 

Chokboyz

Link to comment
Share on other sites

Originally Posted By: The Almighty Doer of Stuff
I'm not sure what you meant about lock/unlock terrain not involving conveyor belts, but I think it does, unless I misunderstood what you meant. When you lock or unlock a terrain, it changes it to a different terrain. For instance, I could have a motionless conveyor belt terrain which has the terrain type "Lockable terrain", "Unlockable terrain", or "Unlockable/bashable". When a lever is pulled, it calls a Lock (or Unlock, depending on which terrain type I chose for it) Terrain (or Lock/Unlock Rectangle Terrain), and change the motionless conveyor belt terrain into moving conveyor belts. The program should check for this happening, as well as the Crumbling Terrain type (Move Mountains/Shatter spells) and Can Be Used type.
While this is technically possible, the "Transform to" field in conjunction with "Swap Terrain" nodes is probably a better way of implementing this type of thing.

Still, I guess it's best to cover all bases.


EDIT: In fact, considering the way conveyor belts work, it would be pretty easy to add a special node type that disables them without changing any terrain. All it would have to do is set "belts_present = false", and possibly set a flag so that the change will be retained when loading a savegame.
Link to comment
Share on other sites

That's true, the Extra values are unused for conveyor belts. I could see all sorts of ways we could manipulate conveyor belts with those fields when the scenario format is rewritten. We still need to fix the already existing terrain types, however.

 

Also, perhaps we could make them work outdoors, while we're making waterfalls work indoors. If we do that, we need to make sure to fix the check for hidden/revealed towns to notice the terrain change as well.

Link to comment
Share on other sites

Quote:
We still need to fix the already existing terrain types, however.

Don't worry, half of it is already done (lock/unlock rectangle).

Quote:
Also, perhaps we could make them work outdoors, while we're making waterfalls work indoors.

Why not ... Besides, that would be pretty easy ...

Quote:
If we do that, we need to make sure to fix the check for hidden/revealed towns to notice the terrain change as well.

It seems I don't understand what you mean ... You want to hide a town under a potential conveyor belt terrain ? grin

Chokboyz
Link to comment
Share on other sites

Originally Posted By: The Almighty Doer of Stuff
That's true, the Extra values are unused for conveyor belts. I could see all sorts of ways we could manipulate conveyor belts with those fields when the scenario format is rewritten. We still need to fix the already existing terrain types, however.
One way to use one of those fields would be to specify the direction to push in, freeing up space for additional terrain abilities. On the other hand, that's probably not really necessary.

Originally Posted By: The Almighty Doer of Stuff
Also, perhaps we could make them work outdoors, while we're making waterfalls work indoors. If we do that, we need to make sure to fix the check for hidden/revealed towns to notice the terrain change as well.
Wow, why didn't I think of that? I was even in the process of creating a scenario that uses conveyor belts outdoors... though it has been cancelled now.
Link to comment
Share on other sites

Originally Posted By: Chokboyz
It seems I don't understand what you mean ... You want to hide a town under a potential conveyor belt terrain ? grin

Yes. Just because you and I can't think of any intelligent use for such a function doesn't mean someone else won't, and I see no reason to unnecessarily limit someone's creativity. wink
Link to comment
Share on other sites

Quote:
Yes. Just because you and I can't think of any intelligent use for such a function doesn't mean someone else won't, and I see no reason to unnecessarily limit someone's creativity.

And i see no reason why i wouldn't have implemented it ... That was a true question you know wink
A use ? Put the party on a giant conveyor outdoor belt (let say they are caught in the ford of a river, so water graphics), if they have done the right thing they will ends up on a dam/whatever_structure_you_want. If they have not, the town remains hidden and they continue their way to the sea and their doom. And i'm sure people would find way better use for this wink

Chokboyz

Edit: Fixing is finished : now, if you change the terrain (using it, stepping on it, lock/unlocking (bash/lockpick/magic/node), crumbling, whatever) while in town and the terrain is a conveyor belt, it springs to life, eager to push you into a wall (yes, that as not yet been corrected). Outdoors version is on the to-do list.

Link to comment
Share on other sites

Oh! One thing that could be done with the Extra values is allowing custom messages when being pushed or prevented by a conveyor belt. Right now, when you step on a conveyor belt and it pushes you, you get a small message in the text area that says "You get pushed." and if you attempt to move in the opposite direction of the conveyor belt, it says "The moving floor prevents you." Perhaps one Extra value could correspond to a scenario message that defines the two messages, separated by a | (the same character that creates line breaks in signs).

 

For instance, let's say you select scenario message 10 to be the conveyor belt's messages. Message 10 says "You float down the river.|The water's too fast to move upstream!" Now, when the party moves along the "belt", it says "You float down the river." and when they try to move against the direction of the "belt", it says "The water's too fast to move upstream!"

 

EDIT: Also, on the editor end, when editing a sign, the dialog box incorrectly says that " creates a line break, rather than |. This has caused several scenario authors to use underscores instead of quotes, which frankly is rather silly.

Link to comment
Share on other sites

That would be a neat addition indeed ... put on the to-do list wink

The actual phase being bug-fixing,(time passage investigated right now), those features may not be in for a while though smile

 

Thanks for your comments/ideas,

Chokboyz

 

Edit :

Quote:
Also, on the editor end, when editing a sign, the dialog box incorrectly says that " creates a line break, rather than |. This has caused several scenario authors to use underscores instead of quotes, which frankly is rather silly.

Corrected in my version confused

 

Oops, i didn't gave the last version of the step sound code. The last one was buggy (while on boat and horse you would hear footsteps), here is the corrected version :

 

Click to reveal..
void move_sound(unsigned char ter,short step)

{

short pic,spec;

 

pic = scenario.ter_types[ter].picture;

spec = scenario.ter_types[ter].special;

 

if ((monsters_going == FALSE) && (overall_mode < 10) && (party.in_boat >= 0)) {

if (spec == 21)

return;

play_sound(48);

}

else if ((monsters_going == FALSE) && (overall_mode < 10) && (party.in_horse >= 0)) {////

play_sound(85);

}

else if(scenario.ter_types[ter].special == 5) //if poisoned land don't play squish sound : BoE legacy behavior, can be removed safely

return;

// else if(scenario.ter_types[ter].special == 6) //if diseased land do the same

// return;

else switch(scenario.ter_types[ter].step_sound){

case 0:

if (step % 2 == 0) //footsteps alternate sound

play_sound(49);

else play_sound(50);

break;

case 1:

play_sound(55); //squish

break;

case 2:

play_sound(47); //crunch

break;

case 3:

break; //silence : do nothing

default:

if (step % 2 == 0) //safety footsteps valve

play_sound(49);

else play_sound(50);

}

}

Link to comment
Share on other sites

Originally Posted By: Chokboyz
Corrected in my version confused


Oh, okay. I'm actually still using the original, purchaseable BoE and scenario editor, out of fear of corruption and bugs introduced in the last version of Ormus's BoE that I used. I'm waiting for a stable version that's as bug-free as possible before I upgrade. Sorry.
Link to comment
Share on other sites

Quote:
Oh, okay. I'm actually still using the original, purchaseable BoE and scenario editor, out of fear of corruption and bugs introduced in the last version of Ormus's BoE that I used. I'm waiting for a stable version that's as bug-free as possible before I upgrade. Sorry.

No problem, i can understand that ... and we're trying to provide this stable, bug-free version wink

Concerning the timers problems, i don't know what i'm supposed to look after ... (the time unit for me is the town step move, here after shortened to move)
Taking a step (with or without horses) in town counts as 1 move, taking a step outside counts as 10 moves (5 while on horses), waiting 40 moves on town actually waits 80 moves and resting outside counts as 1700 moves.
Outside, the moves are taken modulo 10 (modulo 5 while on horse), so if the party_age is 147 when exiting a town, it is rounded to 150. I doubt that causes bugs though.
Resting (Inn) is 700 moves.
A day is 3700 moves.
When trying scenario event timers, everything worked fine (dialog displayed every 150 moves) except when resting. In fact,resting bypass (if rest successful) the 1200 last resting moves (that may get timers slightly off : if my party age is 1200 and i rest, three dialogs appears (150*3 = 450 ; 1700-450=1250) but the fourth one will appears a little (100 moves) after awaking (2850<1200+1700=2900< 3000)).
Is that the problem encountered ?
On a side note, a day passed outside is the same as a day passed in town (3700 moves).

Chokboyz

Edit : sleeping in Inn and Have a Rest Node also bypass the event check ... So that must be the source of the problem (whatever it is) ...
Link to comment
Share on other sites

Originally Posted By: Chokboyz

Edit : finally the three pieces of code that i had to post :

Quote:
Placed conveyor resulting from place/swap/transform terrain when no prior conveyor was present weren't functional. Fixed.

Function town_mode_spec() in SPECIALS.cpp
[...]
This has previously (a few post above) been done on the change/swap/transform rectangle terrain. I forgot to apply the draw_map fix to the rectangle functions though. This has been fixed.
Both these fixes applied. Oddly, the draw_map calls had already been added. I also added the "*redraw = true" line and the draw_map call to the rect_spec function in the cases that call set_terrain.

Originally Posted By: Chokboyz
Quote:
Affect Statistic Node probability check was wrong. It draws a number between 0 and 100 and if the number is strictly less than pic the stats were changed. Obviously even a 100 percent chance had 1 chance on 101 to fail.

Find case 98 in the affect_spec() function (SPECIALS.cpp) and replace the get_ran(1,0,100) < spec.pic with get_ran(1,1,100) <= spec.pic. Similar fix has to be applied to monster radiate field, field placement (to CM : you already did this) and monster dropping (place_glands() ). The monster summon ability get_ran must be taken over 0 and 99 to be accurate (i.e 50% means not 50/101 chance).
Also done.

Originally Posted By: Chokboyz
Ok, so here is my code for the Appears/Disappears on day X/event Y fix (include before and after the monster_loaded check).
I went over this again, and the only change I could see is that one > changed to >=, which I have also done.

Originally Posted By: Chokboyz
Quote:
No Step on sound option was taken in account. Fixed

Replace the move_sound() function in EXLSOUND.cpp by something like that :
[...]
Note that, this code preserve the legacy BoE behavior (i.e no sound when walking on swamp, except the first big splash). Remove the poisoned land lines and the squish sound will be used.
I'm not convinced it will play a "first big splash". I took your code as a base and made my own version:
Click to reveal.. (move_sound())

Code:
void move_sound(unsigned char ter,short step){    static bool on_swamp = false;    short pic,spec;    pic = scenario.ter_types[ter].picture;    spec = scenario.ter_types[ter].special;    //if poisoned land don't play squish sound : BoE legacy behavior, can be removed safely    if(scenario.ter_types[ter].special == 5){        if(on_swamp)return;        on_swamp = true;    }    else if(scenario.ter_types[ter].special == 6){ //if diseased land do the same        if(on_swamp) return;        on_swamp = true;    }else on_swamp = false;    if ((monsters_going == FALSE) && (overall_mode < 10) && (party.in_boat >= 0)) {// is on boat ?        if (spec == 21) //town entrance ?            return;        play_sound(48); //play boat sound    }    else if ((monsters_going == FALSE) && (overall_mode < 10) && (party.in_horse >= 0)) {//// is on horse ?        play_sound(85); //so play horse sound    }    else switch(scenario.ter_types[ter].step_sound){        case 1:            play_sound(55); //squish            break;        case 2:            play_sound(47); //crunch            break;        case 3:            break; //silence : do nothing        default: //safety footsteps valve            if (step % 2 == 0) //footsteps alternate sound                play_sound(49);            else play_sound(50);    }}
So, if you're moving from a poison square to a poison or disease square, or from a disease square to a poison or disease square, the sound will be ignored. However, if you move onto a poison or disease square from some other type of square, the sound will be played. I'm pretty sure this code will do that. (In case you're not aware, a static local variable retains its value over multiple function calls. It's essentially a global variable that can only be accessed from one function.)

I also removed case 0 since it was duplicate code.


Originally Posted By: Chokboyz
A final bug fix (thanks Thuryl) :
Quote:
Conveyer Freezes upon loading fixed.


In load_file() in FILEIO.cpp, find the lines
if (town_restore == FALSE) { and add the lines :
[...]
so that each time the game is loaded while in town, it checks if there is a conveyor and acts accordingly.

Chokboyz
Well, I did that, but there was something odd there. This is what that chunk of the code now looks like:
Click to reveal..
Code:
// Set up field booleansfor (j = 0; j < town_size[town_type]; j++)    for (k = 0; k < town_size[town_type]; k++) {        // Set up field booleans        if (is_web(j,k) == TRUE)            web = TRUE;        if (is_crate(j,k) == TRUE)            crate = TRUE;        if (is_barrel(j,k) == TRUE)            barrel = TRUE;        if (is_fire_barrier(j,k) == TRUE)            fire_barrier = TRUE;        if (is_force_barrier(j,k) == TRUE)            force_barrier = TRUE;        if (is_quickfire(j,k) == TRUE)            quickfire = TRUE;        if ((scenario.ter_types[t_d.terrain[j][k]].special >= 16) &&            (scenario.ter_types[t_d.terrain[j][k]].special <= 19))            belt_present = TRUE;    }    if ((scenario.ter_types[t_d.terrain[j][k]].special >= 16) &&    (scenario.ter_types[t_d.terrain[j][k]].special <= 19))        belt_present = TRUE;force_wall = TRUE;fire_wall = TRUE;antimagic = TRUE;scloud = TRUE;ice_wall = TRUE;blade_wall = TRUE;sleep_field = TRUE;center = c_town.p_loc;load_area_graphics();
I'm guessing the second check for conveyors is completely useless. And are the other field = true lines supposed to be outside the loop?


Originally Posted By: Chokboyz

Edit: Fixing is finished : now, if you change the terrain (using it, stepping on it, lock/unlocking (bash/lockpick/magic/node), crumbling, whatever) while in town and the terrain is a conveyor belt, it springs to life, eager to push you into a wall (yes, that as not yet been corrected).
Hmm... so, I need to still add that check for change when used, change when stepped on, and crumbling...

Originally Posted By: The Almighty Doer of Stuff
Oh! One thing that could be done with the Extra values is allowing custom messages when being pushed or prevented by a conveyor belt. Right now, when you step on a conveyor belt and it pushes you, you get a small message in the text area that says "You get pushed." and if you attempt to move in the opposite direction of the conveyor belt, it says "The moving floor prevents you." Perhaps one Extra value could correspond to a scenario message that defines the two messages, separated by a | (the same character that creates line breaks in signs).
Why use one scenario string when you can use two? We plan to alter it to give a practically unlimited number of ... well, pretty much anything ... so unless you need the other Extra field for something else, we might as well use two separate strings.

By the way, if this suggestion doesn't appear in the first post soon, remind me to add it.

Originally Posted By: The Almighty Doer of Stuff
EDIT: Also, on the editor end, when editing a sign, the dialog box incorrectly says that " creates a line break, rather than |. This has caused several scenario authors to use underscores instead of quotes, which frankly is rather silly.
I don't think that error ever existed in the Mac version.

Originally Posted By: Chokboyz

Oops, i didn't gave the last version of the step sound code. The last one was buggy (while on boat and horse you would hear footsteps), here is the corrected version :
I still think my version, above, is better. Incidentally, it should fix the bug you mentioned.

Originally Posted By: Chokboyz

Quote:
On an almost-related note, could someone possibly inform me what SDF(306,x) are used for?

[306]
[0] is Don't Save Maps
[1] is No Sounds
[2] is No graphics frills (lose special effects)
[3] is (by default) Show room description more than once
[4] is Never show instant help
[6] is the game speed
[7] is Make game easier (monsters much weaker)
[8] is Fewer wandering monsters
[9] is Turn off terrain animation

[296][0] is Turn off frills on shore (yup, it's an unprotected index ... you can change this option by having a set flag node setting the [296][0] to 0 (turn off) or whatever else (turns on) ... Should be fixed in my opinion )

[305]
[6] is No targeting line (use if getting crashes)
[5] is Fewer sounds (use if getting crashes)
I have added constants to consts.h for these. Below are the additions:
Code:
#define SDF_PARTY_SPLIT_TOWN    304][3 // for future use, hopefully#define SDF_SKIP_STARTUP        305][4#define SDF_LESS_SOUND          305][5#define SDF_NO_TARGET_LINE      305][6#define SFD_NO_MAPS             306][0#define SDF_NO_SOUNDS           306][1#define SDF_NO_FRILLS           306][2#define SDF_ROOM_DESCS_AGAIN    306][3#define SDF_NO_INSTANT_HELP     306][4 // boolean#define SDF_NO_SHORE_FRILLS     306][5#define SDF_GAME_SPEED          306][6#define SDF_EASY_MODE           306][7#define SDF_LESS_WANDER_ENC     306][8#define SDF_NO_TER_ANIM         306][9
I also shortened "ITEM_PROTECTION_FROM_PETRIFY" to "ITEM_PROTECT_FROM_PETRIFY". I also did the same with the other ones that contained "PROTECTION_FROM".

I was unsatisfied with the somewhat misleading NonSpell Use constant names, so I changed them as follows:
Code:
#define ITEM_POISON_WEAPON              70 //put poison on weapon#define ITEM_BLESS_CURSE                71#define ITEM_AFFECT_POISON              72#define ITEM_HASTE_SLOW                 73#define ITEM_AFFECT_INVULN              74#define ITEM_AFFECT_MAGIC_RES           75#define ITEM_AFFECT_WEB                 76#define ITEM_AFFECT_DISEASE             77#define ITEM_AFFECT_SANCTUARY           78#define ITEM_AFFECT_DUMBFOUND           79#define ITEM_AFFECT_MARTYRS_SHIELD      80#define ITEM_AFFECT_SLEEP               81#define ITEM_AFFECT_PARALYSIS           82#define ITEM_AFFECT_ACID                83#define ITEM_BLISS                      84#define ITEM_AFFECT_EXPERIENCE          85#define ITEM_AFFECT_SKILL_POINTS        86#define ITEM_AFFECT_HEALTH              87#define ITEM_AFFECT_SPELL_POINTS        88#define ITEM_DOOM                       89#define ITEM_LIGHT                      90#define ITEM_STEALTH                    91#define ITEM_FIREWALK                   92#define ITEM_FLYING                     93#define ITEM_MAJOR_HEALING              94
As for the MONSTER_TYPE_ constants, I kind of like the idea of using MONSTER_RACE_ instead. Any objections?

Oh, and drop the _CREATURE from MAGICAL_CREATURE. smile

One more thing. I notice you've commented out some of the constants I added? Not that it really matters, but may I ask why?
Link to comment
Share on other sites

It's not necessarily the monster's race, however. Take Humanoid for example. Sliths, Nephils, and Troglodytes are all Humanoid type, but they are clearly not the same race.

 

Besides, that's what the scenario editor calls it and there's no point that I can see introducing possible confusion. Same goes for MAGICAL_CREATURE.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...