2weaponfighting and offhand assigned experience

[zoom]

How would two weapon fighting work in dsb.I just cannot imagine it
Is it like DM2?
then, can you tell dsb that it should increase a
general ninja experience each time the offhand
is used to attack ?(even if you would chop or swing,
that is , normally increase fighter level only)
[my aim would be to have the second sword be dependent on ninja
experience as well as fighter exp]
fact is I do not know very much about dsb, but I want to get an idea,
so sorry to propose or ask things that do not help much or are
a bit out of the way...

[zoom]

hello?
can someone please explain how it works in dsb?

I would really like to know.
Should I look in
the game itself?
the documentation?

would it be so customizable that it is hard to tell,
because it is virtually not standardised?
the experience thingdoes not matter, btw..

[beowuuf]

At the moment DSB works as DM so if there are probably no hooks for a second set of attack icons, I don't know though

[Sophia]

If you mean two handed fighting like DM2, where you can invoke an attack method for the left hand item-- though the engine itself supports invoking an attack method from any item in any inventory slot, the gui doesn't.

DSB does, however, support weapons held in two hands

[zoom]

thanks!
good question , what I mean..I do not really know. I am undecided about
what would be cool and sensible for the future?
I tried to arrange it , but it is probably become a mess....

we had the discussion about dual wield and 2h wield. Now the player just
does not have a "button" for an attack method from any item in
any inventory slot

you obviously have to change the gui, maybe to resemble s.th. alike dm2
Or is there maybe other possiblilities for gui change?


0)(change is probably inevitable)

I was pondering about having just one attack option slider for each
champion like in original dm.

now some brainstorming>
A)flip left right hand. gives 2 times 3 options .
B1)folder for fighter methods , ninja methods and a general (standard) one,
then one for special slots in inventory/misc method slot.
B2)this way you could introduce a talk to shopkeeper system as well.

C)dual wield > doubtless a much desired feature.

C1)holding two "compatible attack method" weapons enhance/alter the attack options
(I would not vote for a dual wield of any combination of weapons...)
B1)a master ninja could always kick or punch, even with a weapon in hand.
(add kick punch and why not warcry to the attack methods. Why does
a champion lose the ability to warcry when she is holding a weapon in hand?
01)just because of the 3 attack methods at a time restriction, I guess.
Would it become awkward to use if you had to scroll up and down ?
Would it be good to have 6 + methods and have the engine display the most frequent
ones on top and the not often used out of screen?
Would a slider be cool in that regard?
Would the possibility to rearrange/assemble the attack methods or
build methods for each champion in game be desired?
could wearing a necklace or ring add attack methods ?
e.g. lighting
z)casting vi bro into a flask... mark some inventory slots where you put empty flasks or
ingredients to automatically put flask in hand and drop weapon or switch weapon or
just cast it into the inventory. Automatically drink potiiiion out of inventory.
this leads too far away from the mouth feeding atmosphere of dm and would destroy the game.

(if you would not prefer a dm2 style gui)

Example>
short sword left hand , long sword right hand

normally , the short sword would not do anything .

all attacks originate from the long sword slot, the action hand or call it right hand

when I put a short sword in the left hand, and it has a dual wield and main weapon compatible attack,like stab or swing, I could tell the action dialogue of the long sword
do not display parry swing chop but doubleswing crossparry stabandchop
or
just interpolate/extrapolate/mirror the selected and executed attack method onto the offhand.
When you click on berserk and the offhand weapon has that option as well,
then grey that one out as well. do 2 attacks.
You could make the duration of the second
mirror attack a bit less long or longer! and decrease damage or increase it!

[Sophia]

I'll admit this: for me, adding the support to the engine for left-handed (or whatever) attack methods was the easy part. I'm not a huge fan of the DM2 gui, and I couldn't really think of a way to present the attack methods in a way that would be nice for the player.

Some thoughts:

Right clicking the normal attack icons is one option. It requires no change to the graphics. However, it's a little clunky.
I suppose I could also put the left handed attack method immediately above or below the right handed one-- there's enough space in those rather tall cyan boxes for that, too. That would of course "hardcode" the attack methods to two, though, right now, it's only one, so it'd still be something of an improvement?
A third option is to use that unused row of pixels above the attack methods and make a sort of "hand switcher" or other attack method "tab," where the hands could be switched-- or whatever body part was assigned an attack method.

Of course, the most outlandish option is a completely reconfigurable and scriptable gui, but don't hold your breath on that one. It's something that I'm interested in, it's also a lot of work and I'm not sure how much it'd actually get used... it seems there's quite a bit of things like that.

On the topic of two-handed fighting without directly invoking attack methods from the left hand, DSB already supports most of this. It can certainly do what you outlined in your example. The attack methods for the long sword in the right hand can be specified as a function returning a table, rather than a table directly. So, that means, in this function, the left hand can be queried and an appropriate table of methods generated. For example:

Code: Select all

function two_handed_sword(id)
	local type, owner, hand = dsb_get_coords(id)
	local lefthand = dsb_fetch(CHARACTER, owner, INV_L_HAND, 0)
	local left_arch = dsb_find_arch(lefthand)
	
	if (left_arch == obj.short_sword)
		return two_sword_methods
	else
		return normal_methods	
	end
end

obj.long_sword.methods = two_handed_sword

[zoom]

ahh, know I see.
that would be function dual_wield_sword(id) I guess but that does not matter right know ,you get the idea more or less across.

right clicking the attack options is dangerous. I dont know what you mean with
clunky-awkward to use?
anyway,it could interfere with the switching to inventory, which should,
imho be priority to stay untouched.

a tab or tabs should please be taken into consideration.
That was what I meant by talk to "shopkeeper" method .****

the standard tab would be as is right now /the attack methods or actions tab.

chances are that a combination of left and right hand there to be a good idea.
example>

Code: Select all

primary hand      <--//--> secondary hand
selected hand is 3/4th of total bar//not selected is 1/4th space
----------------------------------------------
|    SWING  [3/4th]          //  CHOP       | bar one
----------------------------------------------
|     PARRY//      [3/4th] CLEAVE           | bar two
----------------------------------------------
|1/8th //   NORMAL ATTACK         //   | bar three
---------------------------------------------
STANDARD ATTACKS ARE DISPLAYED 
IN THE MIDDLE AS USUAL, BUT 1/8TH
OF THE BAR IS LEFT BLANK AT EACH
OF THE SIDES

this way you could notice the greyed out attack methods for each weapon
and switch albeit with an extra click back and forth.
normal attacks as like in odm stay the same, but have slightly less space
at the edges of the corresponding bar because of looks ..

also , there should be a way/checkbox whether to actially use dual wield ..
maybe in inventory screen...

****
second tab > special slots(assigned in inventory to be displayed there)
maybe not needed with above split screen like method?
You could , however add another tab for >
search /identify / listen or perception /sneak/ push&pull/ greet/barter/talk/combine items/hide/use item/repair......

its just brainstorming again..do not care about how it would be done, just
what would be cool as first thoughts
(in the end, it could all be less apt,when you realise it is too much work
or just really not that cool).

Code: Select all

tab one                 // tab 2 // tab 3

tabs, obviously would look like the magic tab thing , just that the different champions (champion 2/3)would be the tab 2 or tab 3.

would be huge amount of work be very different from odm and will it be fun to play?

[Sophia]

would be huge amount of work be very different from odm and will it be fun to play?

To me, that's the big mystery.
It's quite different from ODM. It would be quite a bit of work. And, really, it would be horrible if after going through all that, it turned out to not even be very much fun.

It seems the opinions on being able to use attack methods from both hands (like in DM2) are kind of mixed anyway.

[zoom]

after thinking about the previous dsb code example it does sound
like a good idea to alter the attack methods of the primary hand depending
on the secondary hand.
so changing the gui can be circumvented.

so then I would suggest to>

give medium weapons a bonus to a vacant left hand ,

when you look at how a weapon is handled , sometimes one handed style
uses the second hand for some support..stabilize /accelerate/ add some punch to the hit etc
depending maybe on fighter level

for small weapons no change .(no malus when left hand is occupied)
there could be , however a possible bonus when using another small weapon
in the other hand...double dagger wield - cross slice attack or whatever..

then of course make a vacant/free left hand a prerequisite for large weapon usage
(2H wield only possible with 2 hands),Probably make an exception for shields.
This is balancing then..

change attack methods for dual weapon style / like in the dsb code example
(short sword/small weapon and long sword/medium weapon,
or two medium weapons or two small weapons)

weapon /Item descriptions should display some info about the different ways to use them.


questions>
how would I introduce a sheathe of poison?
that item would grant poison attack bonus to each weapon that is sharp..

should it be put in the left hand and had I to tell each and every weapon out there
that if left hand > poison sheathe then use poison bonus attacks. else normal attacks
I can imagine that you could do s.th. with archetypes there? Or can I assign to
the poison sheathe that if placed on right spot(left hand or pouchbag ) add bonus..?

COULD YOU/WE ADD EXTRA SUBSKILL(S) ?
LIKE a DUAL WIELD > new fighter subskill??
or should dual wield ability be just be assigned to the standard fighter skill?
is it possible to have a subskills for ninja and fighter?
(I cannot decide whether dual wield is fighter or ninja.)
in that regard how about a wizard / ninja dualskill..??.
same for priest wizard, .--->powercasting comes to mind..

How about adding a collect button within the ranged weapons methods(bow)?
SHOOT
COLLECT
RAPID SHOT
collect action would put arrows right into the pouch in inventory when some are
lying on the floor in front of party...
maybe then use of ranged weapons would be more fluent?

[Remy]

As far as a Poison Shealth, there are a few ways you could do it depending on what exactly you want it to do. Probably the quickest (and dirtiest) way to do it is to override the 'method_physattack' method (originally found in base/methods.lua) with a method that also checks for the Poison Shealth and applies a bonus to damage if it's in the right spot (Left Hand or wherever). Using this method automatically ties it to most standard weapon attacks (though, that may include some you don't want it to work for).

The number of subskills (and classes, for that matter) seem to be hardcoded into the DSBengine (at least, in the very rudimentary test I just ran, DSB crashes every time I tried to adjust any subskill numbered '5'), so designers can't add subskills that easily. One way it might be done is with exvars, but you'd have to script new methods for handling experience, and I'm still not sure if it would work (I don't quite know how the dsb_* functions compute experience level, for example).
The easy, dirty way is to hijack a subskill that doesn't get used for anything (or anything important). You could use the Ninja subskill 'CLIMBING' for 'DUAL_WIELD' instead. You'd have to change the methods attached to the Rope archtype so that it doesn't give you any experience, and then write new methods for anything that does add to DUAL_WIELD (but since you'd have to write methods for dual wielding weapons anyway, this isn't a big deal).
As far as a subskill that applies to two Classes (such as Wizard/Ninja), I can't imagine a situation where that would be remotely useful. What would you want it to do, or rather, what would you want it to be for?

A Collect method can easily be scripted for a bow (at least, I think it can) - you'd just use 'dsb_fetch' and run through the returned table and move any Arrow archtyped instances to the character's inventory. That's actually a pretty nifty idea. I'll see if I can't put together a method.

[Sophia]

the quickest (and dirtiest) way to do it is to override the 'method_physattack' method

Oh, this is definitely dirty. I've tried to include hooks in this function to things that designers might want to do differently from the stock version, and if a new hook is needed, I will be happy to add it. I think it would save a lot of headaches-- both for me and for anyone who wants to make changes to attack methods.

The number of subskills (and classes, for that matter) seem to be hardcoded into the DSBengine (at least, in the very rudimentary test I just ran, DSB crashes every time I tried to adjust any subskill numbered '5'), so designers can't add subskills that easily.

This is one of those things that I wasn't sure if anyone even wanted to do. I can add this capability. It's definitely quite doable for subskills. Adding actual classes could run into some GUI issues, given that the default system only has space for four...

I don't quite know how the dsb_* functions compute experience level

The same way DM does. The xp level for the base skill and the subskill are added and averaged, and then the resulting experience is compared to the amounts in the xp_levelamounts table (defined in base/global.lua) to get the level.

As far as a subskill that applies to two Classes (such as Wizard/Ninja), I can't imagine a situation where that would be remotely useful.

I can't either, and this would be much more difficult to do.

move any Arrow archtyped instances to the character's inventory

I'd check if arch.missile_type == MISSILE_ARROW instead. That way you'll also pick up slayers and any new types of arrows that someone may create.

[Remy]

I'd check if arch.missile_type == MISSILE_ARROW instead. That way you'll also pick up slayers and any new types of arrows that someone may create.

Good idea - I expanded it a bit to do a compare between 'need_ammo_type' and 'missile_type' so that it could fit with any projectile shooters, both current and expanded.

Here's the code:

Code: Select all

function method_collect_ammo(name, ppos, who, what)
  local z = dsb_find_arch(what)
  local lev, x, y, face = dsb_party_coords()
  local pickup_count = 0	
  for j=0,3 do
    local stuff, stuff_count = dsb_fetch(lev, x, y, j)
    if (stuff_count) then
      for i=1,stuff_count do
        if (dsb_fetch(CHARACTER, who, INV_L_HAND, 0)) then
           slot = INV_QUIVER
        else
           slot = INV_L_HAND
        end
        while(dsb_fetch(CHARACTER, who, slot, 0)) do
           slot = slot + 1
        end
        if (slot < 13) then
           local y = dsb_find_arch(stuff[i])
        if (y.missile_type == z.need_ammo_type) then
           dsb_move(stuff[i], CHARACTER, who, slot, 0)
           pickup_count = pickup_count + 1
        end
      end
     end
    end
   end
  dsb_set_idle(ppos, pickup_count * 5)
end

shoot_method = {
	{ "SHOOT", 0, CLASS_NINJA, method_shoot_ammo },
	{ "COLLECT AMMO", 0, CLASS_NINJA, method_collect_ammo}
}

Add that to the end of 'startup.lua' in 'test_dungeon' (or any dungeon), and it should be good to go. It goes through all the items on the square the character party is standing on and adds any ammo associated with the weapon that calls 'COLLECT AMMO' to the left hand and then the quiver.
I only have it collect from the square the party is on to prevent the script from grabbing items on a square that it shouldn't (such as missiles that are currently sticking in or part of the inventory of a monster, or behind a door). It stops collecting if the quiver and left hand are full to help curb it's desire to take every piece of applicable ammo that it can, including, perhaps, another party member's.
The code isn't perfect (forgive me, I'm new to Lua) - the 'for' loops could probably be cleaner and there's probably a faster way to do the slot sorting, but it works.
The last bit overrides the 'shoot_method' definition with one that includes Collect Ammo so that it applies to all weapons that use that method. CLASS_NINJA can be ignored, since it doesn't actually add any experience.

I've tried to include hooks in this function to things that designers might want to do

I actually haven't really look at the function in detail, other than knowing it's rather big and it's used by almost everything, so there's probably a hook in that I didn't see.

The same way DM does. The xp level for the base skill and the subskill are added and averaged, and then the resulting experience is compared to the amounts in the xp_levelamounts table (defined in base/global.lua) to get the level.

If DSB keeps an experience point total for each Class (seperate from the subskills of each Class - in other words, there are five values stored in memory, 4 for the subskills and one for the Class total), then the exvars idea could work - everytime you add to the exvars subskill experience points, you add to the base Class experience points, too, with a proper function call to include a level_up check.
But, if the DSBengine opens up the available number of subskills, then it's all really acedemic.

[Joramun]

1/ Your function is ok...This could be adapted for all throwable weapons, too !

2/ The best shot here is the function m.special_effect associated to an attack method... You can override it for each method and do basically whatever you want with the attack / the monster !

3/ I never really liked that way of calculating the xp : it means extending (the subkills somewhat change the xp balance, and of course a class that has 4 useful subskills will be more powerful than a class that has useless subskills ( ninja anyone ? )

Basically, your actual action xp is : ( 2*used_subskill + other_3 ) / 2
So the used subskill roughly counts as 2/5 of the result for a balanced class, but an unbalanced class will have it counting for half or more in the result (if the other 3 are low).
Adding subskills will somewhat decrease the impact of the used subskill in the result, which is not "realistic".
There is also the problem of leveling : a lot of subskills will overall progress slower than a smaller set,
on the other hand, since the class xp is the sum of subskills, a class with a large number of "useful" subskills will progress much faster.

[Remy]

Yeah, that script could be adapted to throwables quite easily. Change INV_L_HAND to INV_R_HAND and the last if-statement condition to '(y.class == "MISSILE")' and it'll work. Well, then you'd have to attach it to the method list for the empty hand (and probably throwable items, so the character doesn't have to wait until he's out of ammo to collect some). It might cause some headaches with picking up other people's ammo (arrows and rocks are considered MISSILEs), and occasionally junk (particularly after a big battle with rockpiles - your quivers would be filled with rocks...Yay), but that's a designer's call.

[zoom]

hmm,
maybe prevent from getting more than one arrow or missile at a time(clicking on grab arrow command) , make the collect missile command rather fast...

and, only get the topmost thing in front.
choose side of checking for arrow depending on
character position.
can be right and left. Then , if right , check for right. get arrow if there is one , then check right again, if there is no arrow, then check left. continue until you move or both sides yield no arrows. or click every time you want to get arrow.

somehow lets me think about autofire mode . continous attack mode. but that is another story..

[Remy]

One at a time? That would be no different than using the mouse to grab an arrow of the ground, and putting it in the left hand. wouldn't it?
The Collect command delay is based on the number of items picked up. If you pick up none, no delay. Pick up five, a delay of 25. You can change the last line of the function (or remove it) to speed it up.

I'm not sure what you mean by 'topmost'; if you mean the first arrow you'd pick up if you clicked a pile of them with the mouse, you can't progammically check for that (at least, I don't know of a way you can). If you mean the farthest away you can reach with the mouse, that's actually the square in front of the party, and I explained above why I avoided allowing grabbing arrows from any location but the one the party is standing on.
Side-checking is also complicated, and largely irrelevant. Chances are, after combat, with both the player and the monsters running around each other, fleeing, turning, and such, it's only 50/50 the missiles a particular character fired are going to be on the same side of the screen as they are when the monster finally dies, so it doesn't matter where they get the arrows from.
Continuous arrow collection is probably beyond the scope of my DSB scripting skills at the moment, and it doesn't make much sense. Firing an arrow at a target generally means the target is some distance away - the character couldn't reach the arrows anyway. Also, most monsters keep projectiles fired at them until they die, so the character shouldn't be allowed to pick them up ("Excuse me Mr. Trolin, can I have my arrow back so I can shoot you with it again?").
It's one of the reasons I added the delay in the first place - I didn't want to create a super-killing method. The purpose is merely convience, so the player doesn't have to keep switching between the inventory screen and the viewport just to collect ammo. But feel free to modify the script however you want.

[zoom]

one at a timewould surely make a difference on convenience

if

the one was put into inventory by just one click(grab arrow method )
and not by 4 clicks as it is now .
click on arrow/to get it in hand, maybe even get rid of the thing in cursor first
right click to reach inv. , maybe need to move cursor over shooting champion's portrait bcs leader is different champion than arching champion
click on pouch inventory spot, here you can decide where to put it..
right click to switch back from inventory screen

concerning just the left hand it does not make much difference,
but you still have the distance you travel with the mouse...that adds up imo.
also you can hold s.th. in the cursor while doing so..

anyway concerning the left hand ,you could always do as it works in the original dm

All in all i do not want to complain.

I am not the programming freak here, so I cannot discuss details,
just bring in my, albeit sometimes silly suggestions.
What is doable and what not I cannot easily see.
Hope nobody minds

with topmost I meant top of the stack/ item pile right at the party spot
as for side checking ,somewhere you have to tell the program to start?
I mean there is a difference in game concerning left side , right side?
or north , east,south, west while party only faces two out of them(e.g.North and East)
therefore I thought side to matter .
But you I guess, kind of circumvent that with party position :facing..

[Sophia]

Also, most monsters keep projectiles fired at them until they die, so the character shouldn't be allowed to pick them up ("Excuse me Mr. Trolin, can I have my arrow back so I can shoot you with it again?").

I would like to clarify here that the real problem isn't with projectiles that are "stuck" in the monster (those would show up with a location IN_OBJ of the monster they're stuck in, and would not be retrieved by dsb_fetch) but rather the ones that are lying at the monster's feet. Projectiles at the monster's feet are still in the dungeon, and can be picked up after the monster dies or moves, but not until then, so a script that automatically grabs things out of the square in front without regard for this limitation could be used for naughtiness.

[zoom]

so only grab items from the tile the party is standing on.
i am not so sure anymore about whether there is a space in front of the party that is
not the monster's tile in front of the party?
what about alcoves?

[zoom]

I have the fear that dsb gets xp wrong!!

subskills:

I believe a subskill can have a bigger xp set than the actual main class skill.
on rare occasions.
so you could set the lightning skill to level 4 and have the main class wizard skill
at level 0!!
check the encyclopaedia on that or gambit's old site, where you see dm champions
and their hidden subskill levels

to prattle on >
each use of a subskill adds xp to the subskill and the main skill
each use of the main skill only yields main skill xp

joramund>

it does not matter when you have one subskill that is not used.

well, ok , flip coin is one exception, it gives 0 xp, but then again, how often
do you use that?

the total xp value (all subskills and the main class skill )will be lower in flip coin case
but you only miss out on one subskill xp that is not used
not on the main skill xp.

normally ,in the end almost always will the main skill be higher than any associated subskill.(you use not only one subskill but four and some actions only give xp to the
main skill)
there is no total xp ( main and subskill xp ) and does not matter I think. What for?

You only have some subskills that are relevant(like fighter subskills for chop berserk and so on). and main skill (class skill which is relevant for getting health and so on and displaying the level and like some subskills for the attack methods available)

hidden skill >(greater than) main skill
in that case your lucky champion may use e.g. melee command early,
i.e.even when the corresponding fighter level main skill xp prerequisite is not met yet.
(she normally would not be able to use melee with just the main class skill level)
(hidden skill has met prerequisite for melee, main skill did not)

on the other hand , a fighter that never got xp for the berserk action subskill, could
at a given fighter main class skill of 9? use the berserk attack method.
then using berserk would get hidden skill xp and main skill xp.

hope you could follow!!