Code Discussion Thread

[Chokboyz]

Originally Posted By: Celtic Minstrel

Perhaps. Do you have any better suggestions?

I've put that on the Known Scenario Bugs list. We can, of course, implement your check for extra safety

Originally Posted By: Celtic Minstrel

Class member of what?

creature_data_type (Ormus' work)

Originally Posted By: Celtic Minstrel

I've already deleted the unused fields in my code, since I'm not worried about compatibility (the original struct is still used anyway for loading). I believe your code also uses the original struct for loading?

Ok for the bit field. And i use the original structures for loading as well.

Chokboyz

[Celtic Minstrel]

Ah, I see, it was checking that case when the horses are first mounted, not while the party is mounted. Fixed.

 

As for the absorb spells thing, I searched for the keyword "absorbed" but only found the damage_monst() case... that one's fixed, but I'm not sure where to find the other one.

 

I did it like this:

Code:

if (((dam_type == 1) || (dam_type == 3) || (dam_type == 5))    && (victim->spec_skill == 26)) {    if(32767 - victim->health > how_much)        victim->health = 32767;    else victim->health += how_much;    ASB("  Magic absorbed.");    return false;}

[Celtic Minstrel]

Originally Posted By: Chokboyz

safety check for Absorb Spell done. Tested and work.

Originally Posted By: Example of code

if (((dam_type == 1) || (dam_type == 3) || (dam_type == 5))
&& (victim->m_d.spec_skill == 26)) {
if((victim->m_d.health + how_much) < 32767)
victim->m_d.health += how_much;
ASB(" Magic absorbed.");
return FALSE;
}

(note that there's two occurences of the Absorb Spells check in the code)

Whoa, I just thought of something that's possibly not quite right here. Suppose you have an Absorb Spells monster whose current health is 32760, and you do 10 damage. Since 32760 + 10 = 32770 > 32768, the magic will not be absorbed, false will not be returned, and possibly the monster may take damage.

Originally Posted By: Celtic Minstrel

Perhaps the following breakdown of PSD[304][???] would work:

Code:

 0 .. 5 - PC present? ( > 0 means yes) 6 .. 7 - Town x,y loc of left-behind characters      8 - Town of left-behind characters

Did I miss anything?

I'm going to implement this. If I recall, there should be at least two places where PSD[sDF_IS_PARTY_SPLIT] is checked or set, plus I need to convert existing party split data when loading a saved game. Is there anything else I should know here?

Originally Posted By: Niemand

I would argue that Chokboyz' method is, in rough outline, perfectly good for use in C++ with a bit of tweaking. First, use std::strings instead of character arrays, naturally, and use find() to look for opening and closing angle brackets. If you find a matching pair of them, pass the contents off to a function for conversion into the desired string, which you would substitute in with replace(). This would be easier if you changed the format so be like <name n>, where n is the number of the creature whose name to substitute, so that the type of data (the name) and the creature for which to get it are neatly separated. You could conceivably support other substitutions than just names as well, if there are any that designers are likely to want.

This will go on the todo list.

[Chokboyz]

Originally Posted By: Celtic Minstrel

As for the absorb spells thing, I searched for the keyword "absorbed" but only found the damage_monst() case... that one's fixed, but I'm not sure where to find the other one.

It's because it doesn't print text in the second case :

Originally Posted By: From Mac code

void magic_adjust(creature_data_type *which_m,short *how_much)
{
if (which_m->m_d.spec_skill == 26) {
*how_much = 0;
which_m->m_d.health += 3;
}
if (which_m->m_d.immunities & 1)
*how_much = *how_much / 2;
if (which_m->m_d.immunities & 2)
*how_much = 0;}

Originally Posted By: Celtic Minstrel

I did it like this [...]

I did it pretty much the same except i won't max the health ... Either way is fine for me.

Originally Posted By: Celtic Minstrel

Whoa, I just thought of something that's possibly not quite right here. Suppose you have an Absorb Spells monster whose current health is 32760, and you do 10 damage. Since 32760 + 10 = 32770 > 32768, the magic will not be absorbed, false will not be returned, and possibly the monster may take damage.

There's no brackets after the if, so the only part skipped will be the health increase. The string "Magic absorbed" will be added to the text buffer and FALSE will in fact be returned.

Originally Posted By: Celtic Minstrel

Nice and descriptive, though a little long. (I also prefer thisTypeOfName, but that's beside the point.) How about simply adjust_hp?

I don't mind typing but i understand your point. Adjust_hp is little more misleading, but that's ok if you prefer.

Originally Posted By: Celtic Minstrel

I'm going to implement this. If I recall, there should be at least two places where PSD[sDF_IS_PARTY_SPLIT] is checked or set, plus I need to convert existing party split data when loading a saved game. Is there anything else I should know here?

Quick glance at the code : i've got, three checks for the PSD is_party_split ([304][0]), one at the end of the handle_action() function which kicks in if the party is toasted, the second is the Split Party node safety check and the third is a safety check at the beginning of the end_split() function.
I've also got three setting of this PSD : one in start_split(), one in end_split() function and the third when using the Leave Town debug key.

Functions related start_split() and end_split().

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

in the function create_out_combat_terrain(), the cave bridge battlefield is never created (a basic cave floor battlefield is used instead) because the check

Click to reveal..

if (ter_type > 260)
ter_type = 1;
else ter_type = general_types[ter_type];

should be something like :

Click to reveal..

if(ter_type == 401 || ter_type == 402)
ter_type = 4;
else if (ter_type > 260)
ter_type = 1;
else ter_type = general_types[ter_type];

This was fixed in a different way: by extending the general_types array. Look in classes/terrain.cpp in my code; the arenas[274] array in cTerrain::operator= is my equivalent of the general_types array.

(I actually hadn't already done it, though, but it's done now.)

I made regular water and water with rock also invoke the bridge. I considered making lava invoke the new (yet to be created) cave fumarole, but decided against it for compatibility (however I'll set the new bladbase to do that once the new scenario format is available).

Originally Posted By: Chokboyz

Also, in the general_types[] array, the index 80 should be 11 and the indexes 215 and 216 are flipped (should be 1 and 0).
The ter_base[] and ground_type[] arrays are the same, so one should be deleted.

You are correct about index 80. For 215 and 216, I'm taking your work on it (ie I'm not double-checking) and have made the change.

Originally Posted By: Chokboyz

Good work Celtic Minstrel, those links are better organized (not to mention valid) now.
(really trivial things : Spears and Sign and Portents scenario names are misaligned)

Fixed.

Originally Posted By: Chokboyz

When loading an outdoor battlefield, the c_town.town_num is not reset. If there's a boat or horse in the previously visited town, then pcs won't be able to enter the square with the same coordinates as the square the boat/horse was, in town.
To fix it, i set the c_town.town_num to -1 at the beginning of start_outdoor_combat().
(It seems it's a BoE original bug, but i'm not sure of it)

I just checked, and I do in fact set univ.town.num (the equivalent of c_town.town_num) to 200 in the end_town_mode() function.

Originally Posted By: Chokboyz

I've also changed the "Set SDF" debug command to display the value of the specified SDF if value to set it to is -1 (BoA style, seemed like a good idea).

This is now implemented.

Originally Posted By: Chokboyz

Finally, i've added the ability to play sound asynchronously : if the sound number specified to the "Play a Sound" node is -sound_num, then it is played asynchronously.

As far as I can see, this is already the case in my code (it simply says "play_sound(spec.ex1a)". I can't remember if that's because I already changed it or if it was already that way.

Originally Posted By: Celtic Minstrel

I have no objection to keeping both Lethe potions if the weaker one is renamed. I only object to having two distinct items with the same name.

Oh, by the way, is the non-Silverlocke one also weaker? That is, a lower ability strength?

Originally Posted By: Chokboyz

There was a typo in handle_talk_event() preventing name from working (name was spelled nama), that has been fixed.
I've also added the "buy" and "bye" keywords (which were not in the original BoE if i'm not mistaken).

I've done this, and also added some elses (no point checking for "look" when you've already established that the question was "name", right?). Also, with regards to the text box (which I haven't done yet), would it be possible to make it not have focus until the user type 'a'? Then you can type 'n', 'b', 'd', etc, for the default responses, or type "akumq" followed by return to ask about kumquats. (Of course, you can already do this...)

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

As for the absorb spells thing, I searched for the keyword "absorbed" but only found the damage_monst() case... that one's fixed, but I'm not sure where to find the other one.

It's because it doesn't print text in the second case :

Originally Posted By: From Mac code

void magic_adjust(creature_data_type *which_m,short *how_much)
{
if (which_m->m_d.spec_skill == 26) {
*how_much = 0;
which_m->m_d.health += 3;
}
if (which_m->m_d.immunities & 1)
*how_much = *how_much / 2;
if (which_m->m_d.immunities & 2)
*how_much = 0;}

Ah, thanks, fixed.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I did it like this [...]

I did it pretty much the same except i won't max the health ... Either way is fine for me.

Originally Posted By: Celtic Minstrel

Whoa, I just thought of something that's possibly not quite right here. Suppose you have an Absorb Spells monster whose current health is 32760, and you do 10 damage. Since 32760 + 10 = 32770 > 32768, the magic will not be absorbed, false will not be returned, and possibly the monster may take damage.

There's no brackets after the if, so the only part skipped will be the health increase. The string "Magic absorbed" will be added to the text buffer and FALSE will in fact be returned.

Oh, perhaps I misread something yet again...

I like my method better, but I guess it doesn't matter much.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Nice and descriptive, though a little long. (I also prefer thisTypeOfName, but that's beside the point.) How about simply adjust_hp?

I don't mind typing but i understand your point. Adjust_hp is little more misleading, but that's ok if you prefer.

Gah, that part wasn't supposed to be there. It's an exact duplicate of something I said earlier. Anyway, I've already called it adjust_hp. We could call it adjust_diff if you'd prefer.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I'm going to implement this. If I recall, there should be at least two places where PSD[sDF_IS_PARTY_SPLIT] is checked or set, plus I need to convert existing party split data when loading a saved game. Is there anything else I should know here?

Quick glance at the code : i've got, three checks for the PSD is_party_split ([304][0]), one at the end of the handle_action() function which kicks in if the party is toasted, the second is the Split Party node safety check and the third is a safety check at the beginning of the end_split() function.
I've also got three setting of this PSD : one in start_split(), one in end_split() function and the third when using the Leave Town debug key.

Functions related start_split() and end_split().

Oh great, handle_action. Well, hopefully it won't be too hard to find.

With this post, I think I'm finally caught up on this thread (finally).

[Chokboyz]

Originally Posted By: Celtic Minstrel

As far as I can see, this is already the case in my code (it simply says "play_sound(spec.ex1a)". I can't remember if that's because I already changed it or if it was already that way.

I've just checked and, in fact, the Windows code is once again in a different state (call 1000 + sound to assure synchronicity) ... I've corrected that.

Originally Posted By: Celtic Minstrel

I just checked, and I do in fact set univ.town.num (the equivalent of c_town.town_num) to 200 in the end_town_mode() function.

I've moved the town.num set (i use -1) to the end_town_mode() function as well.

Originally Posted By: Celtic Minstrel

I've done this, and also added some elses (no point checking for "look" when you've already established that the question was "name", right?). Also, with regards to the text box (which I haven't done yet), would it be possible to make it not have focus until the user type 'a'? Then you can type 'n', 'b', 'd', etc, for the default responses, or type "akumq" followed by return to ask about kumquats. (Of course, you can already do this...)

The text input box is an option (activated via "Preferences"), that "a" always brings up the ask box.

Chokboyz

Edit :

Originally Posted By: Celtic Minstrel

We could call it adjust_diff if you'd prefer.

Sold.

Originally Posted By: Celtic Minstrel

Oh great, handle_action. Well, hopefully it won't be too hard to find.

Within the ten last lines

Originally Posted By: Celtic Minstrel

With this post, I think I'm finally caught up on this thread (finally).

I've got a few things already added that will made it through Classic BoE version 1.0, but you done the hardest part

[Celtic Minstrel]

Any chance of moving SDF(305,4..8) to SDF(306,10..13)? I'd sort of like to have all preferences on row 306... then I could do something like PSD[PREFS][NO_MAPS] to access them. (By the way, is PSD[305][7] actually unused?)

 

It's not that important though. I can think of another way to get a similar effect.

 

 

For the new party splitting, I've implemented it as well as moving all relevant functions into the cParty class (party_record_type in your code). However, I'm not happy with it yet, so I haven't included conversion code when loading a saved game. That will be added later.

 

What I'm not happy with in the current one is that you cannot split the party if they are already split. I'm thinking about adding a few fields to the player class and extending adven to allow for more than 6 players (but still only access the first 6). This would facilitate both more complex splits (for example, send half the party into a cave, then send one of those three up a narrow passage) and character storage (as in Avernum 2, in Formello for example). Each player would therefore need to store their own global location (basically town number and location in town), or perhaps a unique ID which represents which party subset they are in.

 

If we chose the ID route, the above two examples could be implemented fairly simply, I think. Assume you have 6 characters. You come to an inn and store one of them there; this character gets an absence ID of 1, and has STORED added to his main status. Then you come to a cave where you can only take half of your party. The two you leave behind get an absence ID of 2, and have SPLIT added to their main status. And finally, you come to a narrow passage where only one player can enter. The other two receive an absence ID of 3 and have SPLIT added to their main status. If we did this, you would need to provide an absence ID for any time a split party or reunite party node is called, as well as for whenever a store/fetch character node is called. It would also be conceivable to reunite with absence ID 2 before reuniting with absence ID 3; we would probably want to have code that somehow displays split-off groups on the map and automatically reunites you if you step on them.

 

 

 

EDIT: By the way, is there any reason the "Reunite Party" debug option cannot be implemented using the end_split() function?

[Chokboyz]

Originally Posted By: Celtic Minstrel

Any chance of moving SDF(305,4..8) to SDF(306,10..13)? I'd sort of like to have all preferences on row 306... then I could do something like PSD[PREFS][NO_MAPS] to access them.

I didn't change the SDF array, but i guess it's ok ...

Originally Posted By: Celtic Minstrel

(By the way, is PSD[305][7] actually unused?)

I use it for "Faster Boom Effects", but can change that easily.

Implementing Split with the ID method would probably works ... That seems quite a lot of work, though

Originally Posted By: Celtic Minstrel

EDIT: By the way, is there any reason the "Reunite Party" debug option cannot be implemented using the end_split() function?

I don't have such debug option. If you're speaking about the check in the "Leave Town" node (case 'B'), then it's basically doing the basic operations needed to reunite party without the need to call the function.

Chokboyz

[The Almighty Doer of Stuff]

FYI, Ctrl+N does not create a new party, despite advertisement to the contrary in the File menu.

[Chokboyz]

Originally Posted By: The Almighty Doer of Stuff

FYI, Ctrl+N does not create a new party, despite advertisement to the contrary in the File menu.

Fixed.
I wonder how many things remains advertised but non working because whoever put it in forgot to wrote a last line of code (that was the case here) ...

Thanks,
Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Any chance of moving SDF(305,4..8) to SDF(306,10..13)? I'd sort of like to have all preferences on row 306... then I could do something like PSD[PREFS][NO_MAPS] to access them.

I didn't change the SDF array, but i guess it's ok ...

Okay, it goes on the todo list then.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

(By the way, is PSD[305][7] actually unused?)

I use it for "Faster Boom Effects", but can change that easily.

If I recall correctly, I made that a global preference rather than a local preference (assuming I've implemented it; I think I have).

Originally Posted By: Chokboyz

Implementing Split with the ID method would probably works ... That seems quite a lot of work, though

Not that much. It would be a radical change though.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

EDIT: By the way, is there any reason the "Reunite Party" debug option cannot be implemented using the end_split() function?

I don't have such debug option. If you're speaking about the check in the "Leave Town" node (case 'B'), then it's basically doing the basic operations needed to reunite party without the need to call the function.

Yes, that's the one I meant. Is there any reason you can't call end_split() there?

[Chokboyz]

Originally Posted By: Celtic Minstrel

Yes, that's the one I meant. Is there any reason you can't call end_split() there?

There's no reason preventing end_split() from being called.
(the reason why i don't call it, is that I prefer setting a few values manually (it's a debug function after all ), bypassing the checks of end_split() than calling the big function. But it's completely irrevelant, end_split() will, of course, works there)

Chokboyz

Edit : little question, what is this item "type flag" field ? Ok, I see, it's a field that is used when combining things, adding charges, etc ...
And how comes it value can range from 0 to 1000 when its type is unsigned char ?
Also, is there a reason why items with "type_flag == 15" are destroyed first when an item needs to be destroyed ?
Those two should be fixed in my opinion.

[The Almighty Doer of Stuff]

Type 15 is your standard, run-of-the-mill Rock, both the large form and the small form.

[Celtic Minstrel]

Originally Posted By: Chokboyz

Edit : little question, what is this item "type flag" field ? Ok, I see, it's a field that is used when combining things, adding charges, etc ...

That's correct. (By the way, I think there's a problem in which brewed potions won't combine with potions found in the scenario. I'm not sure there's anything that can be done to fix that though. There's also another problem where preset items – the ones given to a new party – won't combine with equivalent items in a scenario.)

Originally Posted By: Chokboyz

And how comes it value can range from 0 to 1000 when its type is unsigned char ?

Eep, I've just changed it to unsigned short.

Originally Posted By: Chokboyz

Also, is there a reason why items with "type_flag == 15" are destroyed first when an item needs to be destroyed ?

Uh, what? I have no idea why that would be the case. In the bladbase, type flag 15 is the two rocks, so it doesn't really matter, but someone could reuse it in a scenario if they decide to delete the rocks. Skipping the check wouldn't hurt anything (it won't make a difference if the party doesn't lose any rocks they may be carrying), so I say we should remove it. Which function?

[Lilith]

Originally Posted By: Celtic Minstrel

In the bladbase, type flag 15 is the two rocks, so it doesn't really matter, but someone could reuse it in a scenario if they decide to delete the rocks.

Reusing type flags is generally a bad idea. What if someone brings in rocks from another scenario?

[Chokboyz]

Originally Posted By: The Almighty Doer of Stuff

Type 15 is your standard, run-of-the-mill Rock, both the large form and the small form.

That explains why it would be deleted first, thanks

Originally Posted By: Celtic Minstrel

That's correct. (By the way, I think there's a problem in which brewed potions won't combine with potions found in the scenario. I'm not sure there's anything that can be done to fix that though. There's also another problem where preset items – the ones given to a new party – won't combine with equivalent items in a scenario.)

Sounds like not giving the correct (or any) type_flag for those items ...

Originally Posted By: Celtic Minstrel

Uh, what? I have no idea why that would be the case. In the bladbase, type flag 15 is the two rocks, so it doesn't really matter, but someone could reuse it in a scenario if they decide to delete the rocks. Skipping the check wouldn't hurt anything (it won't make a difference if the party doesn't lose any rocks they may be carrying), so I say we should remove it. Which function?

I've skipped it already as the rocks will be destroyed first with the second check anyway.
Function : destroy_an_item() .

Chokboyz

[The Almighty Doer of Stuff]

The first 100 flags are reserved by the game for standard items that are used in most scenarios, so that they'll combine between different scenarios. I believe 101+ type flags are stripped from the items when the party leaves the scenario.

 

Also, I think Chokboyz was referring to deleting items when there's more items on the ground in a town than the game can handle. It deletes rocks from the ground first because nobody cares about rocks. Better to delete a rock than to delete the Ubersword of Death.

 

(Side note: I almost called Chokboyz "Ormus". I must be more tired than I thought. Bedtime!)

[Chokboyz]

Originally Posted By: The Almighty Doer of Stuff

The first 100 flags are reserved by the game for standard items that are used in most scenarios, so that they'll combine between different scenarios. I believe 101+ type flags are stripped from the items when the party leaves the scenario.

Ok, that all makes sense now ... Thanks.

Originally Posted By: The Almighty Doer of Stuff

Also, I think Chokboyz was referring to deleting items when there's more items on the ground in a town than the game can handle. It deletes rocks from the ground first because nobody cares about rocks. Better to delete a rock than to delete the Ubersword of Death.

That's it.
For information (designers out there ?) : rocks are (were) deleted first, then items with value less than 3, then items with value less than 30, then non-magical items, then a random item.

Conclusion : don't give your Ubersword of Death a value less than 30

Chokboyz

[Lilith]

Originally Posted By: Chokboyz

Conclusion : don't give your Ubersword of Death a value less than 30

Chokboyz

This is annoying, because a lot of scenario designers deliberately give important items a value of 0 so they can't be accidentally sold.

[Celtic Minstrel]

Originally Posted By: Thuryl

Reusing type flags is generally a bad idea. What if someone brings in rocks from another scenario?

Well, that's true, yeah...

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

That's correct. (By the way, I think there's a problem in which brewed potions won't combine with potions found in the scenario. I'm not sure there's anything that can be done to fix that though. There's also another problem where preset items – the ones given to a new party – won't combine with equivalent items in a scenario.)

Sounds like not giving the correct (or any) type_flag for those items ...

Well, I think it should be fixed iff the items are actually equivalent.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Uh, what? I have no idea why that would be the case. In the bladbase, type flag 15 is the two rocks, so it doesn't really matter, but someone could reuse it in a scenario if they decide to delete the rocks. Skipping the check wouldn't hurt anything (it won't make a difference if the party doesn't lose any rocks they may be carrying), so I say we should remove it. Which function?

I've skipped it already as the rocks will be destroyed first with the second check anyway.
Function : destroy_an_item() .

That destroys an item on the ground, right? We can probably do away with it actually. Not yet, but eventually. Still, I'll skip the check for now. (It's also not at all what I thought you were talking about. )

Originally Posted By: The Almighty Doer of Stuff

The first 100 flags are reserved by the game for standard items that are used in most scenarios, so that they'll combine between different scenarios. I believe 101+ type flags are stripped from the items when the party leaves the scenario.)

Well, they shouldn't be. If anything, it should just set the type flag to nothing (0, I guess).


By the way, if two different items combine because they share the same type flag, which item takes priority? I'm talking about the case where they are distinct items with different properties. This could create problems if someone is stupid enough to (for example) give type flag 38 to an Avatar Brew or something. (Type flag 38 is candles in the bladbase.) If they already had an Avatar Brew and they picked up a candle, would they lose the brew or would it gain an extra charge? If they had a candle and they picked up an Avatar Brew, would they gain a candle and not get the brew, or would the candle disappear and they get an extra charge on the brew? Or is there a check to avoid such bugs? There probably should be, though I'm not quite sure what.

[Celtic Minstrel]

Originally Posted By: Thuryl

This is annoying, because a lot of scenario designers deliberately give important items a value of 0 so they can't be accidentally sold.

I thought you could sell items with a value of 0. Regardless, we could consider adding a flag for this. In fact, I think the best way would be to change the Cursed flag so that it prevents items from being unequipped, but shops will still buy it. Then the Not Sellable flag (or whatever you want to call it) means shops won't want to buy it. And when converting old scenarios, all items with the Cursed flag are automatically given the Not Sellable flag as well.


Speaking of item flags, I added an "Enchanted" flag a while back. I think it was so that if you enchant a sword with Shoot Flames, it won't disappear once it runs out of charges. (That is currently the case, right?)

[Lilith]

Pretty sure it's whichever item they're carrying first that gets kept, but you're the one who's poking around in the source code.

[Lilith]

Originally Posted By: Celtic Minstrel

I thought you could sell items with a value of 0.

Nope. You can sell items with a value of 1 for 0 coins, though, I think.

[Chokboyz]

Originally Posted By: Thuryl

This is annoying, because a lot of scenario designers deliberately give important items a value of 0 so they can't be accidentally sold.

I don't know if that would help, but we can check for a potential special class before deleting the item ...

Originally Posted By: Celtic Minstrel

Speaking of item flags, I added an "Enchanted" flag a while back. I think it was so that if you enchant a sword with Shoot Flames, it won't disappear once it runs out of charges. (That is currently the case, right?)

It indeed disappear with the last charge ...

Originally Posted By: Thuryl

Pretty sure it's whichever item they're carrying first that gets kept, but you're the one who's poking around in the source code.

Exact, first on the list absorb the others.

Chokboyz

[Lilith]

Originally Posted By: Celtic Minstrel

Speaking of item flags, I added an "Enchanted" flag a while back. I think it was so that if you enchant a sword with Shoot Flames, it won't disappear once it runs out of charges. (That is currently the case, right?)

This is a good idea. It should also change the way an item's value is calculated so that it's no longer affected by the number of charges remaining. (so a flame-shooting sword with 2 charges left doesn't have twice the value of the same sword with 1 charge left).

[Celtic Minstrel]

Is it currently affected by the number of charges? I thought there were some items whose value is multiplied by the charges, and others whose value isn't multiplied by the charges.

[Lilith]

No, they all are. A few items in custom scenarios have crazy negative values because of it.

[The Almighty Doer of Stuff]

Originally Posted By: Celtic Minstrel

Originally Posted By: The Almighty Doer of Stuff

The first 100 flags are reserved by the game for standard items that are used in most scenarios, so that they'll combine between different scenarios. I believe 101+ type flags are stripped from the items when the party leaves the scenario.)

Well, they shouldn't be. If anything, it should just set the type flag to nothing (0, I guess).

This is what I meant when I said the "101+ type flags are stripped from the items" and not "items with 101+ type flags are stripped from the party".

Quote:

By the way, if two different items combine because they share the same type flag, which item takes priority? I'm talking about the case where they are distinct items with different properties. This could create problems if someone is stupid enough to (for example) give type flag 38 to an Avatar Brew or something. (Type flag 38 is candles in the bladbase.) If they already had an Avatar Brew and they picked up a candle, would they lose the brew or would it gain an extra charge? If they had a candle and they picked up an Avatar Brew, would they gain a candle and not get the brew, or would the candle disappear and they get an extra charge on the brew? Or is there a check to avoid such bugs? There probably should be, though I'm not quite sure what.

You'd have to be careful though, because sometimes, as is the case with the two different sized rocks, you want two different items to combine into one stack.

Originally Posted By: Celtic Minstrel

In fact, I think the best way would be to change the Cursed flag so that it prevents items from being unequipped, but shops will still buy it. Then the Not Sellable flag (or whatever you want to call it) means shops won't want to buy it. And when converting old scenarios, all items with the Cursed flag are automatically given the Not Sellable flag as well.

Cursed items can be sold, though, once they're uncursed with Remove Curse or by a healer. This behavior should be preserved.

[Celtic Minstrel]

Originally Posted By: The Almighty Doer of Stuff

This is what I meant when I said the "101+ type flags are stripped from the items" and not "items with 101+ type flags are stripped from the party".

Oh. Why do I keep misreading things?

Originally Posted By: The Almighty Doer of Stuff

You'd have to be careful though, because sometimes, as is the case with the two different sized rocks, you want two different items to combine into one stack.

True. I believe the torches are another example? But the possibility of disastrous results like I mentioned indicates we should probably change something.

Maybe instead of a type flag we should have items combine only with items that are "equal", where "equal" means that all functional fields are the same (so, not including graphic, for example). And then use the type flag field to specify the number of some other item that it can also combine with. (Only problem is, what if you have three separate items which should be able to combine into a single stack?)

Originally Posted By: The Almighty Doer of Stuff

Cursed items can be sold, though, once they're uncursed with Remove Curse or by a healer. This behavior should be preserved.

Yes, so Remove Curse would cancel both properties if Cursed is set, but would have no effect if Cursed is not set but Not Sellable is.

EDIT: I thought I posted something about the special queue using "max", but I can't find it... and it's not in my code...

[Lilith]

Originally Posted By: Celtic Minstrel

Maybe instead of a type flag we should have items combine only with items that are "equal", where "equal" means that all functional fields are the same (so, not including graphic, for example). And then use the type flag field to specify the number of some other item that it can also combine with. (Only problem is, what if you have three separate items which should be able to combine into a single stack?)

I dunno. I can imagine situations in which the current "disastrous" behaviour would be useful to a designer as part of a puzzle, although I'm not sure if any existing scenario has relied on it.

[Celtic Minstrel]

Hmm... give an example?

 

 

 

On an unrelated note... Chokboyz, is it possible for you to alter any member functions that call add_string_to_buf so that they return the string to add instead of adding it themselves? That's what I'm going to do when I get there (and already have done with the splitting functions). Since add_string_to_buffer only exists in the game (and not the editors), it's necessary in order to be able to use the exact same code for all three. (Unless we do some conditional compilation stuff, I suppose.)

 

Also... calling add_string_to_buf() with an empty string now does nothing.

[Lilith]

Originally Posted By: Celtic Minstrel

Hmm... give an example?

Two items with the same type flag but different special classes, in a scenario designed for a singleton party. You can't carry both items at once, because they stack together if you do. The aim is to get both items from point A to point B, where point B is at the other end of some kind of moving-wall or conveyor-belt puzzle.

Or, in a scenario not designed for a singleton party, you could force two items to be carried by two different characters in the same way, for plot reasons or something.

[The Almighty Doer of Stuff]

As an alternative to fixing the "problem", we could hypothetically just tell designers to be careful about giving different items the same type flag, and not try to protect them from themselves.

[Chokboyz]

Originally Posted By: Celtic Minstrel

On an unrelated note... Chokboyz, is it possible for you to alter any member functions that call add_string_to_buf so that they return the string to add instead of adding it themselves? That's what I'm going to do when I get there (and already have done with the splitting functions). Since add_string_to_buffer only exists in the game (and not the editors), it's necessary in order to be able to use the exact same code for all three. (Unless we do some conditional compilation stuff, I suppose.)

Added on the TODO list.

Originally Posted By: Celtic Minstrel

Also... calling add_string_to_buf() with an empty string now does nothing.

Done.

Originally Posted By: The Almighty Doer of Stuff

As an alternative to fixing the "problem", we could hypothetically just tell designers to be careful about giving different items the same type flag, and not try to protect them from themselves.

That's a good idea

Chokboyz

[Celtic Minstrel]

I think perhaps we should add a warning when items are combining that are not the same item (ie same number). Otherwise, if a designer decided to do something like what Thuryl described, the player may get confused and wonder why they have lost an item that they formerly had. And also the warning should allow the player to cancel picking the item up or giving the item to another player.

[Chokboyz]

Originally Posted By: Celtic Minstrel

I think perhaps we should add a warning when items are combining that are not the same item (ie same number). Otherwise, if a designer decided to do something like what Thuryl described, the player may get confused and wonder why they have lost an item that they formerly had. And also the warning should allow the player to cancel picking the item up or giving the item to another player.

It can becomes quite tedious, but seems doable.
Writing a new dialog seems to be the only required task as either cancelling the pick up or giving the item to another player functions are (?) already there(a simple return for the first and a "select pc" call for the second).

On the coding side : began adding some *i nodes (after all, all that needs to be done is implement them ).
What has been implemented for now :

• Added a "Change Town Lightning" node. (special number 196, town special)
  Use messages, don't use SDF, Jump To unchanged,
  Extra.1a : lightning level to change to (0 - fully lit, 1 - Dark, 2 - Very Dark, 3 - Totally Dark). If not within [0,3], don't change town lightning.
  Extra.1b : Unused
  Extra.2a : Amount of party light level to change.
  Extra.2b : 0 is give light to party, 1 is take light, other is do nothing.
  Dynamically change the lightning of a town or the party light level.
• Changed the "Has enough Mage Lore ?" node to "Has enough Statistic ?". (special number 153, ifthen special)
  Don't use messages, don't use SDF,
  Extra.1a :If he party has (at least) this much of skill
  Extra.1b : Call this special.
  Extra.2a : Skill to check (0 - Strengh to 18 - Luck). If -1, checks Mage Lore like in legacy (compatibility).
  Extra.2b : Checking method : 0, others - cumulative, 1 - highest, 2 - average, 3 - lowest, 10 + x - that PC.
  If -1, checks Mage Lore like in legacy (compatibility).
  Jump to : Otherwise call this special.
  Checks the amount of a given skill and acts accordingly.
  If a pc a selected or party is split, only this pc is checked.
  Only alive PC are taken into account.
• Added a "Has enough of species ?" node. (special number 156, ifthen special)
  Don't use messages, don't use SDF,
  Extra.1a : Which Species (0 - Human, 1 - Nephil, 2 - Slith)
  Extra.1b : Special to jump to if met.
  Extra.2a : How many party members need species (i.e if number >= extra.2a)?
  Extra.2b : Unused.
  Jump to : Otherwise call this special.
  Checks if the party has so many characters with a given species and acts accordingly.
  Only alive PC are taken into account.

If that seems ok (i.e nothing forgotten), i'll post the code.

The hide map option has also been added to Town Options ("This place defies mapping" sentence adopted).

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I think perhaps we should add a warning when items are combining that are not the same item (ie same number). Otherwise, if a designer decided to do something like what Thuryl described, the player may get confused and wonder why they have lost an item that they formerly had. And also the warning should allow the player to cancel picking the item up or giving the item to another player.

It can becomes quite tedious, but seems doable.
Writing a new dialog seems to be the only required task as either cancelling the pick up or giving the item to another player functions are (?) already there(a simple return for the first and a "select pc" call for the second).

I think you misunderstood something there. There are two situations in which items may stack: when picking them up, or when giving an item to another player. (Possibly also "Give Item" nodes... that might require something slightly different.) So I wasn't actually saying that they should be able to select a different PC to get the item. They should just be given the option to cancel.

Those other nodes seem okay. The -1 check for Mage Lore will be unnecessary though. Were 196 and 156 formerly unused? In Has Species, did you cap it at the number of characters in the party? (ie If there are only two characters and you have a Has 3 Sliths? node, it evaluates as true if both characters are sliths.) For Has Enough Statistic, perhaps 16 for the currently selected PC (ie selected with a Select PC node).

Since you're starting on Stareye's node, I think I'll start delving into other custom nodes.

EDIT: Oh, another thing. For "Has Enough Statistic?" you should probably add the ability to check hit points (19) or spell points (20). (Alternatively they could be -1 and -2, but that's probably not as good and even confusing.)

[Chokboyz]

Originally Posted By: Celtic Minstrel

I think you misunderstood something there. There are two situations in which items may stack: when picking them up, or when giving an item to another player. (Possibly also "Give Item" nodes... that might require something slightly different.) So I wasn't actually saying that they should be able to select a different PC to get the item. They should just be given the option to cancel.

Hum, you're right ... I thought the "or giving the item to another player" part was the player's decision

Originally Posted By: Celtic Minstrel

The -1 check for Mage Lore will be unnecessary though.

In the end, it will (scenario make version check) indeed

Originally Posted By: Celtic Minstrel

Were 196 and 156 formerly unused?

Yes, 195 was the last "ifthen" special and 156 is the first "unused" special in the "town specials" (right before the rect_specials, but i think you said it's was a windows specificy ...)

Originally Posted By: Celtic Minstrel

In Has Species, did you cap it at the number of characters in the party? (ie If there are only two characters and you have a Has 3 Sliths?

I didn't put any cap to the number of character to check for. It's up to the designer to take into account that party may be smaller than six pcs (e.g if you want to check if the full team is slith, you put 6, and since pc_number is less or equal to 6 that would mean full party whatever the size).
It's open for discussion, though.

Originally Posted By: Celtic Minstrel

For Has Enough Statistic, perhaps 16 for the currently selected PC (ie selected with a Select PC node).

For now, if a pc is selected (via a Select PC node), he and only he, is checked. Do you suggest we don't make this as the default behavior but rather a special case ?

Originally Posted By: Celtic Minstrel

Oh, another thing. For "Has Enough Statistic?" you should probably add the ability to check hit points (19) or spell points (20). (Alternatively they could be -1 and -2, but that's probably not as good and even confusing.)

I was planning of doing a dedicated node for Health/Spell Points/Experience checking, but why not

Chokboyz

Edit : the variable c_town.town.specials2 is checked in the code to prevent Magic Map from being casted. Do we plan on using that or do I changed it to check the hide_map variable ? (there's no way to set specials2 for now but i can change that quite easily)

[The Almighty Doer of Stuff]

A skill point check couldn't hurt as well, I think.

 

As for the species check, could it possibly be set up so designers can set whether to check if the number of that species is less than, equal to, or greater than the specified number?

[Chokboyz]

Originally Posted By: The Almighty Doer of Stuff

A skill point check couldn't hurt as well, I think.

Ok, i'll add it.

Originally Posted By: The Almighty Doer of Stuff

As for the species check, could it possibly be set up so designers can set whether to check if the number of that species is less than, equal to, or greater than the specified number?

Using the last field for the checking method ? No problem

Chokboyz

Edit : I've modified the give spell nodes, so that the spec.1b field determinates if the spell is to be given or taken (0 is take, 1 is give, -1 is legacy). Low level spells can now be accessed if 100 + x in the spec.1a field.

The last one i'm considering to implement is the "Make town hostile -> Set Town attitude" one (as in this post http://pied-piper.ermarian.net/topic/7/001822). Should i bother ?

I've also added, some time ago, the ability for an object to call scenario specials, should i add the same type of ability with town/outdoor specials ?

[Celtic Minstrel]

Originally Posted By: Chokboyz

For now, if a pc is selected (via a Select PC node), he and only he, is checked. Do you suggest we don't make this as the default behavior but rather a special case ?

I think we should avoid having special nodes not in the "Affect PC" class from relying on the result of Select PC (by default, that is). Since this is an If-Then node, I'd prefer to make it a special case.

However, that's open for discussion.

Originally Posted By: Chokboyz

I was planning of doing a dedicated node for Health/Spell Points/Experience checking, but why not

Either way would work.

Originally Posted By: Chokboyz

c_town.town.specials2 is checked in the code to prevent Magic Map from being casted. Do we plan on using that or do I changed it to check the hide_map variable ? (there's no way to set specials2 for now but i can change that quite easily)

I've changed it to check the defy_mapping bitfield variable.

Originally Posted By: Chokboyz

Originally Posted By: The Almighty Doer of Stuff

A skill point check couldn't hurt as well, I think.

Ok, i'll add it.

As part of Check Statistic, or as a separate node?

Originally Posted By: Chokboyz

Originally Posted By: The Almighty Doer of Stuff

As for the species check, could it possibly be set up so designers can set whether to check if the number of that species is less than, equal to, or greater than the specified number?

Using the last field for the checking method ? No problem

Actually, this is probably better than the party size cap done by Stareye...

Originally Posted By: Chokboyz

I've modified the give spell nodes, so that the spec.1b field determinates if the spell is to be given or taken (0 is take, 1 is give). Low level spells can now be accessed if 100 + x in the spec.1a field.

I intend to shift the high level spells up so that the numbers you enter are the same as the numbers representing the spells in the actual code. So, 0 is a level 1 spell.

Originally Posted By: Chokboyz

The last one i'm considering to implement is the "Make town hostile -> Set Town attitude" one (as in this post http://pied-piper.ermarian.net/topic/7/001822). Should i bother ?

I think Stareye actually changed the Make Town Hostile node to a Set Creature Attitude node, which I think should instead be a separate node. Then perhaps we could change Make Town Hostile to Set Town Status (valid statuses being friendly, hostile, and dead).

Originally Posted By: Chokboyz

I've also added, some time ago, the ability for an object to call scenario specials, should i add the same ability with town/outdoor specials ?

Um... I think I was planning to make that depend on the Magic Use type. (By "object" you mean "item", right?)

[Chokboyz]

Originally Posted By: Celtic Minstrel

I think we should avoid having special nodes not in the "Affect PC" class from relying on the result of Select PC (by default, that is). Since this is an If-Then node, I'd prefer to make it a special case.

However, that's open for discussion.

Ok, let's see what others think of that, either way is fine with me

Originally Posted By: Celtic Minstrel

Either way would work.
[...]
As part of Check Statistic, or as a separate node?

The Check Statistic node is already quite large in term of code, but it would indeed by easier to do a global function. I'm sure for now ...

Originally Posted By: Celtic Minstrel

I've changed it to check the defy_mapping bitfield variable.

Maybe you can add a little more flexibility by having mappable area but where you can't cast Magic Map ?

Originally Posted By: Celtic Minstrel

Actually, this is probably better than the party size cap done by Stareye...

I've used the last field (ex.2b) to set the calculation method (0 is <, 1 is ==, 2 is >).

Originally Posted By: Celtic Minstrel

I intend to shift the high level spells up so that the numbers you enter are the same as the numbers representing the spells in the actual code. So, 0 is a level 1 spell.

Then a version check has to be done, because that would break legacy compatibility.

Originally Posted By: Celtic Minstrel

I think Stareye actually changed the Make Town Hostile node to a Set Creature Attitude node, which I think should instead be a separate node. Then perhaps we could change Make Town Hostile to Set Town Status (valid statuses being friendly, hostile, and dead).

That seems like a good idea to have two separate nodes. If there's no objections, i'll do that.

Originally Posted By: Celtic Minstrel

Um... I think I was planning to make that depend on the Magic Use type. (By "object" you mean "item", right?)

Yes, i was speaking of items.
Good idea for the magic_use_type (we've got four at disposal, which one will we use ?)

Chokboyz

[Celtic Minstrel]

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I've changed it to check the defy_mapping bitfield variable.

Maybe you can add a little more flexibility by having mappable area but where you can't cast Magic Map ?

Hmm... so, perhaps make the effectiveness of Magic Map contingent on a new separate bitfield flag called "defy_scrying" or something...

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Actually, this is probably better than the party size cap done by Stareye...

I've used the last field (ex.2b) to set the calculation method (0 is <, 1 is ==, 2 is >).

I think I would actually prefer -1 for <, 0 for ==, and 1 for >. I know -1 usually means "unused" in a special, though, which would make < the default (when probably you actually want > to be the default).

Actually, come to think of it, there are many cases where it would probably be beneficial to allow more flexible comparisons (SDF compare? for example). Other options are <=, >=, and !=...

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I intend to shift the high level spells up so that the numbers you enter are the same as the numbers representing the spells in the actual code. So, 0 is a level 1 spell.

Then a version check has to be done, because that would break legacy compatibility.

No, you don't need to check the version. The in-memory structures should not have to adjust for different versions. That's the job of the file IO code.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

I think Stareye actually changed the Make Town Hostile node to a Set Creature Attitude node, which I think should instead be a separate node. Then perhaps we could change Make Town Hostile to Set Town Status (valid statuses being friendly, hostile, and dead).

That seems like a good idea to have two separate nodes. If there's no objections, i'll do that.

Okay then.

Originally Posted By: Chokboyz

Originally Posted By: Celtic Minstrel

Um... I think I was planning to make that depend on the Magic Use type. (By "object" you mean "item", right?)

Yes, i was speaking of items.
Good idea for the magic_use_type (we've got four at disposal, which one will we use ?)

Four is the perfect number; look in my terrain.cpp for the conversion code for "call special" terrain abilities. There are four options: always call a scenario special, call a scenario special if outdoors and a town special if in town, call an outdoor special if outdoors and a scenario special if in town, or call an outdoor special if outdoors and a town special if in town. I don't remember which is which, but for consistency we should probably use the same assignment as for terrain specials. (Even though in this case the designer never sees the numbers. )

[Chokboyz]

Originally Posted By: Celtic Minstrel

Hmm... so, perhaps make the effectiveness of Magic Map contingent on a new separate bitfield flag called "defy_scrying" or something...

I've adopted the "defy_scrying" notation (changeable at will). I think we should also check if hide_map is set because it makes little sense to be able to cast Magic Map and have the map saying it is impossible (but maybe you've already do that ...)

Originally Posted By: Celtic Minstrel

I think I would actually prefer -1 for <, 0 for ==, and 1 for >. I know -1 usually means "unused" in a special, though, which would make < the default (when probably you actually want > to be the default).

No problem. Done

Originally Posted By: Celtic Minstrel

No, you don't need to check the version. The in-memory structures should not have to adjust for different versions. That's the job of the file IO code.

Alright.

Originally Posted By: Celtic Minstrel

Four is the perfect number; look in my terrain.cpp for the conversion code for "call special" terrain abilities. There are four options: always call a scenario special, call a scenario special if outdoors and a town special if in town, call an outdoor special if outdoors and a scenario special if in town, or call an outdoor special if outdoors and a town special if in town. I don't remember which is which, but for consistency we should probably use the same assignment as for terrain specials. (Even though in this case the designer never sees the numbers. )

I'll take a look and implement it so.

I've completed the (big) "Has enough Statistic" node with :
0-18 - corresponding skill
19 - Current Health
20 - Max Health
21 - Current Spell Points
22 - Max Spell Points
23 - Experience
24 - Skill points
25 - Level

Chokboyz

[Cryolemon]

I'm not sure if this has been mentioned (hopefully you'll forgive me for not reading ~600 posts) but is there any fundamental reason for keeping some of the statistic caps at what they are?

 

It would be useful if we could set a monsters health above 2500 in the editor for example. I'm not sure what I think the max should be, 65535 comes to mind although that seems excessive (having said that RPGs like FFVII have had monsters with 1,000,000+ health...)

 

The same goes for PC stats, is there any reason why the stats have to max out at 20? I'd suggest 32. I think max PC Health should be at least 1024 (maybe more, see my previous comment) max level could maybe be increased to 64 or 100.

 

I haven't read the source code (nor do I intend to in detail, c++ isn't really my thing) so I'm not sure if these could be done easily. Hopefully this makes sense.

[Chokboyz]

Besides horribly unbalancing the game, the main reason is that the current phase is, for my part, releasing a stable enhanced,legacy compatible version (hopefully bug free). That's mostly over though and we'll move to deeper changes.

 

I'm not sure having 65535 health is a good idea (or i hope you're also enhancing damages), but that can be achieved quite easily (see monster_record_type and pc_record_type structures).

 

Hope it helps,

Chokboyz

[Celtic Minstrel]

It wouldn't be too hard to change limits. Could it affect game balance, though? We can't make any changes that do that.

 

Originally Posted By: Chokboyz

I've completed the (big) "Has enough Statistic" node with :

0-18 - corresponding skill

19 - Current Health

20 - Max Health

21 - Current Spell Points

22 - Max Spell Points

23 - Experience

24 - Skill points

25 - Level

Hmm... I'm thinking we should include current health, current spell points, experience, skill points, and level in a different node, mainly because there are so many of them. As I see it, a "statistic" is something you can train in, and under that definition those ones don't qualify.

 

Not sure what the other node(s) would be called though.

[Lilith]

It's almost trivial to increase the cap on monster health. Increasing the cap on PC stats raises much more serious game balance issues, though. For one thing, some pre-existing scenarios with premade parties deliberately use a level-50 PC to ensure that the PC won't level up during the scenario.

[Cryolemon]

So game balance is the biggest issue then? Regarding the last thing maybe there could be a general scenario option to not allow levelling up? (Doesn't really help the compatibility issues, but does solve it for the future =/).

 

Chokboyz, Yeah increasing damage, etc as well would be the idea, so you could have things like in FFVII (maybe not to the level of millions of HP though).

 

I suppose the increased caps could be optional and default to off (have them as general scenario options or tied to a saved game or something).

 

Also, on a slightly different subject, is there a limit to how much damage one attack can do? I'm guessing 255 if there is?