Author Topic: skills.c-supporting larger skill values properly  (Read 1884 times)

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
skills.c-supporting larger skill values properly
« on: September 07, 2011, 08:24:45 pm »
    So, I'm currently doing some testing, and came across an interesting problem that'll probably get someone in the future; mainly, that skills command only supports fractions with a total length of 6 chars.  I'm not posting the file because this change is trivial, but think it's probably useful to throw this out there.

    So: the problem.  Skill values such as 20/20 work and will continue to work up to 99/99.  At 100/100, however, it will actually read 100/10, as the allotted length for the field in the scanf used to make it is only 6.  Essentially, when testing, it suddenly shows that you have a skill which is greater than it's max, a result which is completely possible to achieve through various means.

    So the change:

In /cmds/players/skills.c, find this:
    return sprintf("%:-20s: %:-6s (%d%%)", skill,

followed by a bunch of stuff that's a continuation of that line.  This is near the top, under the function GetLine.  Change it to:

    return sprintf("%:-20s: %:-9s (%d%%)", skill,

Essentially changing only %:-6 to %:-9.  You now support skills up to 9999/9999 in theory; I can only personally verify that 999/999 works, however.  In the current version, 3.7a5, this is line 22.

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: skills.c-supporting larger skill values properly
« Reply #1 on: September 10, 2011, 09:58:13 pm »
Note that there isn't any issue with the skill code functioning properly, this is merely a display problem.

Pardon my grandstanding below... :)

This is actually a symptom of a larger issue.  One that has been at the core of MUD development for decades, and one which other types of games are avoiding because they've split into a client/server architecture.

If our games were designed to let the server handle function and the client handle presentation, this wouldn't ever be an issue for Cratylus.  The server would happily return a packet containing the skill values in some kind of structured format like:

Code: [Select]
{ "skill" : { "name" : "footsie", "current_value" : 97, "max_value" : 99 } }

The client would then take that and present it in some kind of nicely formatted output like the server currently does, or maybe not like that at all... maybe graphically, or read out as speech, or presented as 97 tiny living orc figures and 3 dead ones.  The important part is, the server wouldn't be doing it.

Ok, I'm done.  This soapbox was paid for, in part, by FutureCorp.  FutureCorp, dragging text games into the twenty-first century... by force!