Parry Branch from Multiple Skills?

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