> StrictNMR should work that way, yes. I added the flag in because
> people were getting confused because of just the case you described
> -- but then some of the GMs complained, so I took the interface out
> but left the flag just in case it was needed later.
Well, you never get everyone happy!
But is it your intention that the flag is TRUE now? Because that
was changed with the last commit, according to the CVS history.
I don't really mind when the program is using StrictNMR or not
StrictNMR. If I have to put to order on Hold, then that is a small
effort. However, the problem is that with StrictNMR there is no
clear feedback why it was disbanded (it did not say, disbanded
due to Civil Disorder, or something like that). I had to look into
the code to figure out what was happening.
> On the Judge, if two retreats go to the same location they are
> reported as illegal. I just matched that.
Well, I don't agree with the Judge on this point, but it doesn't matter
> I'll have to try out the other problem to understand what's going on
> -- I haven't had a chance yet.
Yesterday, I realized that it is maybe not really a problem of RP.
What I did was to read orders with the overwrite flag on in the
retreat phase. At that moment I tried to move an army from
Ankara to Armenia and I could not enter that. So, I concluded
that the administration of RP was messed up. But, that is maybe
just a wrong conclusion. When RP is still in retreat phase, then
Armenia is probably not in the dislodge list of Ankara, or Ankara
is not dislodges at all. So, this is perfectly illegal as not expected.
The only thing is, does the 'overwrite When Loading' make any
sense in the retreat phase?? Maybe, you can just block that.
> I had a request for you -- since you now have the BFS code in there,
> do you think it's possible for you to modify the text for a convoyed
> army? I.e. once all the convoying fleets are in place, A Yor - Nwy
> becomes A Yor - Nth - Nwy. (It can't be A Yor -> Nth -> Nwy because
> the '>' mess up web pages). That would make things easier for the
> Judge users, as mentioned on the RPForum. But if it's going to be
> too much work, don't worry about it.
This is of course possible. But when we start to implement this, I would
like to see a more systematic approach to this problem. There are two
problems with Judge users, reading and writing orders. If we change
the output we should also allow the input (otherwize RP can't read its
own output!). Furthermore, if we just put the path in the output we deviate
from the official rulebook (as Face to Face player I do not like that).
Finally, the semantics are not the same in case of multiple paths. Yor - Nwy
is not the same as Yor - Nth - Nwy in case there are multiple paths. The
order Yor - Nwy can take any path, while the order Yor - Nth - Nwy can
only take the specified path.
What I want, is that RP can handle the three different types of convoys:
- Without path.
- With path.
- With the additional note "by Convoy" or "via Convoy" as clarified in
the 2000 rulebook.
In case of orders with path, RP should administrate the full path. Write it to
file and read from file etc. The same counts when the order contained
"by Convoy" or "via Convoy". The adjudicator should only consider the
specified path when the path is specified.
In the user interface the user should enter the full path. I was thinking, that
the user should go to Convoy mode, start on clicking on the convoyed
army, then click on the convoying fleets and end with clicking the final place twice
(as in a Hold support). For a move "by Convoy" it just should click on the
army and then click twice on the destination. The problem with this
user-interface, is that there is little feedback what is going on for the user.
It is maybe an idea to add an option dialog. Where you can switch this
on or off (it should be off by default, of course, since it is a deviation of
the official rules). When convoyed paths are on, RP should not accept
any move that is not to an adjacent place. The Judge users can't any
mistakes anymore. In such case we could allow auto-route. That it
searches for a convoyed route as you described.
In such option dialog we could also add the 'StrictNMR' flag.
The reason why I think we should implement it this way, is because
I was thinking how RP could be modified into a real client program.
In such way that you can submit your orders in RP and can also read
directly the results in RP via a protocol on top of HTTP.
In principal Manus Hand is prepared to cooperate with this and generate
the right pages on the DPjudge for this functionality. Of course,
this is a major operation. One of the (smaller) problems is the path
convoys. So, we need a proper solution there (since the user does not
see the orders that go to the server, we can't have a non-robust solution
Back to your question, I think path convoying is something for the first
version after the version your currently preparing. Do you agree?
Currently, I am still busy with my test cases. The basic version is now ready.
I have only to do some HTML formatting and then I will ask people on
rec.games.diplomacy to review it. This task took much longer then I expected
(happy for me, there was no projectleader beating me :-) When I was
digging in the rules I found more and more details and differences between the
1976, the 1982 and 2000 rules. I decided to put the differences in the document
and exactly point on which test cases there different results with the different
rulebooks. This document can also help to identify the differences between
adjudicators when we start to link programs together.
When I finished the document I have still plans to add my own adjudicator
algorithm for the Colonial rules, but maybe I should give the RP client idea