1 hour ago, JJs Juggernaut said:

This not true to my knowledge. The Java random function that vassal uses is as random as machine random is. A seed is used (usually nano seconds on a clock) and that generate the random value. That generated value in no way effects future generated values to "balance" things out.

I was told by a friend @NebulonB who I think asked @Green Knight about it, that it did not use the Java Random class but some sort of Vassal internal rng function that was a bit of a black box.

I hope I don't mis-remember something, please correct me if so.

50 minutes ago, Rocmistro said:

So I haven't played Armada on Vassal in a long time. Does it still have all the fiddlyness of having to pull out each piece for everything one at a time and all that? I love the effort and idea behind Varmada, but good lord is it cumbersome to play.

Once you get used to it, it can be actually faster than a real game.

You are highly encouraged to create lists and save them prior to playing though, you can do that offline - saving is easy and there is a guide for it by GK.

30 minutes ago, RapidReload said:

I was told by a friend @NebulonB who I think asked @Green Knight about it, that it did not use the Java Random class but some sort of Vassal internal rng function that was a bit of a black box.

I hope I don't mis-remember something, please correct me if so.

On 10/25/2016 at 4:04 AM, Green Knight said:

Add dice/re-roll fallacy debunked:

I've had some players insist that the dice roller's random function is bugged somehow.

Basically this:

A) Get different results when you roll all dice at once, rather than roll a few, then add some dice. Take Ackbar, for example. Roll 3 and then add 2 is supposedly different from roll 5.

B) Re-rolling a dice produces weird streaks. Re-rolls from Evades, Toryn Farr, whatever. So if you cancel a dice and add a dice instead (same net effect), you'll get different results.

I'm sorry, but I'm unable to locate any bugs.

Dice (and fickle red dice in particular) produce a wide range of possible results, no matter the method used to roll them.

As for re-rolls, yes there are streaks, but the same applies to canceling/adding a dice. As a matter of fact, it would be very strange not to get some streaks (blue/black dice should get plenty of HIT streaks in particular, but also ACC and HIT/CRIT respectively).

http://www.vassalengine.org/wiki/Using_VASSAL#Why_are_the_dice_rolls_not_random.3F

Its been monte carlo'd, both short and long strings are random.

The human pysche is at fault, we naturally remember the extremes. So yes its your own fault @RapidReload and @Karneck

9 minutes ago, CaribbeanNinja said:

http://www.vassalengine.org/wiki/Using_VASSAL#Why_are_the_dice_rolls_not_random.3F 

Thanks for looking all that up.

Knowing a little bit about random number generators I did not find it strange that there may be 5 red blanks in a row, but that it often seems to get counterbalanced by a sequence of good results - and more often than for it to be coincidence in my estimation. In short, it would appear that the past results have an effect on the current result, which could happen if the seed value for the generator was not changed or was not independent from the other seed values used.

But you looked up all the information so I guess its for me to believe what they say or not to.

Not sure it got reported as a bug, but a game @Karneck and I had a bit back demonstrated some kind of weirdness with the fire arcs on either the Victory or Gladiator.

I can probably dig up the log file if needed, but you can see it in the video here at 0:22/0:23 seconds where we are flipping back and forth in the arcs between the Demolisher and my VSD...

For some reason, I'm very clearly in his black dice range in his front arc, but when we popped the overlay up on the Victory, he was visibly out of black dice range in my side arc.

Which...doesn't make any sense at all.

Yeah, I reported it, but all I got was shoulder shrugs.

17 minutes ago, Ginkapo said:

Its been monte carlo'd, both short and long strings are random.

The human pysche is at fault, we naturally remember the extremes. So yes its your own fault @RapidReload and @Karneck

Well if its been monte carlo'd who am I to ask polite questions. Let the self-flagellation commence.

5 minutes ago, Karneck said:

Yeah, I reported it, but all I got was shoulder shrugs.

Actually you got more than shoulder shrugs. You had several people respond with suggestions and opinions as to what may be happening. As GK suggested, the arc could be a pixel off (we will be verifying if this is the case in our own dev tests). As other suggested (and it looks to me), it looks like the VSD side does have the GSD front.

And finally, one other thing. Depending on your zoom level things can appear differently. I had one case were I was clearly in and showed my opponent a screenshot, he showed me one as well as it was clearly out. This was a case of different zoom levels and screen resolutions. That's just the way digital images are.

4 minutes ago, JJs Juggernaut said:

Actually you got more than shoulder shrugs. You had several people respond with suggestions and opinions as to what may be happening. As GK suggested, the arc could be a pixel off (we will be verifying if this is the case in our own dev tests). As other suggested (and it looks to me), it looks like the VSD side does have the GSD front.

And finally, one other thing. Depending on your zoom level things can appear differently. I had one case were I was clearly in and showed my opponent a screenshot, he showed me one as well as it was clearly out. This was a case of different zoom levels and screen resolutions. That's just the way digital images are.

I did zoom in and out a few times to confirm it, and the difference appeared to remain at various zoom levels.

And it wasn't a near thing, either - the GSD -> VSD shot was well into my hull 'cardboard' (indeed, he had black on my front and rear hull zones, too, not just the side), while for the VSD -> GSD shot I couldn't even get the corner of his plastic or shield dial. It was a big difference, which we both saw on our own instances.

12 minutes ago, RapidReload said:

Well if its been monte carlo'd who am I to ask polite questions. Let the self-flagellation commence.

It has been asked so many times, so yes, its been tested, move on.

Thanks for adding the SSD; didn't seem to be any obvious problems.

Depressed to find out that my current list seems to work quite well against an SSD. I was really hoping to try something new when the SSD came out, but maybe my SSD build just needs work... ECMs (on large ships) seem to be a pretty good counter to the SSD. Advanced Projectors on it was useful at first, but once the shields were gone I really needed ECMs.

Hmm. Seems that when you spawn the 4 command dials for the SSDs the top three spawn "revealed" - when you set them they're visible. The "extra dial" is fine, it's just the other three.

20 hours ago, Grumbleduke said:

Hmm. Seems that when you spawn the 4 command dials for the SSDs the top three spawn "revealed" - when you set them they're visible. The "extra dial" is fine, it's just the other three.

Thanks! Added to the list to fix in the next update. For now its simple enough to fix them by unflipping them after you spawn it.

I just came across all this, and I have a hat to throw in the ring. But I do want to caveat first that, just because this is long, I ain't mad--there's just a lot to this question. So, sorry if I come off as abrasive @RapidReload and @Karneck . No hard feelings intended.

--

On 1/9/2019 at 11:46 AM, RapidReload said:

I guess its for m  e to believe what they say or not to   .  

You really don't have to take anybody's word for it. It's all open source, so you're welcome to go look at the source code .

I just did. I don't know Java at all, and most of the code is not well-documented, but best I can tell from a quick 20-minute perusal, these are the relevant snippets in VASSAL.build.module.DiceButton.java:

public class DiceButton extends AbstractConfigurable {
  protected java.util.Random ran;
  
  ...

  protected void DR() {
    StringBuilder val = new StringBuilder();
    int total = addToTotal;
    int[] dice = null; // stays null if no sorting

    if (!reportTotal && nDice > 1 && sortDice) {
      dice = new int[nDice];
    }

    for (int i = 0; i < nDice; ++i) {
      final int roll = ran.nextInt(nSides) + 1 + plus;
      if (dice != null) {
        dice[i] = roll;
      }
      else if (reportTotal) {
        total += roll;
      }
      else { // do not sort
        val.append(roll);
        if (i < nDice - 1)
          val.append(","); //$NON-NLS-1$
      }
    }

    if (reportTotal) {
      val.append(total);
    }
    else if (dice != null) {
      Arrays.sort(dice);
      for (int i = 0; i < nDice; ++i) {
        val.append(dice[i]);
        if (i < nDice - 1) {
          val.append(","); //$NON-NLS-1$
        }
      }
    }

    String report = formatResult(val.toString());
    Command c = report.length() == 0 ? new NullCommand() : new Chatter.DisplayText(GameModule.getGameModule().getChatter(),report);
    c.execute();
    c.append(property.setPropertyValue(val.toString()));
    GameModule.getGameModule().sendAndLog(c);
  }
  
  ...
  
  public void addTo(Buildable parent) {
    ran = GameModule.getGameModule().getRNG();
    GameModule.getGameModule().getToolBar().add(getComponent());
    property.setPropertyValue("1"); // Initialize with a numeric value //$NON-NLS-1$
    property.addTo((MutablePropertiesContainer)parent);
  }
  
  ...
  
}

Basically what's happening here:

The module defines "ran" as an instance of or reference to the class java.util.Random .

Then it does some other stuff.

Then it calls the nextInt() method or function of ran , with the parameter of nSides . This bit:

final int roll = ran.nextInt(nSides) + 1 + plus;

means it's using a Java standard library to generate a pseudorandom number in an idiomatic Java manner to get a value between 0 (inclusive) and nSides (exclusive), nSides being presumably the number of sides on the die. It then adds 1 so that the random number is 1 (inclusive) to nSides (inclusive), so 1d8 roll returns 1-8 instead of 0-7. It then has a provision for a result modification (not relevant to the Armada module, but remember VASSAL is a framework and other modules would need this functionality) by adding the contents of plus to that result before sticking it in a list of results to return later.

Then it does some other stuff.

Then it binds all that other **** it just did to an interface to make it accessible to whatever modules want to use it. This is the interface the Armada module uses to "roll" dice.

So best I can tell, this

On 1/9/2019 at 10:58 AM, RapidReload said:

I was told by a friend @NebulonB who I think asked @Green Knight about it, that it did not use the Java Random class but some sort of Vassal internal rng function that was a bit of a black box.

is not accurate. While it is true that there is provision for black-box dice rollers in the codebase (specifically, a provision to interface to a couple of different die-rolling webservers), the Armada module doesn't use either of those. I verified this both by looking through the code, and by rolling dice and capturing the network traffic to verify that no dice data (indeed, no data at all) was being sent back from Vassal's server or anywhere else when I rolled dice. The only data on the wire is the log file updates sent to Vassal to post to the other player so they can see the roll results after they've been rolled.

I'm honestly not sure what you mean by this:

On 1/9/2019 at 8:11 AM, Karneck said:

it also seeks to have "balanced" results.

but this piece of it:

On 1/9/2019 at 8:11 AM, Karneck said:

This means most games are usually fine, but some can get super skewed.

should be no more true in Vassal than IRL, and in fact is very likely less true in Vassal as physical gaming dice are actually generally pretty poor mechanical RNGs .

Also, just a friendly reminder since I was sniffing Vassal network traffic as part of the above research: don't use real passwords for your Vassal password!

Vassal does an absolutely piss-poor job of handling what it calls "passwords." They are stored in plaintext on your PC, they are passed in plaintext over the internet to everyone on your Vassal server, they are stored in plaintext in log files, and the lead dev doesn't give a **** because "well, we tell people on vassalengine.org not to use real passwords."

I saw several real passwords in the network traffic...

Where is a good tutorial video for playing Armada on Vassal? I've googled and every one I've found says "This video is unavailable". I'm not familiar with how Vassal works and need a good Vassal Armada 101

4 hours ago, Ardaedhel said:

It's all open source, so you're welcome to go look at the source code .   

Wooooot? Looking at that baby asap. (As soon as my real baby is asleep).

Might respond after I have a look at it, but your post makes me think I was right with:

On 1/9/2019 at 8:46 PM, RapidReload said:

which could happen if     the seed value for the generator was not cha  ng  e  d

To be confirmed.

5 hours ago, RapidReload said:

which  could happen if     the seed value for the generator  was not cha   ng  e  d

That task is abstracted away by java.util.random. Vassal shouldn't even need to bother with it.

If java.util.random doesn't change seeds, we have way bigger problems than cold dice.

2 hours ago, Ardaedhel said:

That task is abstracted away by java.util.random. Vassal shouldn't even need to bother with it.

If java.util.random doesn't change seeds, we have way bigger problems than cold dice.

Well I had a look at it. Was a little disappointed that it is only the Vassal source code, was hoping for the Armada module source code. Anyway.

With respect to the RNG, not much one can say really, and it is in fact a bit of a black box.

The key is that

protected java.util.Random ran;

is later set to

ran = GameModule.getGameModule().getRNG();

which is

protected Random RNG = new SecureRandom();

According to the specification, SecureRandom will generally use the SHA1PRNG algorithm, which is an old cryptographic hash function that is apparently re-implemented (changed) by SUN for Java at times, and it is not known what the current java implementation looks like beyond:

The general structure is well known (see https://en.wikipedia.org/wiki/SHA-1#/media/File:SHA-1.svg), however there are some inputs that may vary, as may the function F.

Generally I can add that the seed value is set once, at the start of the Vassal engine to whatever SHA1PRNG uses as seed as it is not set explicitly by the Vassal implementation and later not changed. While, from a cryptographic standpoint this is not good, for the application scenario here its not a real issue, we are unlikely to throw enough (~2^64) dice, however there could conceivably be an issue with the reduction from the 160-bit SHA result to the 64 bits used by Java, to the 8 numbers used by Armada Vassal. The design of SHA-1 leaves the lower 64 bit of the hash the same as were bits 32-95 a round earlier ... this might in fact not be good for our specific use case, as these are then possibly mapped directly to values in the range 0-7. However any issue there would be on the side of Java/Sun, so I guess we'll have to trust them and have no way of checking :-p. They might even take those 64 bits from the middle of the hash, who can say.

I would in fact prefer an implementation based on the standard java.util.random class using a PRNG based on the linear congruential method as this would allow for a perfectly controllable, better understood, also nicely randomized, and faster implementation of the dice rolling, but hey, small problem.

Finally, each player will have their own SHA1PRNG running and synchronizing their results via the Servers - I was not certain this happened, thus it is in fact impossible for results rolled by one player to influence the results from the other player in any way, so good news on that, if you roll badly and your opponent rolls well, blame your own SHA1PRNG, the devil.

53 minutes ago, RapidReload said:

Finally, each player will have their own SHA1PRNG running and synchronizing their results via the Servers - I was not certain this happened, thus it is in fact impossible for results rolled by one player to influence the results from the other player in any way, so good news on that, if you roll badly and your opponent rolls well, blame your own SHA1PRNG, the devil.

That is interesting. Appreciate all the input from everybody.

SSD card needs an exhaust I think for passes.

Also hovering over the SSD to get a closer view doesnt really work. Its too big.

1 hour ago, Ginkapo said:

Also hovering over the SSD to get a closer view doesnt really work. Its too big.

I have a feeling that phrase is going to come up a lot with the SSD.

From the spread we've seen the SSD comes with a "pass" token of sorts: - not sure if it is worth including that in some way?

22 hours ago, RapidReload said:

the  Armada module source code.

The Armada module is a zip file with a .vmod file extension. The "logic" such as it is is pretty much contained in a build XML in that zip.

As far as I can tell it doesn't explicitly define a die roller in there (though, again, I just did a quick ctrl-f instead of reading the whole 1+MB text file), which means it should default to the Vassal default die roller, which, as far as I can tell, is the one under discussion.

GK's outube tutorials are down!