Parry Branch from Multiple Skills?

[IAmJacksOpinion]

Seriously, why do I need to branch parry from dual wield? Couldn't I just as easily learn to put my sword in the way of someone elses if I was only EPing? Or even ETWOing?

As it currently stands non-warrior guilds are give two options:

A) Use a shield to provide defense, and never learn the parry.
B) Run around Dual Wielding and hope you survive the 15-20 days you need to branch.

Preferably, I would like to see it added to be branchable from general offense.

I guess I could understand not learning to parry while you're using a shield (why distract your killing hand to defend yourself when there's a perfectly good shield handy), but at the very least it could be added to Etwo as well?

Or maybe I'm talking out of my ass and it already is?

Thoughts? Clarifications?

[Synthesis]

Morgenes has already said that if you are good enough with two-handed, they will manually branch parry for you.

All you have to do is send in a request via the request tool when you think you're good enough with the skill.

Apparently, in the current version of the game, it isn't possible to code a skill tree such that a particular skill can potentially branch from two different base skills.

Also:

Skill Dual Wield                                                   (Combat)

   This automatically-used skill is invoked whenever your character fights
with a weapon in his/her secondary hand (see "help es"). It represents your
character's proficiency in fighting with two weapons.

Notes:
   It is somewhat easier to parry using two weapons.

   No shield can be employed when using two weapons, and your character is
thus somewhat easier to hit.

See also:
   skill parry


From this, it is reasonable to infer that if you ep a shield and es a weapon, your dual wield skill will improve.

[Ourla]

It smells twinky in here.

[Riev]

*sniff sniff*

Do you guys smell that?

....

*sniff*

Smells like closed thread.

[Synthesis]

Why the fuck would they lock a thread for quoting an Imm and a helpfile?

[Thunkkin]

Why the fuck would they lock a thread for quoting an Imm and a helpfile?

Actually, I think it's important that etwo-ers know about this:

http://www.zalanthas.org/gdb/index.php/topic,30295.msg358874.html#msg358874

http://www.zalanthas.org/gdb/index.php/topic,30290.0.html

[FantasyWriter]

I don't feel like looking it up, but Morg said that they tried making it where it would also branch off etwo and shield use, but it was possible to do with the current code.
If you feel that you have gained a sufficient level in one of those skills, email your clan staff CCing Morg and they'll take a look at it and give you parry if the skill you are 'branching from" is high enough.

Edited to add: oops.. thanks thunkkin

[IAmJacksOpinion]

Woop! Sorry, I guess it does say that after all.

In that case I apologize for not reading every post from every threat. Ever.

Alright then, should that be added to the helpfile somewhere, you think, to help avoid another stupid chump like myself from making this mistake?

[Salt Merchant]

Why not set up the code to check etwo skill level upon login and have it automatically email the staff and player when the skill level is high enough?

This could conceivably be done for merchants that have just achieved master crafter status as well.

[Dalmeth]

Because it's just frikking irritating to track a character down at any given time.

[Salt Merchant]

Because it's just frikking irritating to track a character down at any given time.

What are you replying to here?

If it's about automatically emailing the player when his skill gets high enough, then at least he won't have to guess when the skill is high enough and risk sending in requests that are only a waste of time for everyone. Sounds like less irritation to me, not more.

And the staff should be cc'd on the automatically generated email to verify and in case they're feeling proactive.

In fact, maybe the request itself should be generated automatically, if that's possible.

[Xygax]

If we were going to write code to automatically notify you when you should have a new skill branched, why wouldn't we just write the code to cause the skill to branch?  I'm so confused.

-- X

[Sephiroto]

If we were going to write code to automatically notify you when you should have a new skill branched, why wouldn't we just write the code to cause the skill to branch?  I'm so confused.

-- X

I was just about say this too.

[Armaddict]

Xygax:

I think what he means is that since you can't have code that says "This skill OR this skill OR this skill reaching this point WILL BRANCH this skill", maybe those other two skills could have it coded to notify you when they have reached that certain level so that action can be taken without you having to do guesswork and bother the staff to check on it.

[Salt Merchant]

If we were going to write code to automatically notify you when you should have a new skill branched, why wouldn't we just write the code to cause the skill to branch?  I'm so confused.

-- X

Why not indeed?

But the point here is to not try to use the branching code as it stands, which (presumably) checks every time the relevant skill ticks up. Instead, it would be a log on check, implemented separately and not modifying anything, so as not disturb the branching code that can't be modified to work off of more than one skill.

[Xygax]

Xygax:

I think what he means is that since you can't have code that says "This skill OR this skill OR this skill reaching this point WILL BRANCH this skill", maybe those other two skills could have it coded to notify you when they have reached that certain level so that action can be taken without you having to do guesswork and bother the staff to check on it.

We can't?  This code stuff is hard.

-- X

ps:  If it's not clear from the sarcasm, what I'm trying to suggest here is that the email notification is not easier to implement than the smarter skill-branching.

[Armaddict]

Ah, I see.  XD

[Salt Merchant]

Xygax:

I think what he means is that since you can't have code that says "This skill OR this skill OR this skill reaching this point WILL BRANCH this skill", maybe those other two skills could have it coded to notify you when they have reached that certain level so that action can be taken without you having to do guesswork and bother the staff to check on it.

We can't?  This code stuff is hard.

-- X

ps:  If it's not clear from the sarcasm, what I'm trying to suggest here is that the email notification is not easier to implement than the smarter skill-branching.

I would suspect it is. For one, it doesn't actually add a skill. And Arm clearly already has an automated email system that could be invoked (e.g. an email is automatically sent out when a character dies). It should be simple.

[Xygax]

Yes, but so's fixing the skill system.

-- X

[Salt Merchant]

Yes, but so's fixing the skill system.

-- X

Not to be antagonistic, but if that's true, why not just put the fix in?

To quote Morgenes directly:
If you feel you should branch parry from two-handed (you have trained two-handed enough to get it branched), you can submit a request and we will review your skills.  Unfortunately Arm 1 won't allow us to let you branch parry from both/either skills.

Morgenes is a prominent coder of the game, but he seems to feel here that the effort involved isn't worthwhile (which presumably indicates that it's significant).

[Sephiroto]

Although I don't know Arm's code, the following idea seems like it might help Morg figure out a way.  I was thinking, couldn't you just assign a variable to all characters who branch parry.  Like pv for "parry value"  Once certain skills reach branch level for parry the game checks for the variable "pv" (parry value).  If the variable is "no", then parry activated in the skillset.  Once parry is added the variable is changed to "yes".  Then, if the code ever checks skills again the value for pv will be "yes", but since the pv must equal "no" for parry to set at the newly branched level it would never be bugged back to newly branched value and should continue to go up normally.

Or maybe they can make it work, but like you say, it might not be worth the extra effort due to the new codebase for 2.Arm

[Xygax]

Well, I didn't say I felt it was worthwhile, either.  I'm just saying that one solution isn't easier than the other.  Perhaps some pseudo-code will prove instructive:

Code Select Expand

if (should_branch_skill(ch, SKILL_PARRY)) init_skill(ch, SKILL_PARRY, 10);
Isn't easier or harder than:

Code Select Expand

if (should_branch_skill(ch, SKILL_PARRY)) send_email(ch, "You should ask a staffer to branch parry for you.");

The hard part (if it is hard, which may be debatable), is the "should_branch_skill()" part, not the email or init part.  Those parts are easy.  We could probably relatively quickly hard-code an answer for the parry question in any case.  Sure, designing and coding an improved data-structure for the skill-tree might be the more generic/clean long-term solution, and perhaps that's what Morgenes is referring to as non-trivial, but all of the discussion here has been around building the notification.  As you note, Salt Merchant, the email notification is easy.  What no one here seems to have considered is that if we're going to hard-code a check for whether the skill should branch or not (or improve the skill-tree structure), we'd have already done the "hard part".

-- X

[Salt Merchant]

Well... I figured the hard-coding in of a check for the skill level to be trivial. It's just an in-memory check whether a property has increased past a certain value. One "if" statement, really, just as in the pseudo code.

Code Select Expand

if (get_val(peon, SKILL_WHATEVER) > ARBITRARY_NUMBER) send_email( get_val(peon, EMAIL), "You can branch! Oh joy\n");

Easy, players are happy, less burden on the staff. What's not to like? 

Code Select Expand

if (get_val(peon, SKILL_WHATEVER) > ARBITRARY_NUMBER) add_skill( peon, SKILL_PARRY, 10);

If the above works, so much the better.

[Xygax]

Admittedly, CVS annotate only accuses me of touching 98570 lines of code in Arm's .c and .h files (probably inflated by one or two runs of "indent" on our source code, so there's a grain of salt for you) of Arm's 234256 total lines, so I might not be a "prominent" enough coder for Salt Merchant. 

-- X

[Salt Merchant]

Admittedly, CVS annotate only accuses me of touching 98570 lines of code in Arms .c and .h files (probably inflated by one or two runs of "indent" on our source code, so there's a grain of salt for you) of Arm's 234256 total lines, so I might not be a "prominent" enough coder for Salt Merchant. 

-- X

Gah... you've probably expended more effort refuting me than it would take to put the feature in!!

I'm going away to sulk now.

[Xygax]

I'm actually not at all trying to refute.  I'm trying to help you expand your thinking.

Don't worry so much about how hard something is for us to code, or about the implementation details of the thing.  If you want a feature, propose it.  And ask for what you really want, not what you think the reasonable fallback is.  Then, don't debate over the merits of various implementation details...  without knowing the code well, it's a meaningless debate.  Overall, I think this will improve the level of our discourse, because sometimes we don't know precisely what user-facing features are most interesting to you guys, but we do know pretty well how hard certain things are to implement.

When you're proposing a feature or improvement, think of it only in terms of how you'd like it to work from your perspective as a player:  "When I achieve some reasonable level of proficiency in my two-handed fighting skill, it would be cool if I could automatically branch parry."  Don't worry about whether we implement it using an edesc on the player, or whether our skill-tree code is sufficiently flexible.

There's nothing that can't be done in code.  Sure, we prioritize the things we work on based on perceived benefit, or based on what's interesting to us personally, but nothing is impossible.  That doesn't mean we'll always do it, but I think if you start with shooting for the stars, we're more likely to have a productive discussion.

-- X

[IAmJacksOpinion]

I'm actually not at all trying to refute.  I'm trying to help you expand your thinking.

Fuckin' hippies...

If you want a feature, propose it.  And ask for what you really want, not what you think the reasonable fallback is.

A parry skill that branches from a broader perspective, such as etwo or even general offense (so a guy can use a shield to not get raaaaaaaped while he's trying to branch?) please!

[cyberpatrol_735]

I know coders hate examples, but I do have an idea.

Instead of basing the parry branch off of the existing code, go to point_update or pulse, even possibly skill_use and use something like:

Code Select Expand


    if ( !str_cmp(db_guild_data[ch->guild].name, "Assassin") || !str_cmp(db_guild_data[ch->guild].name, "Pickpocket and so forth") ){
        if ( ch->skills[SKILL_ETWO] >= ( skill_cap(ch, SKILL_ETWO) - 20 ) )
            if ( !ch->skill[SKILL_PARRY] )
                ch->skill[SKILL_PARRY] = 5;
    }


I mean.. that's how I'd do it if there wasn't another way. Just tossing ideas, I do know C and that's not really pseudo, it's mostly diku.
It's a temporary fix and it would work, what other factors could throw up problems, X?
Please don't bash me for trying to be helpful

[Xygax]

We have better transition points (gain_skill and login handling, I think, are my favorites) and the version I'd do would have a lot less string compares, but yes something like this would be what I was talking about earlier when I said "hardcode".  But I'm not really soliciting help in implementing the feature.  As I said above, I'm trying to get you guys to STOP worrying about implementation details, not write code.

-- X

[FantasyWriter]

I wish I could code, sniff sniff.

em mopes off to buy a C for Dummie's book.

[RogueGunslinger]

If I could code, I'd simply propose all my ideas in such a format so they could just be implemented if staff agreed.

[Xygax]

If I could code, I'd simply propose all my ideas in such a format so they could just be implemented if staff agreed.

But even if you were Dennis Ritchie himself, you wouldn't be able to implicitly know the APIs and data-structures of the Arm code, it's limitations and strengths, or the utter mayhem that has ensued in parts of it.  All of which means you wouldn't be able to write code that I could use without modification and debugging (which means I'd be pretty much just as well off ignoring your code and writing my own).

-- X

[RogueGunslinger]

But I'd do it anyways. Because I could, and sharing ideas in a certain format, if it better describes what I'm trying to say, is useful.

Don't ask where that came from.

[Xygax]

But I'd do it anyways. Because I could, and sharing ideas in a certain format, if it better describes what I'm trying to say, is useful.

Right, I totally agree.  Which is why I'm trying to convince you that code is NOT the better format.

-- X

[SMuz]

Ugh, no, don't ever post ideas in code. Pseudocode if you really have to

Heheh, I'd imagine that one of the major reasons to work on Arm 2 is the utter mayhem of heavily modifying the original code. I suppose that making parry branch from other skills would require some reprogramming of the branching code, which is why they haven't done it yet. Or if it's not really that tough, one of them would do it tonight to prove us wrong

[Xygax]

I would, actually, but I've got my sandbox gutted to implement some new JavaScript features I think are cooler.

-- X

[RogueGunslinger]

Now where did I leave that quote.. Oh yes;

Well, I didn't say I felt it was worthwhile, either.  I'm just saying that one solution isn't easier than the other.  Perhaps some pseudo-code will prove instructive:

Code Select Expand

if (should_branch_skill(ch, SKILL_PARRY)) init_skill(ch, SKILL_PARRY, 10);
Isn't easier or harder than:

Code Select Expand

if (should_branch_skill(ch, SKILL_PARRY)) send_email(ch, "You should ask a staffer to branch parry for you.");

The hard part (if it is hard, which may be debatable), is the "should_branch_skill()" part, not the email or init part.  Those parts are easy.  We could probably relatively quickly hard-code an answer for the parry question in any case.  Sure, designing and coding an improved data-structure for the skill-tree might be the more generic/clean long-term solution, and perhaps that's what Morgenes is referring to as non-trivial, but all of the discussion here has been around building the notification.  As you note, Salt Merchant, the email notification is easy.  What no one here seems to have considered is that if we're going to hard-code a check for whether the skill should branch or not (or improve the skill-tree structure), we'd have already done the "hard part".

-- X

[Xygax]

I'm sure you're making a point, but I'm not sure what it is...

-- X

[RogueGunslinger]

Yeah... Neither did I.

[Eloran]

Sending in a request takes five minutes. Receiving a reply usually takes a week, if not less.

The process was painless for me when I requested parry from etwo - Morgenes was more than helpful.

[Salt Merchant]

Sending in a request takes five minutes. Receiving a reply usually takes a week, if not less.

The process was painless for me when I requested parry from etwo - Morgenes was more than helpful.

It's difficult for me to not write a pissy response to this. Okay, on the face of it, yes, I imagine you got a reply and Morgenes was polite and all that. Fine. But the underlying mindset drives me nuts. Namely that eliminating a host of annoyances (listed below) is not worth a five minute change to the code. I don't care what people say, I just can't see this taking more than five minutes to hard code in.

1. We repeatedly read how busy the staff are. In this case, they have to process requests, many of which probably are not even valid since the person asking has absolutely no way of knowing whether the skill has reached the necessary level or not. They have to read the request, manually check the skill level, add the skill if need be and reply.

2. Player X may not know to send in a request. Not everyone devours the GDB and would know.

3. Player X may just not think he's reached the point at which he should have parry, even though he's long been there. No request.

4. Player X may be too intimidated by the staff or shy to send a request in, especially if he sent one in last month and was told no.

5. Player X may lose his character by the time a week has passed and the staff can turn their attention to it. Maybe he wouldn't have lost his character if it could have parried that fatal blow? In any case, he'll never get to enjoy having that skill.

6. Player X might not even know whether a particular class can ever branch parry or not. I don't think it's mentioned anywhere in the help files that rangers eventually can parry, for example (if I'm wrong about rangers, it just proves my point).

I could extend this list, but I think it's already long enough to be convincing. So, yes, while the existing system works (sort of), I don't see any reason at all not to improve on it.

To top it off, Xygax has posted here about twelve times, gotten sarcastic toward me by his own admission (thereby implying that I'm stupid), and went to the trouble to dig up all sorts of statistics on all the work he's done on the code. All of that rather than just tweaking the code to notify players and save the staff's time on who knows how many unnecessary requests too. Wtf, I ask you?

Now Gimfalisette has posted an even better idea, namely having the skill command include a flag (a *) for maxed out crafting skills of merchants and for maxed out parry. No notification email need even be sent. Five minutes of work has become two minutes. Still ignored.

Sorry to the people who are offended by my saying this, but it's very discouraging to me as a player.

EDIT: if the staff is so tight on time, then I volunteer to help out. One of my degrees is in computer science, I have many years of professional experience and years of experience with coding on MUDs as well. Even time on staff on this one, although not in a coding capacity (except for DMPL).

[Xygax]

It's difficult for me to not write a pissy response to this. Okay, on the face of it, yes, I imagine you got a reply and Morgenes was polite and all that. Fine. But the underlying mindset drives me nuts. Namely that eliminating a host of annoyances (listed below) is not worth a five minute change to the code. I don't care what people say, I just can't see this taking more than five minutes to hard code in.

Yeah, I think the hacky version is worth about 5 minutes worth of code to write.  I'm not a huge fan of writing hacks like that as they become harder and harder to maintain, and often introduce unexpected bugs.  5 minutes of coding also equates to at least 10-20 minutes of testing and debug, if we're being responsible (I confess, I'm not always that responsible).  But, for me, the real reason I probably won't be tackling this project tonight (aside from the fact that it's Friday night) is the tone of this post.

Don't take this too badly, it's probable I wouldn't have tackled this anyway, it's not the sort of thing I usually like to munge with and I'm not compelled by the mechanic itself, in any case (though I -could- see myself getting turned on by the fixing-the-skills-system-data-structures project).  But you certainly haven't increased the likelihood of me working on this, and I'd be surprised if your post gave the other coders any warm fuzzies, either (though I'm in no position to speak for them).

-- X

[cyberpatrol_735]

Code Select Expand


> Look thread

Before you is a thread about implementing code features from the players to the staff.
Many snarky comments have been made and have been responded to in a professional
manner.

A gdb discussion thread looks near-death.


[Synthesis]

There's some warm fuzzies for you.

[Twilight]

To respond hopefully how Xygax was hoping for:

The only thing I can see with the proposed change, being able to branch parry from two-handed as well as some other skill, is that people who have not experienced such a branching are taken care of, as they might not have any idea how long it takes, or that it exists.

I would like to see the branching code updated.  I would like to see it such that multiple paths can bring about a branching.  I would like to see it so that multiple skills often work in conjunction to branch.

To give an example, lets say that Tavern Gossipping branches to Aide Boffing at 69.3 percent.  I would like to see it such that if Byn Humping was at 40.2% and Slandering Elves was at 45.6%, you would also branch to Aide Boffing.  Or if Tavern Gossiping was only at 50% but your Slip the Mickey skill was at 30%, you would also branch.

While given the player knowledge on branching this wouldn't be as cool as it could be, if it were implemented in Arm 2 the right way I think it would go a long ways towards obscuring what branches what. 

Of course, I would like skills to build on each other as well.  So that, for instance, 10% of your Tavern Gossiping skill percentage is added onto your Aide Boffing skill.  Thus, while some people may have an "advanced" skill or two (especially with split guilds), they must have the base skills feeding into them to become masters.  So someone with woodworking would get some impact from what their lumberjacking skill was.  And someone with wagonmaking would get impact from their lumberjacking and woodworking skills (and maybe other skills, given its nature).

[Xygax]

That's a much more sophisticated system even than I had envisioned, but yes something like that would be awesome.  Maybe not TOO hard to do, either.

-- X

[jmordetsky]

If I could code, I'd simply propose all my ideas in such a format so they could just be implemented if staff agreed.

But even if you were Dennis Ritchie himself, you wouldn't be able to implicitly know the APIs and data-structures of the Arm code, it's limitations and strengths, or the utter mayhem that has ensued in parts of it.  All of which means you wouldn't be able to write code that I could use without modification and debugging (which means I'd be pretty much just as well off ignoring your code and writing my own).

-- X

opensource, svn, and google code?

edit:

oh yea, unit tests.

edit++:

wait even better. gladiator match unit tests . If you made a change to combat but wanted to make sure the new changes didn't let a n00b elf ranger kill a maxed mul warrior you could run the test that would make them fight.

I'm radical.

[Twilight]

Mmmm, I think sophisticated would be to impact the max cap of the branch skilled.  So, to continue my example:

Branch from Tavern Gossiping:  50% max Aide Boffing
When Slip the Mickey is 30%:  Add 20% to Max
When Byn Humping is 40.2% and Slandering Elves is 45.6%:  Add 15% to Max

Branch from Byn Humping and Slandering Elves:  30% max Aide Boffing
When Tavern Gossiping 50% and Slip the Mickey 30%: Add 20% to max
When Tavern Gossiping 69.3%: 35% to max

Etc.

Of course, that would be a complete pain, most likely.

[Armaddict]

Needz more powergame.

[Salt Merchant]

There's some warm fuzzies for you.

These did make me feel better. For a moment. Thanks.