I hate to turn technical but there is no other way to explain it. Here we go:
First I suppouse that actually each time a battle occurs, some data is created into the server (probably a battle ID
with clients involved) that later is compared to each client answer to resolve the results. Even more, the effect of
ALT-F4 is that the client fails to report, so basically ANY REASON that prevents a client to report back successfully
will be indistingishable from the server POV... My idea tries to solve this.
Before, a little notation is needed to avoid confusion:
SERVER(SRV): Dyna server that resolves battle results and generates missions (basically manages the map).
HOST CLIENT(HOC): In the tactical battle, the player that acts as the server that actually RUNS the mission script.
STANDARD CLIENT(STC): The player/s that connect to the HOC to play the mission script.
Now the IDEA:
This could be the typical COMMUNICATION FLOW of a successful DYNA MISSION:
1) SRV detects a battle and offers the involved players the options to enter or forfeit.
2) After a timeout period, SRV know how many players had accepted and how many forfeited (by default a no answer is
interpreted as a forfeit).
3) SRV decides which player act as HOC and the rest will act as STC (The criteria is unknown totally to me).
4) The HOC initializes mission script and waits for ALL the STC to connect to him (should report back to SRC how many
players STARTED the mission successfully).
5) The battle flows and ends properly, HOC reports back, to the SRV, the mission results of ALL STC and communicates
the individual results to each STC.
6) SRV will update prestige/disrepute of the involved players based on the information reported by the HOC.
Before continuing to the real cases... Where ANYBODY can loose it's connection, a note on HOC selection. Could be used
a hydrid "credit system" based on the amount of successfully ended missions and the detected ping from the server POV
(The ping method is not reliable... but it's an extra information... in the case of a draw). So each time a battle
starts SRV will chose the HOC from all the players involved based on which player has reported back more missions as
HOC, and in the case of a draw, the one that has better connection to the SRV (i.e. lower ping).
K, now the connections problem, first I will not enter on what happens if the HOC fails... Actually it's managed by
Taldren's code more or less elegantly so let's analyze what could be done to distingish between different STC
problems:
a. STC failed to join the HOC but was registered in the SRV as one of the accepting players.
b. A STC has suffered a connection loss from the HOC (and probably from the SRV also) during the mission.
c. A STC has suffered a critical bug that forces an INVOLUNTARY exit (I'm talking here of a total crash and things
like that).
d. A STC has issued a VOLUNTARY exit (via ALT-F4 or KILLING the process). It's important because this conditions COULD
be detected FROM INSIDE the program, while c. is more difficult to achieve (but not impossible
).
K, now let's analyze what the HOC can detect about the former problems:
I. A connection loss during the combat (that includes b.,c. and d.; but for d. you can send additional data).
II. A STC failed to join the mission (the a. case).
Now, imagine that when the server offers a mission to a player, sends also to his client the Battle ID so the STC
knows this IMPORTANT thing for later use, k?.
Now, if the SRV keeps the Battle ID where some problem arised (during a period long enough for a player to reconnect
from a TOTAL disaster (need to reboot and things like that) let's say... 5-10 minutes) and then forces the problematic
client to send what happened with that Battle ID, then the SRV could make the right decission.
If you combine the previous mechanism with the actual situation, if a player ALT-F4, the HOC reports a failed connection
to the SRV, so the SRV keeps the Battle ID waiting for the offending STC to connect back before aplying the penalty
(notice that the rest of the players will continue going without problems because the result of the battle was clear)
only the decission on the penalty to apply is delayed.
Well this mechanism could be perfectioned with additional info from the STC in the case that the HOC fails (or ALT-F4)
but the general idea is allowing POST battle results analysis.
Maybe it's too complex to include in a patch (but I'm reasonably sure that some of this mechanism exist already),
but in SFC4, who knows?
.
P.S. As usual, excuse me for the length and the barbaric english
Topic: An Advanced Solution for ALTF4'ers (Read 1155 times)