Jump to content

Queries on mechanics and incompatible source things


Celtic Minstrel

Recommended Posts

So, I started pulling in most of the changes *i made aeons ago, and noticed that both myself and him fixed the Petrification Touch ability (which, as I recall, caused disease as well), but in a different way. I'm not sure whether I should keep his version only, or try to merge them somehow.

 

This is how I fixed it (with comments added for explanation where needed):

if ((attacker->spec_skill == 30) // Monster has petrification touch?
   && (pc_has_abil_equip(target,49) == 24) // Has protection from petrification item equipped?
   && (get_ran(1,0,20) + univ.party[target].level / 4 + univ.party[target].status[eStatus::BLESS_CURSE]) <= 14)
{
   add_string_to_buf("  Petrifying touch!");
   print_buf();
   kill_pc(target,eMainStatus::STONE); // petrified, duh!
}

And this is how *i fixed it:

if (attacker->spec_skill == 30)    {
   add_string_to_buf("  Petrification touch!                ");
   r1 = max(0,(get_ran(1,0,100) - univ.party[target].level + 0.5*attacker->level));
   // Equip petrify protection?
   if (pc_has_abil_equip(target,49) < 24)
       r1 = 0;
   // Check if petrified.
   if (r1 > 60) {
       kill_pc(target,eMainStatus::STONE);
       add_string_to_buf("    Turned to stone! ");
       play_sound(43);
   }    
   else {
       add_string_to_buf("    Resists! ");                            
   }
}

(It will probably be obvious by now why "retaining my version only" was not among the options I proposed.)

 

So, uh, any thoughts on this? The real difference is how the chance of resisting it is determined - r1 in *i's version, and the second line of my version. I have no idea how either of them were thought up (I wrote my version back in 2009, so I dunno what I was thinking at the time).

 

EDIT: Apparently the Windows code has its own version; I might've copied from there. It's clearly inferior to both, though:

// Petrification touch
if ((attacker->m_d.spec_skill == MONSTER_PETRIFYING_TOUCH) && (get_ran(1,0,8) < 3))
{
   add_string_to_buf("  Petrifying touch!");
   print_buf();
   adven[target].kill(4);
}

 

EDIT #2: Well, I think I figured out where the idea of bless affecting it came from - the code for petrification gaze incorporates that:

if (target < 100) { // on PC
   sprintf (create_line, "  Gazes at %s.                  ",univ.party[target].name.c_str());
   add_string_to_buf(create_line);
   r1 = get_ran(1,0,20) + univ.party[target].level / 4 + univ.party[target].status[eStatus::BLESS_CURSE];
   if (pc_has_abil_equip(target,49) < 24)
       r1 = 20;
   if (r1 > 14) {
       sprintf (create_line, "  %s resists.                  ",univ.party[target].name.c_str());
       add_string_to_buf(create_line);
   }
   else {
       sprintf (create_line, "  %s is turned to stone.                  ",univ.party[target].name.c_str());
       add_string_to_buf(create_line);
       kill_pc(target,eMainStatus::STONE);
   }
}

But, should petrification touch also incorporate it? I'm not sure about that one.

Edited by Celtic Minstrel
Windows! Also gaze. And tags.
Link to comment
Share on other sites

I'm looking at the windows code now, and noticed SDF_COMPATIBILITY_SPECIALS_INTERRUPT_REST. What's the point of this?

 

EDIT: And another: "SDF_ASK_ABOUT_TEXT_BOX".

 

EDIT: Here's another thing; not quite an incompatibility, probably more of a relic from Exile III (maybe Ishad Nha will be able to figure out what it means?)

 

Basically, when you're in town, the game chooses between four possible background patterns based on the lighting type, your outdoor sector, and the number of the town you're in. Here's the code:

if (univ.town->lighting_type > 0) {
   if (univ.party.outdoor_corner.x >= 7)
       bg_pict = bg[1];
   else bg_pict = bg[9];
}
else if ((univ.party.outdoor_corner.x >= 7) && (univ.town.num != 21)) // TODO: What's so special about town 21?
   bg_pict = bg[8];
else bg_pict = bg[13];

I have no idea what is the significance of outdoor sector x >= 7 or town.num == 21. It actually checks for this even when outdoors or in combat, so my tentative guess would be maybe it indicates whether you're on the surface or underground? I'm not really sure if that's it, though. I still have no idea what town 21 is.

Edited by Celtic Minstrel
Back for backgrounds!
Link to comment
Share on other sites

That definitely looks like vestigial Ex3 code. Although...I'm pretty sure there might be some other code for that floating around, because I seem to remember getting random backgrounds every time I entered a town (which might actually be from Ex3, not BoE. It's been awhile).

 

In any case, it could definitely use a tune-up. Perhaps the new scenario format could add a few flags for 'background'/'combat background' to let the designer specify? We should also specify a sane default if not present, probably the same as the main menu bg.

 

Personally, it's always annoying as hell to be playing the game, and then have the background switch from lovely black countertop to HOW ABOUT SCENARIO EDITOR WHITE. It's quite jarring.

 

As far as petrifying touch goes, I'd recommend leaving the bless option in. I remember it being quite hard to counter in Exile 3 (Basilisk Island :( ), of course that was the Windows version, which looks rather...impossible to dodge. It's been awhile since I dealt with the mechanic.

Link to comment
Share on other sites

The Windows code is littered with something like eight compatibility options, some of them quite complicated.

 

  1. Legacy Day Reached behaviour - as far as I can tell, all that this does is add 20 to the day you need to reach for no reason at all, so I'm not going to adopt this. I did however add a line to add 10 to the day you need to reach if easy mode is enabled. Basically this means that if a scenario wants to check that you've reached a given day, it will be told "yes" 10 days later than it expects.
  2. Legacy Kill Node - I haven't quite worked out what this one does, but it looks like it's not necessary even considering changes to the kill node.
  3. Working Town Waterfall - I don't think I need to check for this, but not sure — are there any scenarios that rely on waterfalls not working in town?
  4. Full Trims - I have no idea what this was supposed to do since it seems to be no longer used... unless I missed something somewhere...
  5. Specials Interrupt Rest - Apparently the Windows version has changed stuff so that timed special nodes to interrupt your rest. I'm not sure I like this behaviour, and am inclined to leaving it at the default, though I wouldn't be against adding something like an "Interrupt Rest" node.
  6. Check Timers While Resting - Ambivalent on this, will likely implement it, but I was thinking of a very different implementation. The Windows code runs through repeatedly, jumping something like 100 days at a time and checking in each iteration if something should happen; I thought about simply jumping all the way forward, like the original code did, but then checking afterwards whether an important time was skipped over. There's a significant difference between the two — in my version, you can only have a single event of each type during rest, whereas with the version in the Windows code it looks like it would be possible for the same timer to trigger multiple times while resting.
  7. Trigger Specials On Boat - I'll likely keep this compatibility flag. I'd rather not, but the effort of converting legacy scenarios to insert a new node at the beginning of any chain placed on boatable terrain seems like it's not really worth it.
  8. Compatibility options in preferences - Currently I'm leaning towards not having these, and instead just automatically applying the options to any scenarios that are loaded from the legacy format. (This means that, simply by loading and resaving your scenario, its behaviour could change.) Generally I'd set it up so that designers can still get the legacy behaviour by tweaking something, and whenever possible I'll automatically convert the scenario data so that the legacy behaviour is retained. I think I'd also try to give a warning when I'm able to detect something but not fix it (like the boats thing).

 

Next: In the code for the Bless/Revive All spells, the game calculates but does not use a random number. A comment in the Windows code speculated that it was intended to be used for Revive All. Does anyone have any idea? For reference, spell 16 is Bless All and 24 is Revive All (pretty sure of that).

play_sound(24);
// TODO: What's r2 for here? Should it be used for Revive All?
r1 =  get_ran(2,1,4);
r2 = get_ran(3,1,6);
for (i = 0; i < univ.town->max_monst(); i++)
   if ((monst_near(i,caster->cur_loc,8,0)) &&
       (caster->attitude == univ.town.monst[i].attitude)) {
       affected = &univ.town.monst[i];
       if (spell == 16)
           affected->status[eStatus::BLESS_CURSE] = min(8,affected->status[eStatus::BLESS_CURSE] + r1);
       if (spell == 24)
           affected->health += r1;
   }
play_sound(4);

 

There's one other question I have. I've made it possible to include level 1-3 spells in shops (which could be useful if you have previously removed them using a special node), but I need to assign costs to each of them, and I have no idea what sort of costs they should have. Here's the existing costs (the 5's are just a stand-in until I get proper costs for the low-level spells):

// Mage spells; one line per level, same order as the spellcasting dialog
5,5,5,5,5,5,5,5,5,5,
5,5,5,5,5,5,5,5,5,5,
5,5,5,5,5,5,5,5,5,5,
150,200,150,1000,1200,400,300,200,
200,250,500,1500,300,  250,125,150,
400,450, 800,600,700,600,7500, 500,
5000,3000,3500,4000,4000,4500,7000,5000
// Priest spells; ditto
5,5,5,5,5,5,5,5,5,5,
5,5,5,5,5,5,5,5,5,5,
5,5,5,5,5,5,5,5,5,5,
100,150,75,400,200, 100,80,250,
400,400,1200,600,300, 600,350,250,
500,500,600,800, 1000,900,400,600,
2500,2000,4500,4500,3000,3000,2000,2000

 

 

As far as petrifying touch goes, I'd recommend leaving the bless option in. I remember it being quite hard to counter in Exile 3 (Basilisk Island :( ), of course that was the Windows version, which looks rather...impossible to dodge. It's been awhile since I dealt with the mechanic.

Okay, but what about *i's implementation? Even not accounting for special things like bless, the calculation is completely different and seems incompatible.
Link to comment
Share on other sites

Apparently the Awaken spell has a range of 8. I'm pretty sure this is not supposed to be the case, since the range is no longer used; it was probably a relic from when that spell number was some kind of dispel field spell. I'm just going to set the range to 0.

Link to comment
Share on other sites

Would be nice to see a little more activity here...

 

Anyway, here's my list of differences between monster spells and PC spells. I'll only include those spells that can be cast by both. I'll use "lvl" to refer to the monster's or player's experience level, and INT to refer to their intelligence score (their level of intelligence skill plus any modifiers from items).

 

  • Spark does fire damage when cast by monsters, but magic damage when cast by PCs. Both deal 2d4 damage though.
  • When monsters cast minor haste, it's not capped at 8 as it is when players cast it. Either way it applies no more than 2 levels.
  • Strength is identical when cast by monsters and PCs, applying 3 levels of blessing without capping at 8.
  • Flame cloud is identical when cast by monsters and PCs, creating a single space of fire wall.
  • Flame deals damage by d4's. When cast by monsters, it deals lvl dice of damage; when cast by PCs, it deals 1+⅓lvl+INT, with a max of 10. Note that the number of dice is not capped when cast by monsters.
  • Minor Poison cast by monsters deals 2-3 damage. Minor Poison cast by PCs deals 2+½INT damage.
  • Slow cast by monsters applies 2+½lvl levels of slowing. Slow cast by PCs applies 2+INT or 3+INT levels.
  • Dumbfound cast by monsters applies a flat 2 level of dumbfounding. Dumbfound cast by PCs applies 1+⅓INT levels.
  • Stinking cloud appears to behave identically for monsters and PCs (except that there's no missile animation when cast by PCs).
  • Summon Beast lasts for 3d4+INT turns when cast by PCs. When cast by monsters, it lasts 3d4 turns if the monster is friendly and 3d4+100 turns if the monster is hostile. (Or possibly the other way around; the +100 applies if their attitude is an odd number.)
  • Conflagration is the same when cast by monsters and PCs.
  • Fireball deals damage in d6's. When cast by monsters, it deals 1+¾lvl dice of damage, with a max of 29 dice. When cast by PCs, it comes out to 2+⅔lvl+INT with a maximum of 10 dice. (And for some obscure reason, if it gets more than 10, it multiplies by 8 and divides by 10; I think this would never be reached. For the curious, the exact calculation is: min(9,1 + (lvl * 2) / 3 + INT) + 1)
  • Weak Summoning is quite different between the two versions. When cast by monsters, it summons up to 2d3+1 monsters, stopping immediately if a summon fails (eg due to lack of space). Each monster lasts for a base duration of 4d4 turns; the same roll applies to every monster summoned, so the monsters will all disappear at the same time. There is a +100 to the duration in the same circumstance as Summon Beast.
     
    When cast by PCs, it summons up to ¼lvl+½INT monsters, clipped to the range [1,7], and doesn't give up after a failed summon (so you could get multiple failures). Each monster stays for 4d4+INT turns, and this is rerolled for each monster, so they won't all disappear at the same time.
  • Web works the same for monsters and PCs.
  • Poison when cast by monsters deals d4+3 levels of poison. When cast by PCs, it deals 4+INT/2 levels... no randomness.
  • Ice Bolt when cast by monsters deals 5+lvl/5 dice of cold damage, in d8's. When cast by PCs, it deals lvl+INT dice of damage, with a maximum of 20 dice, but in d4's.
  • Slow Group when cast by monsters deals 2+lvl/4 levels of slowing. When cast by PCs, it deals 5+INT levels.
  • Major Haste when cast by monsters applies a flat 3 levels of hasting. When cast by PCs, it applies 1+lvl/8+INT levels (capping it to 8). Monsters don't have a simple Haste spell, which for PCs applies lvl/2+INT levels of hasting (with a minumum of 2)... which, come to think of it, is actually better than Major Haste. That doesn't sound right, does it? Is this an existing bug, or did I mess up my spell enumification? Major Haste and Major Blessing share some of their implementation, so it's possible I accidentally swapped bits of them.
  • Firestorm deals damage in d6's. When cast by monsters, it deals 4+¾lvl dice of damage. When cast by PCs, it deals 3+⅔lvl+INT dice with a maximum of 14. There's also a seemingly extraneous check for getting a number of dice greater than 20, in which case it multiplies by 8 and divides by 10.
  • Summoning works the same as Weak Summoning, see that entry for details. The only difference is that when cast by PCs, it summons lvl/8+INT/2 monsters (clipped to the range [1,6]) for 5d4+INT turns, while when cast by monsters it summons 2d2+1 monsters for 4d4 turns (with a possible +100).
  • Shockstorm works the same for monsters and PCs.
  • Major Poison when cast by monsters deals d2+6 levels of poison. When cast by PCs it deals 8+INT/2 levels.
  • Kill when cast by monsters deals 3d10+35 damage. When cast by PCs, it deals 3d11+lvl*2-1. (Yes, that's a d11; to be precise, it's get_ran(3,0,10), which also accounts for the -1 in the preceding formula.)
  • Daemon when cast by monster lasts for 3d4 turns, plus a possible +100 as described for Summon Beast. When cast by PCs, it lasts for 5d4+INT turns.
  • Major Blessing when cast by monsters heals 2d10 damage without capping to max health, applies 3d4 levels of blessing (capped at 8), completely cures webs and slowing, and boosts morale by 3d10 points. When cast by PCs, it applies 3+INT levels of haste, 2 levels of weapon poison, and a flat 4 levels of blessing. So, uh... this spell is completely different, which makes it unique amongst the mage spells castable by monsters (all the others at least only differ in the numbers).
  • Major Summoning works the same as Weak Summoning, see that entry for details. The only difference is that when cast by PCs, it summons lvl/8+INT/2 monsters (clipped to the range [1,5]) for 7d4+INT turns, while when cast by monsters it summons 2 or 3 monsters for 4d4 turns (with a possible +100).
  • Shockwave delegates to an external function, so it works identically for monsters and PCs.

 

So, this throws a minor spanner in the works of my idea to unify the monster and PC spellcasting system; while a lot of these differences could be put down to the fact that monsters and PCs simply don't have the same stats, and some are fairly minor mechcanical differences, a few are quite drastic differences. I think I also uncovered a couple of things that might be bugs from looking through this. Two things, in fact.

  • I suspect the haste amounts for Major Haste and Major Blessing got mixed up. It doesn't look like this is my fault, fortunately; is there a known bug on this? As mentioned above, Major Haste currently deals 1+lvl/8+INT levels of haste, capped at 8, while Haste deals lvl/2+INT levels (still capped at 8), and Major Blessing deals 3+INT levels. Supposing you're level 10 with an intelligence modifier of 4, this would mean Haste deals 9 levels (before capping to 8) and Major Haste deals 6 levels. Meanwhile, Major Blessing gives you 7 levels. If you're level 4 with an intelligence modifier of 4, then Haste deals 6 levels and Major Haste deals 5 levels. Hm, on second thoughts, maybe this is a bit more complicated than I though... still, it seems like Major Haste is categorically worse than Haste, which makes no sense whatsoever.
  • The three generic summoning spells for monsters all have the same duration. This doesn't seem likely to be intentional, since the PC ones increase in duration with the higher-level spells.

 

Any thoughts on all this? I only did the mage spells for now since it took awhile and I decided I needed a break from it. Maybe I'll do the priest spells later, if people show any interest.

 

Also, I'm considering maybe renaming the monster version of the Major Blessing spell to something else. Suggestions would be welcome.

 

EDIT: Sorta changed my mind, because I noticed there are a lot more drastic differences with the priest spells. This is a less detailed list, though.

  • Monsters have two priest spells not accessible to PCS: Wrack (a weak Wound) and Unholy Ravaging (slows and poisons).
  • The monster Stumble spell is nothing like the PC Stumble spell. In fact, it's basically identical to the PC Goo spell, so I'm probably going to just rename it to Goo.
  • Wound deals magic damage when cast by monsters. (Wrack deals unblockable damage, though.)
  • Holy Scourge slows in addition to cursing when cast by monsters. Might this be a bug? Should it slow when cast by PCs?
  • Heal All only affects the caster when cast by monsters (healing a flat 50 HP). I doubt this was intentional.
  • Revive all doesn't cure poison when cast by monsters (just heals).
  • Avatar doesn't grant invulnerability or magic resistance when cast by monsters.

 

EDIT 2: And it turns out that most of the monster spells have up to half spell point cost relative to the PC versions. A few have the same cost, but most cost less. This is really a mess...

Link to comment
Share on other sites

stuff

Okay, but what about *i's implementation? Even not accounting for special things like bless, the calculation is completely different and seems incompatible.

Looking at the two, I'm tempted to say I like yours better. I suspect we're going to hit a lot of these, and doing such a great overhaul and merge is definitely going to change some mechanics. In these cases I would always say "do what makes it more fun for the player", and in my personal experience petrification was a bit too much unless you had a handful of special items.

 

Going through the list, I'll give my input (sorry if its poorly-formatted, i just woke up from three hours slep)

  • Spark should do fire damage, it's a fire spell.
  • Minor haste should probably be capped. I've never been a fan of the "apply two hundred minor spells and become a god" style of gameplay, it feels too minmaxey. (probably might be more sane to check every beginning of turn and see if bless/haste/other effect amounts have exceeded bounds, and then trim down, rather than doing this check every spell)
  • Strength: see above.
  • iirc Flame is a pretty low-level spell, so maybe the PC version would be better to keep? Although I'm lead to believe that version doesn't have RNG, which is lame. maybe instead of 1/3*level, make it 1/3(1d(lvl)) or some such?
  • Minor poison: I'd lean towards the PC version...
  • For Slow, any ideas on merging the two?

Actually, looking at these, it makes me wonder if an entire overhaul is in order. I feel like a lot of these aren't taking into account the vast amount of skills and attributes present in the system. Only checking one or two things is nice for tabletop gaming, but we have the luxury of computing. We could make every spell be affected by more than just level and int. (honestly, before i saw the codebase i kind of assumed the game did this, and it seems silly that it doesnt)

 

I'd say maybe have a table of coefficients that each spell is run through. I mean, things like mage lore, luck, etc should be taken into account (as well as items that might do this sort of buffing), when casting spells. Maybe luck makes you sqrt(0.1*luck_levels) more likely to hit. Maybe every level of Priest makes priest spells do 5% more damage. Stuff like that.

 

Perhaps some sort of hook or callback at some point during the spell, maybe something like damage = get_mage_dam_mods(original damage), get_mage_hit_mods, etc., that returns the number modified by these coefficients/whatever.

 

I mean, it's a pretty big overhaul and departure from original game logic, but it seems like a unified codebase is going to make waves no matter what, we might as well take the opportunity to go all thew way. (maybe this is too ambitious a thought?)

Link to comment
Share on other sites

I suspect the haste amounts for Major Haste and Major Blessing got mixed up. It doesn't look like this is my fault, fortunately; is there a known bug on this? As mentioned above, Major Haste currently deals 1+lvl/8+INT levels of haste, capped at 8, while Haste deals lvl/2+INT levels (still capped at 8), and Major Blessing deals 3+INT levels. Supposing you're level 10 with an intelligence modifier of 4, this would mean Haste deals 9 levels (before capping to 8) and Major Haste deals 6 levels. Meanwhile, Major Blessing gives you 7 levels. If you're level 4 with an intelligence modifier of 4, then Haste deals 6 levels and Major Haste deals 5 levels. Hm, on second thoughts, maybe this is a bit more complicated than I though... still, it seems like Major Haste is categorically worse than Haste, which makes no sense whatsoever.

 

The difference between Haste and Major Haste seems fine to me as is, considering that Haste only works on a single target and Major Haste hastes the whole party at once. It does seem odd for Major Blessing to be strictly better than Major Haste under most circumstances for the same spell point cost, though, even given that it's a higher-level spell. If I were going to try and balance them I'd probably be inclined to just increase Major Blessing's spell point cost to at least 12, rather than monkeying around with the number of levels of hasting it causes.

 

Poison when cast by monsters deals d4+3 levels of poison. When cast by PCs, it deals 8+INT/2 levels... no randomness.

(...)

Major Poison when cast by monsters deals d2+6 levels of poison. When cast by PCs it deals 8+INT/2 levels.

 

Is this a typo or is there literally no difference between Poison and Major Poison when cast by PCs?

 

Spark should do fire damage, it's a fire spell.

 

It did magic damage when cast by PCs in Exile 3 as well, and I seem to recall the documentation claiming that it's supposed to do magic damage. Plus, if it does fire damage it's kinda redundant with Flame Cloud. (Not that it's especially useful even if it does magic damage, but...)

Link to comment
Share on other sites

The difference between Haste and Major Haste seems fine to me as is, considering that Haste only works on a single target and Major Haste hastes the whole party at once. It does seem odd for Major Blessing to be strictly better than Major Haste under most circumstances for the same spell point cost, though, even given that it's a higher-level spell. If I were going to try and balance them I'd probably be inclined to just increase Major Blessing's spell point cost to at least 12, rather than monkeying around with the number of levels of hasting it causes.

Oh, silly me, you're right. Somehow I missed that Major Haste is a mass spell. This is the case for monsters too.

 

Is this a typo or is there literally no difference between Poison and Major Poison when cast by PCs?

Ah, whoops, that is a typo. Poison by PCs does 4+INT/2 levels.

 

 

Spark should do fire damage, it's a fire spell.

It did magic damage when cast by PCs in Exile 3 as well, and I seem to recall the documentation claiming that it's supposed to do magic damage. Plus, if it does fire damage it's kinda redundant with Flame Cloud. (Not that it's especially useful even if it does magic damage, but...)

Spark is actually not a fire spell. It's an electricity spell. The spell description in-game is "Fires a weak bolt of electricity at an enemy." And as I recall, electricity is usually represented as magic damage (for example, monsters that breathe electricity deal magic damage).

 

Looking at the two, I'm tempted to say I like yours better. I suspect we're going to hit a lot of these, and doing such a great overhaul and merge is definitely going to change some mechanics. In these cases I would always say "do what makes it more fun for the player", and in my personal experience petrification was a bit too much unless you had a handful of special items.

Hm, okay. I may take some bits from *i's still, thouhgh.

 

Minor haste should probably be capped. I've never been a fan of the "apply two hundred minor spells and become a god" style of gameplay, it feels too minmaxey. (probably might be more sane to check every beginning of turn and see if bless/haste/other effect amounts have exceeded bounds, and then trim down, rather than doing this check every spell)

Alright. You're right that it's silly to have the check in every spell, though. It's make a lot more sense to just use the slow_pc function with negative input, which handles the capping for you.

 

iirc Flame is a pretty low-level spell, so maybe the PC version would be better to keep? Although I'm lead to believe that version doesn't have RNG, which is lame. maybe instead of 1/3*level, make it 1/3(1d(lvl)) or some such?

It does have RNG - the formula in the previous post is the number of dice of damage, so it could range from 1d4 (if level 1 with no intelligence, which might be impossible though) to 10d4.

 

For Slow, any ideas on merging the two?
Huh? Merging? How do you mean? They don't look especially mergeable... or do you mean making the PC version depend on level as well? Keep in mind that monsters don't have an intelligence level.

 

Actually, looking at these, it makes me wonder if an entire overhaul is in order. [...details cut out...] I mean, it's a pretty big overhaul and departure from original game logic, but it seems like a unified codebase is going to make waves no matter what, we might as well take the opportunity to go all thew way. (maybe this is too ambitious a thought?)

Hm, I'm not sure. I'm sort of in favour of keeping most of the basic game logic the same as it used to be except for bug fixes, but I might consider larger changes... I do want the game to play more or less the same though, and we should probably try to avoid changes that have a major effect on the game balance.

 

 

Regarding spell cost, it turns out most of the monster spells have a cost equal to the spell level, which might actually be a relic of the original Exile. The only exceptions are Fireball, Summon Beast, and Weak Summoning, which all cost 4 spell points despite being level 2 or 3. There are more exceptions for priest spells; in particular, all three of the level 7 monster priest spells cost 8 spell points, and Summon Host/Guardian costs 10. Besides that, the only other differences are Pestilence (a leve 6 spell that costs 8sp) and Summon Spirit (a level 2 spell that costs 4sp). That actually makes me wonder if Pestilence used to be level 7...

 

 

I'd particularly like to hear thoughts on the spells that differ the most - Major Blessing, plus the priest spells I listed in the previous post. Basically, should I apply parts of their working from monsters to PCs or vice versa?

 

EDIT: A few more things. Apparently, all monster spells have a fixed range of 10 - this is checked before even deciding to attempt casting a spell. The other odd thing I noticed is that if they don't have enough spell points to cast whatever spell they randomly chose, they automatically regain one spell point in that turn. Admittedly, this is actually the only way they regain spell points, but... it strikes me as a very odd way to do it.

 

And finally, something not specifically related to spells - an attempt at spellcasting drains action points even when it was determined that nothing could be cast (eg due to a lack of spell points, being in an antimagic field, trying to target in an antimagic field, not having a target). The spellcasting function returns true if something happened, but the return value is ignored. This also occurs for breath weapons and missile attacks. Should this be changed?

Link to comment
Share on other sites

So, I went ahead and did some stuff.

 

  • All haste spells delegate to slow_monst/slow_pc. All bless spells delegate to curse_monst/curse_pc. This ensures the cap is handled properly. (All monster spells except I think major haste or blessing previously did not handle the cap.) Note: The names of those functions are a little misleading, as they apply the opposite status effect when receiving a negative input (internally, slow/haste and bless/curse are two unified effects rather than the four they appear as in-game; scenario designers probably already knew this though).
  • Both versions of Spark now deal magic damage. Both versions of Wound now deal unblockable damage.
  • Flame spell for monsters is now capped at 15 dice of damage. Since it works in d4's (as opposed to the PC version's d6's), this gives it the same max damage.
  • Not quite sure on this one, but I changed the monster version of Minor Poison so that it deals a base 2 damage plus a random extra from 0 to half the monster's level (instead of 2 plus rand(0,1)). For level 1 monsters that means it'll always deal 2 damage; for level 2 or 3 monsters it'll be unchanged, and for higher-level monsters it'll do more. I applied a similar change to the monster version of Poison, which previously dealt 4 plus a random extra value from 0 to 3 but now uses half the caster's level as the upper bound for the random number. Monsters need to be at least leve 4 to cast Poison, so such monsters will have a slightly smaller damage range than before (4-6 instead of 4-7).

 

When changing the monster spellcasting code to use the same spell enum constants as the PC spells, I had them ignore the range and use the level as the cost, with a handful of hard-coded exceptions. So, for now, there's no changes to spell costs for monsters.

Link to comment
Share on other sites

Definitely feel free to change. Agree with the part about optimizing fun. I especially like having bless help avoid petrification. I'm also certainly not wed to the exact numbers.

 

I did add some allowance for monster level in mine. I believe the justification was that a level 1 monster with petrification touch should be far less effective than a level 40 one.

Link to comment
Share on other sites

I went over that a little while back, and I did include allowance for the monster's level; I think that's the only bit I took from your version, though. I also added it to petrification gaze, actually. Gaze and touch now use the same calculations, basically.

Link to comment
Share on other sites

  • 3 weeks later...

According to the documentation, the monster missile abilities have the following damage ranges:

  • Darts - 1-6, ie 1d6
  • Arrows - 2-12, ie 2d6
  • Spears - 3-18, ie 3d6
  • Rocks1, Razordisks - 4-24, ie 4d6
  • Rocks2 - 5-30, ie 5d6
  • Rocks3 - 6-36, ie 6d6
  • Good Archer, Spines - 7-42, ie 7d6

 

However, the calculation in the code is quite different ("level" is actually the ability's unique ID number):

 

short dam[40] = {
   0,1,2,3,4, 6,8,7,0,0, 0,0,0,0,0, 0,0,0,0,0,
   8,0,0,0,0, 0,0,0,0,0, 0,0,0,0,6, 0,0,0,0,0
}
r2 = get_ran(dam[level],1,7) + min(10,bless);

 

This gives the following damage ranges, where B stands for the monster's current level of blessing:

  • Darts - 1d7+B, ie 1-7 unblessed
  • Arrows - 2d7+B, ie 2-14 unblessed
  • Spears - 3d7+B, ie 3-21 unblessed
  • Rocks1 - 4d7+B, ie 4-28 unblessed
  • Rocks2, Spines - 6d7+B, ie 6-42 unblessed
  • Razordisks - 7d7+B, ie 7-49 unblessed
  • Rocks3, Good Archer - 8d7+B, ie 8-56 unblessed

 

What should I do about this? I'm altering the ability structure so that you can actually specify the exact damage range, but when converting old monsters, should I use the documented values or the actual values?

Link to comment
Share on other sites

I remember back in the Arena days we noticed that razordisks seemed significantly stronger than their damage range would indicate. That explains that, then.

 

I'd be mildly inclined toward replicating the actual behaviour rather than the documented behaviour; even if we assume that the documented behaviour is what was intended, scenarios will have been tested and balanced around the actual behaviour.

 

I believe there are also differences in the AP costs of different missile abilities, and in whether they can be used at melee range.

Link to comment
Share on other sites

I believe there are also differences in the AP costs of different missile abilities, and in whether they can be used at melee range.

There are, yes. Heat ray costs only 1 AP, razordisks and good archer cost 2 AP, and all others cost 3 AP. (And regular breath weapons cost 4 AP.) I had been thinking about tweaking that.

 

As for whether they can be used at melee range, it looks like all the ones after razordisks can be used at melee range except for good archer and spits acid. I was going to add shoots spines to that list, maybe tweak other things.

 

EDIT: The list of ranged abilities that can be used at melee range:

  • Petrification ray
  • Spell point drain ray
  • Heat ray
  • Breathes stinking clouds
  • Shoots web
  • Paralysis ray
  • Breathes sleep clouds
  • Shoots spines

There was also a comment (not backed up by the code) that said ranged abilities can be used at melee range if they are magical but not gaze attacks.

 

Of the abilities on that list, are there any for which removing the ability to be used at melee range would be undesirable? At the moment I'm only considering changing "shoots web", though.

 

As for AP costs, I was considering going with this:

  • All ray attacks cost 2 AP. (That's down by one for most rays, up by one for heat ray.)
  • Acid/webs cost 3 AP. (So, no change.)
  • Breath weapons (sleep/stink) cost 4 AP, to match the other breath weapons. (Though this seems to contradict another unbacked comment in the source saying that "vapours don't count as an action".)
  • The two arrow abilities cost 3 AP. (To match the PC cost of an equivalent action.)
  • Other non-magic thrown missile abilities cost 2 AP. (Again matching the PC cost. This includes spines.)

 

Link to comment
Share on other sites

Breath weapons (sleep/stink) cost 4 AP, to match the other breath weapons. (Though this seems to contradict another unbacked comment in the source saying that "vapours don't count as an action".)

 

That probably refers to monsters that automatically radiate fields. I don't think there are any of these in the standard Blades of Exile Base, but it's possible to create custom monsters that do so.

 

I'm still not sure I see a lot of reason to change AP costs from what they are, when doing so is inevitably going to mess around with the balance of pre-existing scenarios.

Link to comment
Share on other sites

I'm still not sure I see a lot of reason to change AP costs from what they are, when doing so is inevitably going to mess around with the balance of pre-existing scenarios.

There isn't really a specific reason to change the AP costs, but I'm making the monster abilities more generic, so that means that I have rules about how AP costs are assigned (and some abilities change cost as a side-effect). There are some possible alternatives, though:

  • Let each ability specify whatever AP cost you want. I thought this was too complicated, though monster abilities have already gotten a whole lot more complicated.
  • Have a few hard-coded exceptions for specific combinations of ability settings. I'm already doing this for the "throws webs" ability, and in general I don't really like this solution.
  • Code a few special-case abilities which don't fit into the generic system. There are already a few such abilities (permanent martyr's shield, splitting, absorb spells, death special node, and action special node).

 

These are the things that have changed with regards to AP costs:

  • Heat ray now costs 2 AP instead of 1.
  • Other rays (paralysis, petrify, and sp drain) now cost 2 AP instead of 3.
  • Good archer costs 3 AP instead of 2. Shoots arrows is unchanged at 3 AP, so it makes sense to me to leave this so that they match. It also matches the PC AP cost for shooting arrows.
  • Missile abilities (darts, spears, rocks, spines) cost 2 AP instead of 3 AP. This matches the cost of razordisks as well as the PC cost of thrown missiles.
  • Cloud missiles (sleep, stink) cost 4 AP instead of 3.

 

Here is a before/after list of all ranged abilities:

                      |    Before                |    After
                      |  AP    Usable at melee?  |  AP    Usable at melee?
----------------------+--------------------------+--------------------------
1] Throws darts       |  3     no                |  2     no
2] Shoots arrows      |  3     no                |  3     no
----------------------+--------------------------+--------------------------
3] Throws spears      |  3     no                |  2     no
4] Throws rocks 1     |  3     no                |  2     no
----------------------+--------------------------+--------------------------
5] Throws rocks 2     |  3     no                |  2     no
6] Throws rocks 3     |  3     no                |  2     no
----------------------+--------------------------+--------------------------
7] Throws razordisks  |  2     no                |  2     no
8] Petrification ray  |  3     yes               |  2     no
----------------------+--------------------------+--------------------------
9] SP drain ray       |  3     yes               |  2     no
10]Heat ray           |  1     yes               |  2     yes
----------------------+--------------------------+--------------------------
14]Breath stink cloud |  3     yes               |  4     yes
19]Shoots web         |  3     yes               |  3     no
----------------------+--------------------------+--------------------------
20]Good archer        |  2     no                |  3     no
23]Paralysis ray      |  3     yes               |  2     yes
----------------------+--------------------------+--------------------------
32]Breath sleep cloud |  3     yes               |  4     yes
33]Spit acid          |  3     no                |  3     no
----------------------+--------------------------+--------------------------
34]Shoot spines       |  3     yes               |  2     yes

 

The rules for how the AP costs were determined are: arrows and spit weapons cost 3 AP; breath weapons cost 4 AP; all others cost 2 AP. The rules for whether they can be used at melee are very simple - only ray and breath weapons can be used at melee range, plus a special exception to allow spines to be used at melee range.

 

However, there's some caveats to this. The current implementation casts petrification and sp drain ray as gaze attacks instead of rays, which is why those two have changed to not be useable at melee range. I could put them back as rays, but then I'd need to code a special exception to print "Gazes" instead of the standard message for petrification. I could also just make gaze attacks useable at melee range. Also, shoot webs is cast as a spit attack, mainly just because I wasn't sure where to put it so I dumped it into the category that left its AP unchanged.

 

Some of these changes could be simply reverted by simply altering the rules. Although regular breath weapons (fire and such) are now handled under the same ability system, they still have a separate block for the actual execution of the ability which always deducts 4 AP, so I could make 3 AP the standard cost for all breath weapons. And the only reason I picked 2 AP for rays is because I was trying to compromise between heat ray and the other rays, so I could easily change the ray AP cost to 3. Of course, doing that would mean all the ranged abilities other than thrown missiles cost 3 AP. But this isn't necessarily a bad thing, and is in fact closer to the state of affairs in original BoE.

 

If I made all those changes, I could then code a special heat ray ability separate from the generic system, specifically so that it can cost 1 AP instead of 3. Maybe "shoot webs" would also be better that way.

 

The only change I'm kinda attached to is making the thrown missile abilities all cost 2 AP and the good archer ability cost 3 AP, because this matches the PC cost for throwing missiles and shooting arrows.

 

If there's no feedback, I'll probably just go ahead and do what I outlined after the table.

Link to comment
Share on other sites

Okay, I've created the possibility to create items that boost any skill, but items that already boosted skills (strength, dexterity, or intelligence) are slightly altered as a side-effect. Their effect hasn't changed in contexts where they already had an effect, but they are now taken into account in a handful of additional contexts.

 

Strength-boosting items have the following new effects:

- Increases hit points gained on level-up

- Increases amount PCs can carry

Dexterity-boosting items have the following new effects:

- Increases hit chance in unarmed combat

Intelligence-boosting items have the following new effects:

- Increases effectiveness in a mindduel

 

Do any of these seem like too much of a change?

Link to comment
Share on other sites

Having strength-boosting items increase HP gain on levelup seems like it'd incentivise annoying micromanagement: carrying around strength items that are inferior to your other equipment, just so you can put them on when you're about to level up. In general you don't want to reward the player for doing busywork like that.

Link to comment
Share on other sites

For town wandering monsters, you get to select four monsters in each group, and the documentation claims that the game will place one of each of the first three and one or two of the fourth. However, this isn't what the game actually does. It tries to place one of each monster in the group, but it randomizes the location, and if it happens to choose a blocked location, the monster isn't placed. (This probably isn't really a problem since I think you'd expect the monsters to not be placed if it can't find space.) In addition, each time it tries to place a monster, it rolls to see if it should place one of the fourth monster in the group.

 

In other words, rather than placing one or two of the last monster, the game places between one and four inclusive. It's guaranteed to place one (provided there's space); there's a 50% chance it'll place each extra one. I think this gives a 12.5% chance of placing one, a 37.5% chance of placing two, a 37.5% chance of placing three, and a 12.5% chance of placing four.

 

The question here is: should I change the code, or the documentation?

Link to comment
Share on other sites

I vaguely remember someone reporting once that flaming weapons cause unblockable damage.

 

Technically, this was never true, though it's reasonable to think so based on observing the game itself. The truth is a bit more complicated, and relates to the assassination skill. The damage monster routine took two values specifying the amount of damage - the first was typed damage, adjusted by various things like resistances or invulnerability. The second value was special damage, which had no type, was never adjusted, and was displayed in the transcript as "+x" where x was the amount.

 

The following things used to do special damage:

  • Bonus damage from the assassination skill.
  • Bonus damage from slayer weapons.
  • Bonus damage from flaming weapons and lightning missiles.

 

I've removed this special hard-coded case and replaced it with a new damage type which is even more unblockable than unblockable damage (since it's not reduced by invulnerability). Furthermore, flaming weapons and lightning missiles now do actual unblockable damage rather than special damage, but it would be easy to switch them to doing fire damage instead.

 

Should I do this?

 

(Regardless of the answer, I plan to correct the bladbase so that flaming weapons do fire damage, but this question is relevant for converting of old scenarios upon load. At the moment, weapons that were described as "flaming" weapons in the original game are now assigned as doing unblockable damage and will instead be described as ... I think the term I used was "dark" weapons, in analogy to darkness breath weapons.)

 

Also, should this "special" damage be accessible from the "do damage" special node? I'm leaning towards "no"; besides, the same effect could be obtained by using the "affect health" node followed by the new "boom space" node and also maybe a "print small message" node.

 

...which suddenly makes me realize that the "affect" nodes should probably have a "silent/no print" option...

 

 

----------

 

 

The original game used monsters from the scenario list for the spells that summon a specific monster, like Daemon, Summon Host, Sticks to Snakes, etc. This made it possible for a scenario to alter what those spells would summon. I'm thinking it might be a good idea for these spells to use hard-coded monsters instead, so that they don't depend on the scenario, but on the other hand the ability to alter their effects is somewhat attractive (I think I was actually doing it in one now-abandoned scenario).

 

Any thoughts on this?

Link to comment
Share on other sites

I've removed this special hard-coded case and replaced it with a new damage type which is even more unblockable than unblockable damage (since it's not reduced by invulnerability). Furthermore, flaming weapons and lightning missiles now do actual unblockable damage rather than special damage, but it would be easy to switch them to doing fire damage instead.

 

Should I do this?

 

Good question. I'm pretty sure that flaming weapons did actual fire damage in earlier Exile games, so it's not clear whether we're looking at a bug or a deliberate change for BoE. I'm still generally in favour of leaving existing scenarios as-is to the greatest extent possible, though. I think correcting the bladbase but preserving legacy behaviour for older scenarios is the right way to go.

 

Also, should this "special" damage be accessible from the "do damage" special node? I'm leaning towards "no"; besides, the same effect could be obtained by using the "affect health" node followed by the new "boom space" node and also maybe a "print small message" node.

 

I don't see a reason not to allow it. If nothing else, it makes sense to keep the numbering of the damage types consistent between different nodes, and I can definitely see possible applications for doing that damage type with a Hit Space or Explosion on Space node (where it might affect enemies, including invulnerable ones, as well as party members).

 

Also, unless my memory's shot there's actually a pretty significant difference between Do Damage and Affect Health, in that Affect Health can't ever kill you even if you're at 0 HP.

 

The original game used monsters from the scenario list for the spells that summon a specific monster, like Daemon, Summon Host, Sticks to Snakes, etc. This made it possible for a scenario to alter what those spells would summon. I'm thinking it might be a good idea for these spells to use hard-coded monsters instead, so that they don't depend on the scenario, but on the other hand the ability to alter their effects is somewhat attractive (I think I was actually doing it in one now-abandoned scenario).

 

Any thoughts on this?

 

There are existing scenarios where people have deliberately altered those summonable monsters to fit the flavour of the scenario, but on the other hand there are also scenarios that altered them unknowingly, resulting in summons that are underpowered or overpowered. Assuming that legacy behaviour will be preserved in either case, my vote would be to keep the special summons editable but mark them in some way in the monster list to make it obvious to the user that they're special.

Link to comment
Share on other sites

Simple boom animations are currently not drawn outdoors, for example when stepping on lava or taking poison damage. This appears to be the case in the original code as well, but I seem to recall it not being the case in Exile III. Am I imagining things here? (Well, I could probably actually try it out, since I have Exile III on my Windows computer.)

 

Also, unless my memory's shot there's actually a pretty significant difference between Do Damage and Affect Health, in that Affect Health can't ever kill you even if you're at 0 HP.

Ah, now that you mention it, I think you might be right. Certainly that's the case as of right now - Affect Health currently never reduces HP below 0 or above max.

 

There are existing scenarios where people have deliberately altered those summonable monsters to fit the flavour of the scenario, but on the other hand there are also scenarios that altered them unknowingly, resulting in summons that are underpowered or overpowered. Assuming that legacy behaviour will be preserved in either case, my vote would be to keep the special summons editable but mark them in some way in the monster list to make it obvious to the user that they're special.

Hmm. I was thinking about having some sort of deliberate summons customization system in the editor, where you bring up a dialog and specify which monster is summoned by each of those spells, but I think for the purposes of preserving legacy behaviour it'd probably be easier to just alter the monster dialog to add something along the lines of "This monster is summoned by the following spells:". It would fit better in the monster abilities dialog (where you also set summon type for the general summoning spells), though it's likely better to put it in the main dialog where it'll be more noticeable.
Link to comment
Share on other sites

So, I just noticed that fields and barriers do less damage in combat mode than they do in town mode.

 

  • Fire wall: 1d6+1 in combat, 2d6+1 in town
  • Force wall: 2d6+1 in combat, 3d6 in town
  • Ice wall: 2d6 in combat, 3d6 in town
  • Blade wall: 4d8 in combat, 6d8 in town
  • Quickfire: This one is the same, 2d8 both in town and in combat
  • Stinking cloud: 2-3 in combat, 1-2 in town
  • Sleep cloud: This one is the same, adding a flat 3 levels of sleep
  • Fire barrier: 2d10 in combat... and wait, they do no damage in town? I don't think that's original behaviour?

 

Aside from the fire barrier, do you think I should do anything about this discrepancy?

 

EDIT: It looks like the two cloud types are actually processed twice in town mode, the first time being as if in combat. So in fact, in town mode, you get 6 levels of sleep or 2d2+1 levels of curse. There's one other quirk here in that the town-mode code calls the same function that places the cloud, so in combat I think you'd get the same result as in town if you're on the space when it was placed there.

 

 

Also, any thoughts about the town wandering monsters thing a few posts up?

Link to comment
Share on other sites

Well, field damage is handled in at least two completely different places. One of those places prints a message and then applies damage only if in combat mode for walls (for clouds and fire barriers it always applies damage). The other place is never reached during combat, and applies more damage. You're right that there's also damage applied when the spell is cast; I think that's in place_spell_pattern for most of them, except for the barriers. I'll look into that. (Oh, and then there's applying field damage to monsters, which is yet another place altogether.) I don't think force barriers deal damage if you wait on their space, but I haven't tested it; it's entirely possible that I've missed it being done at some other point.

 

I've tweaked some of this, but I should probably either tweak it back or at least somehow get it back to match the legacy behaviour even if the way it gets there is a bit different.

Link to comment
Share on other sites

Back to the topic of barriers - since you brought up force barriers, I checked out what happens with them.

 

On casting in combat mode, fire barriers deal 3d6+1 damage and force barriers deal 7d6+1 damage; bizarrely, this is fire damage rather than the magic damage that fire barriers usually deal. On casting in town mode, there's no damage dealt immediately; in the case of a fire barrier, that means no damage will ever be dealt if they immediately move out of the barrier. Force barriers never deal damage once placed. If one is cast on your space, sitting in them has no effect.

 

EDIT: On an unrelated note, I might be missing something, but it appears that once a monster has cast Martyr's Shield on itself, the effect is permanent - I can't find a place in the code where it wears off.

 

EDIT2: Magic resistance does nothing to protect you from magic damage. Instead, it reduces fire and cold damage. I kinda want to change that, but... maybe it'd be better to just change the name of the effect instead?

Link to comment
Share on other sites

For some reason, I thought that the magic item shops were populated with random items of a particular treasure type. It turns out that that's wrong - all the magic item shops are populated identically, with at most 1 item of treasure type 4, 2 of treasure type 3, 3 of treasure type 2, and none of treasure type 0.

 

Was I the only one with this misconception, or was it widespread? If it was a common belief, I might change things so that the five magic item shops are populated differently such that (for example) shop #4 is better than shop #2.

Link to comment
Share on other sites

I'd love a shop that let you set a separate flag, besides treasure type, to determine what shop and how often it would appear. That way you could have an item that will ONLY appear in the magic item shop and not from mob drops. I think I tried to do that a couple times and was disappointed.

Link to comment
Share on other sites

I was planning to make shops more like in BoA so that you can put any items in a shop (rather than just consecutive ones) or even mix different types of items (like mage spells and priest spells in a single shop), so perhaps I can find a way to sneak randomness into that system as well.

 

Perhaps because of the previously mentioned misconception, I actually added a new treasure class which is meant to be used for items that should be "unique" or at least so rare that they're never a random drop (I thought magic junk shops could grab things of treasure class 0, but it seems I was wrong, because they actually use the exact same code as random drops). But even if it doesn't have any direct game effect, to me it seems nice to be able to distinguish between "monsters don't drop it because it's ridiculously common and/or useless" and "monsters don't drop it because it's ridiculously rare and/or unique". (I also added a new summon class for monsters in a similar vein, though there I don't think I was under any illusion that it would have any actual effect.)

 

Link to comment
Share on other sites

I wonder, would it be too much of a mechanical change to reimplement the magically inept trait? Currently its effect doesn't really match its name and description. (The description is: "Magically Inept characters, for some reason, resist the effects of magical items, and are unable to use them. Potions and scrolls won't work for them at all, although worn items, such as rings and armor, will have a small effect.")

 

The actual effect is that usable items of any kind (except for light sources and weapon poison) don't work for them, regardless of whether or not they're magic. The description implies it should affect worn magical items as well, but it doesn't. My intuition from the name also suggests potions should be usable, but I guess the description contradicts that. It has no effect on actually casting spells - I'm assuming this is intentional, though, as the description explicitly references magic items.

 

The effect I'd go for is still a bit nebulous, but would be something like the following. If a usable item is not magic, a magically inept character can use it. (Possibly with an exception for items that cast spells.) If a usable item is not magic, a magically inept character cannot use it at all. (Maybe add an exception for potions, but maybe not.) For magical worn items (general use abilities), treat them as if their ability strength is one lower than it actually is. For weapon abilities, don't do anything - their abilities affect the enemy, not the wielder. (Possibly make an exception for Soulsucker.)

 

-----

 

On a tangentially related note, the three usable item varieties (potions, scrolls, wands) are currently almost mechanically identical. Potions multiply their weight by the number of charges and play a drinking sound when used, and I think they're more likely to show up as random drops. Scrolls and wands are completely identical mechanically. This seems like a bit of a waste, and I would sort of like to change that somehow. Making potions usable by magically inept characters could potentially be one of those changes. Another possibility could be introducing some means to recharge wands (maybe using a talk node similar to weapon enchantments?), and thus making them not disappear when their charges hit 0.

Link to comment
Share on other sites

  • 3 months later...

I have no idea how to document the effect of setting path_type to 1... any ideas?

 

// Where place?
temp_rect = missile_origin_base;
temp_rect.offset(-8 + x2[i] + (x1[i] * t) / num_steps, -8 + y2[i] + (y1[i] * t) / num_steps);
temp_rect.offset(ul);
temp_rect.offset(current_terrain_ul);

// now adjust for different paths
if(store_missiles[i].path_type == 1)
temp_rect.offset(0, -1 * (t * (num_steps - t)) / 100);

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...