Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)

[vghetto]

Wesband is currently broken. With shops and and armor vendors throwing Lua error upon entering.

Hmm, that's disappointing. Can you give more details about the error? Please include information about era selected and other mods enabled.

I just tried it on 1.16.1. local host multiplayer. It works fine over here.

[Lord-Knightmare]

I just tried it on 1.16.1. local host multiplayer. It works fine over here.

I had 1.16.0 on this machine...let me try it with the latest 1.16.1 and see if that solves it.

[Lord-Knightmare]

Wesband is currently broken. With shops and and armor vendors throwing Lua error upon entering.

Hmm, that's disappointing. Can you give more details about the error? Please include information about era selected and other mods enabled.

I just tried it on 1.16.1. local host multiplayer. It works fine over here.

Okay, I have discerned the cause.
When I just not bother picking any era/faction/leader unit, it works just fine...but if I switch to a preferred leader and play, I get the Lua error.
Maybe faction=lock=yes to resolve this?

[vghetto]

Okay, I have discerned the cause.
When I just not bother picking any era/faction/leader unit, it works just fine...but if I switch to a preferred leader and play, I get the Lua error.
Maybe faction=lock=yes to resolve this?

Thanks! I see it now. I'll lock leader and faction selection for now.

[daniel.santos]

Thank you for all of your awesome work on this vghetto! And another thanks to Ken Oh, et. al. for making this mod in the first place. I REALLY loved it and so glad it's back and getting some fresh love!

I might have time to submit a few improvements via git, but I don't want to make any promises I can't keep!

[daniel.santos]

Hello! I've found a bug with the mutual exclusion between skirmisher and bloodlust and firststrike and I would like to know what the intention was so I can properly fix it.

Currently, you can train bloodlust 1 and then train skirmisher. This results in being locked out from upgrading bloodlust any further. The combat mechanic seems to work fine though (if this is the intention) because you still get bloodlust on your weapon when you're evade is too low for skirmisher, but once you get evade back up (taking off armor) you are endowed with skirmisher and bloodlust is removed from your weapons. It is similar for first strike, except that there's only one level of first strike, so you are at least not locked out of any future upgrades -- you will have first strike on your weapons until your evade enables skirmisher, at which point it is removed.

Is it intended that you must choose an upgrade path (skirmisher on one side and blood lust and first strike on the other) or was it intended to allow both to be trained, but blood lust and first strike be disabled when skirmisher has become active?

My guess would be that the intention is that you must choose between a heavy build (that can have blood lust and first strike) or a slight build that can have skirmisher. Can Ken Oh, or anybody else please confirm?

[Ken_Oh]

Woof, this is taking me back. I can't say for sure, but I would have to say that the first level down the road of something should lock you out of the other roads. It doesn't make sense to me that you'd be able to dip only once into a couple of them. So, yeah, your guess is probably correct.

[daniel.santos]

Thank you Ken!

Yeah, I had a little down time from my work, found out that somebody ported it to a recent version of Wesnoth and started playing it -- that led to playing with the code and... you know how it goes. I'm working on a whole new set of features.

• I've merged vghetto's single-player Weshack back into Wesband code base, so now it can be played both as multi- or single-player with the vghetto's nice enhancements!
• I've added a higher level "loot all" menu to reduce clicks as well as a "loot dungeon" option that's available once a level is cleared.
• Today I just finished adding enchant weapon/armor scrolls to help out with deeper levels (where I always have trouble surviving) -- this part changes the game mechanic, so it'll need a lot of work to balance.

I have a bunch more features I'm either working on or planning as well.

• I'm reworking the Upgrade menu to also function as a character sheet, showing all stats and skills (even the ones that are maxed)
• I would like to add to single-player a "follow the leader" option so that you can scout the dungeon with your best scout unit and have all the others follow so you don't have to do so much work to get everybody else to where the fight is/is going tobe.
• I'm reworking the spells/usables both to clean the code up and allow for spells/usables that can target enemy units. This one will take a lot of work on the AI side to get AI units to utilize them properly. Of course, once that works, I'll need to actually add offensive spells and useables.
• Finally, I would like to add some type of resurrection feature so that a game can be continued after a leader unit has been killed.
• I'm probably also going to add a way to go back up levels in case you start getting your butt kicked and need to level up more.

That's about it. I'm having fun, but now I've got paying work again, just when it started to get interesting too! Still, I'm going to try to polish off what I have working and release it in the next few days.

EDIT: Oh yeah, another goal is to refactor it to reduce the number of lines of code. I started with 76,868, but so far I've netted an addition of 700 lines. But there are a lot of places that are just waiting to be replaced with some macro that will probably shave off 10k.

[Soliton]

Hello! I've found a bug with the mutual exclusion between skirmisher and bloodlust and firststrike and I would like to know what the intention was so I can properly fix it.

Currently, you can train bloodlust 1 and then train skirmisher. This results in being locked out from upgrading bloodlust any further. The combat mechanic seems to work fine though (if this is the intention) because you still get bloodlust on your weapon when you're evade is too low for skirmisher, but once you get evade back up (taking off armor) you are endowed with skirmisher and bloodlust is removed from your weapons. It is similar for first strike, except that there's only one level of first strike, so you are at least not locked out of any future upgrades -- you will have first strike on your weapons until your evade enables skirmisher, at which point it is removed.

Is it intended that you must choose an upgrade path (skirmisher on one side and blood lust and first strike on the other) or was it intended to allow both to be trained, but blood lust and first strike be disabled when skirmisher has become active?

My guess would be that the intention is that you must choose between a heavy build (that can have blood lust and first strike) or a slight build that can have skirmisher. Can Ken Oh, or anybody else please confirm?

You're probably talking about https://github.com/virtualghetto/Wesban ... 2c60dca05b

Unfortunately the commit message is not very informative. It's a recent addition anyway so probably pick whatever makes sense to you or even revert it.

[daniel.santos]

You're probably talking about https://github.com/virtualghetto/Wesban ... 2c60dca05b

Unfortunately the commit message is not very informative. It's a recent addition anyway so probably pick whatever makes sense to you or even revert it.

Thank you, Soliton. I never got around to looking closely at all of the patches used in the port. So it seems that it originally allowed them all to be trained then. I'm seriously considering adding a game configuration and this would be a candidate option -- rather to allow training skills of opposing strategies.

When Wesband was young, you originally just chose your race and then your character evolved as you made upgrade decisions. I still like that concept and have been looking at ways to bring it back and still mesh with the current class choice system. I would have to analyze all of the class trees though, and this is the type of issue in question. Honestly, I like both solutions: you can train what you want, but you can't do them all at once vs you have to choose with career path you're going to follow.

Just for reference, and though I'm not a historian, in the old days the skirmishers were typically the youngest and poorest of citizenry who were drafted into military service. They would have a small wooden shield, but usually no armor and relied speed upon agility to harass opposing forces with missile weapons before the heavy forces engaged. They often didn't participate in melee, but when they did it was only after the heavy forces had engaged.

[daniel.santos]

Hello all!

I've been hacking away on my spare time and I feel like I should have posted a release much sooner. I've got so many changes now that sorting them out into a meaningful set of patches (which I prefer to do) is a real chore! I'm going to release this as 0.9.0 with initial support for Wesnoth 1.16, but from this point forward, I don't want any more separate releases for different versions of Wesnoth. Since we have lua functions to check the Wesnoth version, I want to have the same add-on code both older and newer versions.

This release will be almost entirely changes in "code mechanics", but there are some changes to the "game" its self. My primary aim was to make it easier to play the game and make it MUCH easier to modify it in the future! Thankfully, Wesnoth is a much more powerful game engine than it used to be and so has more capability to write add-ons with a higher maintainability score.

Code / Interface Mechanics
Weshack and Wesband United!
This combines vghetto's f**king awesome single-player Weshack with the multiplayer capability, so that it can be played as either a single- or multi-player campaign. (Most of my testing has been on single player.) I plan to expand upon this in the future so that you can:

• Always have all characters on the same side, even in the overworld
• Add an optional group "bank" that can be used in both single- and multi-player so there's less need to drop/transfer gold when shopping

Less Right-Clicking For Loot
I've added a top-level menu item to "get all items" beneath your unit. However, when not "in-combat" and moves are refreshing, the option changes to allow you to loot items beneath you as well as all that surround you. The menu item also gives you a summary of what you are picking up, e.g., "pick up 28 gold and 2 items" or "pick up a rusty axe."

Finally, once a level is cleared, a top level "loot dungeon" option comes up for the very, very, lazy!

Spells and Usable Items
Every item and spell has the boolean properties

Code: Select all

                    usable_self
                    usable_other_adj
                    usable_other_dis
                    usable_adj
                    usable_dis

Replaced with

Code: Select all

                    target
                    range_min
                    range_max

target may be friend, foe, or empty. So usable_self=1 (and the rest zero) is replaced by target=friend, range_min=0, range_max=0 while usable_self=1, usable_other_adj=1 is target=friend, range_min=0, range_max=1. This is a LOT easier to work with in code, removes a lot of annoying copy & paste, and supports spells with a longer range or that target enemies. There's an additional mechanic for spells like teleport who's max range depends upon casting power. (currently not working)

Use/Cast Menu
Owing to the above change, there is now a single "Use/Cast" menu option instead of 5 that only appear when appropriate. The Use/Cast menu now works completely with the vghetto Weshack! It shows all spells and items that every unit on your side can cast or use on the the target. If you right-click on a unit on your side, their own "self" options will appear first followed by what anybody else can do. When a unit cannot cast a spell/use an item due to a lack of sufficient actions or cast time, the item shows up in grey. (It doesn't yet grey-out spells that cannot be cast due to lack of mana.)

Every living unit on your side can now use items and cast spells. NPCs don't have correct spells yet, but that will eventually be fixed. For now I've decided that your undead minions are too dumb to use items -- also, dark adapts don't seem to be able to get minions at all right now (we'll will eventually fix that).

Added Campaign Options
There's not much here so far, only to choose between some display preferences and items for testing game balance. But other preferences can be added here in the future. I will likely add an option for playing a game where new characters only choose a race and start off as a level 0 peasant/peon/hatchling as was the case in very early versions of Wesband.

Changes to Game Mechanics
Experience, Leveling, and Talent Points
I've reverted one change from vghetto's work, and that's the change from 15% max_experience increase on leveling to 12%. The reason is that it's both too much and not enough: at higher levels you get a LOT of hit points from leveling, yet not enough talent points. I feel like I'll need a lot of help and time to find the correct balance, so I've made all of these some ugly campaign options for now. This is bad because humans will always be tempted to give themselves the max they can get, and that will make the game quickly boring.

So leveling is back to +15% max_experience, but I've added an exponential curve to talent point increase. Right now I'm testing a game with

tp_add = (1 + level) * 4 * (1 + real_level / 24)

Where

• tp_add is the new talent points gained, originally (1 + level) * 4
• level is the traditional Wesband level (you get one for every 5 sub-levels), and
• real_level is the actual number of times your PC character has leveled

While it looks like it might be right for higher levels, it's too much for lower levels, so it'll need more work and feedback after others have played it for a bit.

New Armor Mechanic
Having played down into dungeon level 30+, I had some characters with 100+ resistance to certain damage types. This meant that I was no longer seeking to improve their armor. As such I've changed the whole armor mechanic. Previously, the base resistance value was added to that of the head, torso, and legs. The new code will add them together until the resistance value reaches 10, then the remaining values are inverted (into a vulnerability score) and multiplied together such that you'll never reach 100% unless a single armor item has 100%. (So 5% and 12% would be combined as 100% - 95% * 88% = 16.4% instead of 5% + 12 + = 17%.)

For a more complete example, if your base blade resistance is -20% and your head, torso and legs respectively add 6%, 25%, and 12%, you end up with 22% instead of 23% -- a very small difference! But with 29%, 65%, and 47%, you end up with a resistance of 80% instead of 121%. So this works out quite nicely to keep the game in balance and interesting at higher levels with a minimal effect at lower levels.

New scrolls: Enchant Weapon, Enchant Item
As you delve deeper into the dungeon you will start encountering scrolls to enchant weapons and armor. I've modified the probability list code in order to provide for more variations (like items not showing up until you're deeper into the dungeon). This adds an interesting new game mechanic that, so far, seems to be in balance. The reward is more powerful items, but the cost is their rarity, high price in the magic shop when you do find them, and the fact that whatever items you use it on will eventually become obsolete as you advance in levels.

For weapons, they can, in order or probability:

• increase damage, or strikes
• change damage type to fire or cold,
• increase chance_to_hit, add firststrike/readied bolt, or poison
• change damage type to arcane or add slow
• add magical
• add drains

For armor:

• add to fire, cold, or arcane,
• add to blade, pierce, or impact,
• decrease magic_adjust penalty, even adding a bonus,
• decrease evade_adjust penalty, possibly adding a bonus

Weapon enchantment still needs a chance to increase the magical bonus for mage staves, and runic hammers, and there are there are many more possibilities. All specials differ from the "allow" specials as they don't require the unit to have the underlying skill. I would like to have a rare special that has a chance of granting an extra attack after an attack is made (but only after exhausting bloodlust, remaining ammo so that it applies evenly to different classes).

Armor enchantment needs a tiny bit more tinkering. You can currently only ever get +1% to evade, which should probably be increased for clunky armor to at least 30%. In the future, I would like to add additional rare armor specials that decrease move cost for specific terrain, camouflage (unit is hidden if at least n hexes from from enemies), heals +2 per round, etc. There's a lot to work with here that can make the game more fun.

In all cases, additional uses of enchant scrolls have decreasing returns and will eventually fail if used too many times on an item. Using a higher level enchant scroll after having previously enchanted with a lower one yields a lower penalty, but the inverse is likely to fail and waste your scroll. It would probably also be nice to have enchant scrolls that will confer a specific benefit instead of the random choice.

(Enchanted properties don't yet show up correctly when the item is viewed in store(fixed), pick up items, and drop items.)


That's the bulk of it. I'll try to get this released within the next week. I have a list with a TON of things I would like to add, but I now need to focus on fixing my out-standing bugs and getting this release out.

[daniel.santos]

I'm getting really close! I've now also fixed the performance problems when in the weapons shop, or dropping, picking up, or giving weapons. For anybody interested in checking it out now, you can grab it from my git repo, although I don't have a proper branch just yet, you can check it out into your add-ons directory using a work-in-progress tag I've recently pushed.

You'll need to first remove Wesband if you already have it installed. I haven't used Windows in a long time, so I'm sorry that I can't give instructions for checking it out from git there, but for Linux, Cygwin/Mingw or Mac, you can do this:

Code: Select all

# Replace with the appropriate path for your system
cd .config/wesnoth-1.16/data/add-ons
git clone https://github.com/daniel-santos/Wesband.git -b wip-20231031

I have the formulas for calculating talent point increases for NPCs and PCs in the campaign config; you probably don't want to touch that -- just ignore it. Also, don't use the "peons" setting, that isn't finished yet.

Honestly, I did a little more improvement work instead of just clean-up to get it ready for release, but the performance issue with displaying many weapons was starting to bug me. A great deal of thanks goes to Celtic Minstrel for their help with various technical challenges.

A few notes on changes:
Changed PC talent points formula to a polynomial that seems to work pretty well. When I finally release, I'll post a little table showing what that amounts to.

tp_add = (1 + level) * (4 + (real_level - 2) * (real_level - 3) / 192)

I've also altered NPC leveling fairly significantly. They no longer have a 150 max_experience cap, so they will level slower. However, instead of just adding 50 talent points each level, they get 25 + level * 25, so basically 50, 75, 100, 125, etc. The only thing they may lack at higher levels if sufficient hit points -- I'll need to check up on that. This affects all NPCs, not just henchmen.

Oh, and there's an option to manually upgrade your own henchmen in the campaign options.

[daniel.santos]

I've finally released Wesband 0.9.0, but since I changed it from an MP to hybrid campaign, I was unfortunately required to rename it. So it has been released as "Wesband Evolved". Honestly, I would have preferred to keep the original name, but oh well.

I'll list the full change log either this weekend or in a few days, as RL is bothering me again.

[daniel.santos]

Looks like we've solved the problem with the add-on situation, so this will retain the original "Wesband" name and the 0.9.0 is now available! I'm going to ask that "Wesband Evolution" be removed.

For the next release, I've fixed an annoying problem -- having moves stop refreshing (i.e., being considered "in-combat") when there are mobs on the other side of a wall and you can't reach each other for some time. From now on, this only triggers when either a player or enemy is within 8 moves of each other. This takes into account terrain and move costs.

However, I'm working on a new ambush mechanic. Hidden units within that range will not trigger combat unless they are set up as a "lookout." If they set up for an ambush, they will remain silent until you discover a visible unit on their side or you run into them.