DiceTool features

[Mr.Ice]

1. make this a chat tool, integrated with the maptool server.

2. reorganize it so that dice rolls come out chat friendly. Emryss posted about a chat on GRiP boards, iPC I think, that had templates for chat messages -- I like that in that it would be good to be able to set up templates for output and have the roll buttons fill in the blanks.

%color%who rolls %what (%result) = %total%-color
%color%who attempts to %action (%roll) = %success%-color

3. per character messages, emotes, /ooc are all requirements, and see Emryss' s post on chat features for some more awesome ideas (http://rptools.net/phpbb2/viewtopic.php?t=10)

4. still keep things selectable, linkable, etc. So for example I can highlight a bunch of rolls and get a total or perhaps right-click menu to apply the damage to something.

5. send maptool macros to maptool (/center $blah) (/playerlink) etc. expand the macro api so that the chat can do some fun stuff like set token states, flash tokens briefly (indicating for example who's turn it is to move),

6. hotkey the tabs and the buttons -- for example put 12 buttons per tab and use F keys to activate. use Shift-F keys to select from the first 12 tabs.

7. export/import or save/restore to generatable files, this could be the beginning of an API from say DMGenie, a plugin there could export a group to a compatible file

8. hotkeys to select from characters you want to chat with , say Alt-F* keys. The character becomes the 'speaker' for all things sent through chat.

[Kuprin]

We need additional dice functions. At the very least:
1. Ability to roll dice individually, and compare each to a target number, such as in Shadowrun and WoD.

2. Ability to see each individual die rolled, and modify them individually.

The latter is higher-priority, obviously, but this needs to happen.

[RPTroll]

And it would help with backgammon.

[Kuprin]

Check out how OpenRPG's dice tool works, if you can get the infernal pile of bad Python to actually work. http://www.openrpg.com

They have a lot of really cool die rollers and stuff that I'd love to see implemented and would definitely help with coding. Just let me finish my exams this week and I'll start source-diving and getting a feel for the code.

Note: I'm a documentation nazi, so if your code is badly documented, you have one week unless you want one angry axe-wielding code-kitty in here on Sunday.

[jay]

Note: I'm a documentation nazi, so if your code is badly documented, you have one week unless you want one angry axe-wielding code-kitty in here on Sunday.

Ha, you're on my side! Make sure you get that axe nice and sharp.

[trevor]

Jay is speaking in reference to our disapproval of over documentation, such as a closing "// end if". Superflous.

[jay]

Heh, that's a leftover. My old editor used to add them automatically and I got used to them.

<grandpa-programmer-voice> I remember the day when we didn't have them-thar fancy code colorizers. We were just happy we didn't have to poke holes in paper to program a computer anymore.

[giliath]

I love debates like this, so here are my 2 cents. My apologies to the developer's whose code I used below, it is not really fair because the code is pre-alpha and little more than a placeholder.

I believe in documentation that explains why something works a particular way or more globally what things are, but I have a huge problem with code comments that explains the obvious. I think they detract from the code because they spread the thing you want to read (the code) out to where you can't see as much on the screen at the same time.

The following code is commented in a way that is completely unnecessary and distracting.

Code: Select all

/**
 * This class contains the data for a creature that can be stored in a group.
 */
public class Creature {
  /**
   * Name of this creature.
   */
  private String name;

  /**
   * Get the name for this Creature.
   *
   * @return Returns the current value of name.
   */
  public String getName() {
    return name;
  }

  /**
   * Set the value of name for this Creature.
   *
   * @param aName The name to set.
   */
  public void setName(String aName) {
    name = aName;
  }
}

versus something like this:

Code: Select all

public class Creature {
  private String name;

  public String getName() {
    return name;
  }

  public void setName(String aName) {
    name = aName;
  }
}

The most interesting thing, is that neither one explains "why" we wrote Creature, i.e. what is it generally supposed to do. In the case of a simple model object, that is the detail that is interesting. Even worse, the code "looks" commented, but it really isn't so most likely that detail won't be added.

As an aside, DiceTool's code base is very old and not written particularly well. I keep meaning to do rewrites, but I want to rework the UI and haven't found a suitable replacement for the way I use it.

[jay]

Comments below are just my opinion. They probably don't mean much to anybody except me, but I feel better now that I've written them down. It is really long and is off the original topic so you can safely ignore it.

I love debates like this, so here are my 2 cents. My apologies to the developer's whose code I used below, it is not really fair because the code is pre-alpha and little more than a placeholder.

Apology accepted

I believe in documentation that explains why something works a particular way or more globally what things are, but I have a huge problem with code comments that explains the obvious. I think they detract from the code because they spread the thing you want to read (the code) out to where you can't see as much on the screen at the same time.

I believe in commenting to help with maintenance. In my opinion, everything created should have a small header to tell what it is, because it helps me find what I really need faster. I don't want to read 5, 10, 50 lines of code just trying to figure out what a method does if it is irrelevant to what I'm doing. And very often just the name of the item is not enough. I have found that what I think is obvious and what somebody else thinks is obvious are frequently two very different things. This is especially true when I'm trying to add something to another's code. They were looking at it one way (i.e. to implement) and I am looking at it in a completely different way (i.e. to add support for new functionality). I've actually had code return to me years after I last worked on it where I was both of those people.

I like to be able to scan a method for the most likely place I need to start working. To facilitate that I add comments within the code which are 'redundant' in that they say what a small block of code is for. Sure, I could read 5, 10 or 15 lines of code and find out what it does but it is just easier and significantly faster for me to read a one line comment (unless they were in Japanese, those were tough).

I actually like the code to be spread out, especially with the colorized editor. In my opinion, having 20 getters and setters crammed in 80 lines isn't easy to read. Now start adding methods within the getters and setters that are also uncommented and it can become difficult to instantly find where the method starts and stops. Of course, 20 getters and setters which are crammed into 180 lines isn't easy to read either. Luckily getters and setters aren't very interesting to read, and I ignore them completely after they have been created. Maybe that's why I don't have a problem with the big comments.

The following code is commented in a way that is completely unnecessary and distracting.

Code: Select all

/**
 * This class contains the data for a creature that can be stored in a group.
 */
public class Creature {
  /**
   * Name of this creature.
   */
  private String name;

  /**
   * Get the name for this Creature.
   *
   * @return Returns the current value of name.
   */
  public String getName() {
    return name;
  }

  /**
   * Set the value of name for this Creature.
   *
   * @param aName The name to set.
   */
  public void setName(String aName) {
    name = aName;
  }
}

I admit that Eclipse gets a little carried away with it's automatic comments. I changed them up some, but not a whole lot. I also admit to almost never reading the comments for my getters & setters. But I like Eclipse to check the code for comments while it is compiling and show me warnings where they are missing. Since the getters and setters are created by Eclipse, those never have that problem and I can find my real doc problems pretty easy.

versus something like this:

Code: Select all

public class Creature {
  private String name;

  public String getName() {
    return name;
  }

  public void setName(String aName) {
    name = aName;
  }
}

You are quite right about this being much easier to read. It is a class with one property in it, and those are always easier to read. I don't know that it is a relevant example for a discussion on comments in code.

The most interesting thing, is that neither one explains "why" we wrote Creature, i.e. what is it generally supposed to do. In the case of a simple model object, that is the detail that is interesting.

I did add a comment stating how I was using it. Or at least what I think it's going to do. Looks like we have differing opinions on what the word 'why' means. If we can't agree on that, how can we agree on what Creature means? And if I remember all of the code correctly, we don't

Even worse, the code "looks" commented, but it really isn't so most likely that detail won't be added.

I seriously doubt that the other example has a higher likelihood of anybody adding comments to it than the first one did. Why would they start now?

[Kuprin]

That's why I start with empty Java files and do my own comments. I do edit in Eclipse, though...at least when I'm on a comp with it. I'm quite familiar with "nano stuff.java" too.

Anyhow. Features.

Are the dice.each() and dice.vs() functions from OpenRPG in yet? If not I'm going to try to get 'round to getting them in asap. If anyone wants to give me a quick rundown on Subversion collabs, so I can make sure it's coordinated with any other build updates, that would be very apprecaited as I've never done any long-distance collab before.