ok, apprently, we are "IRC incompatible" so we'll have to discuss it on the ML :)
> > I didn't use WML because (1) I wanted it to be trivially readable (I > admit that I failed here) so the user can see what's being sent if they > want, and (2) config doesn't seem to guarantee ordering, which makes it > a bad match for logging. > 1) readability was not the problem, the format is quite easy to read... but so is WML. It's more about using existing framework and allowing us to integrate easily with other tools 2) I think it does... we don't use it as such, but I think it does you can alwasy add "date= " flags in each block if you want to be sure > I'll look at it again though since you feel strongly about it. > yes, thx >> 4) how does it interact with MP games and replays ? is it logging >> anything ? in particular the oponents names ? > > It shouldn't do anything in those cases. Will test. > ok, good... we might want to log things about MP games, but best leave that out for the moment >> 5) I don't like the idea of a nag screen, even if it's only at first >> game start, here is a better way to do it >> >> have a checkbox option "Log anonymous data" on by default >> next to it, put two buttons: "clear game logs" and "send logs to >> developers" > > I understand, but I really think the nag screen is required to get > statistically valid stats: putting it in the dialog biasses away from > beginners (the main area I am trying to address). I have a friend who > got to Siege and then gave up on Wesnoth: she simply couldn't get > through it. > > Such information from a newbie who got disheartened is IMHO the most > valuable, and a preferences option wouldn't do it 8( > yes and no... my idea was to have default behaviour be "log, but don't send" so complete beginners would still have their data logged. It's only when they start playing with preferences (which is usually quite fast with players, but that's another flamewar) that they will see that they can change that behaviour. but well... you're the one writing the patch, so the choice is yours > OK. Originally I didn't know where it would be called from, so it would > have had to be a global variable. Since it seems only to be needed in > two places, I'll make it a member of something convenient. > my original idea was to have it be it's own class, but if you find a class in which it fits, even better... hope this helped Boucman > Thanks! > Rusty. > -- > ccontrol: http://ozlabs.org/~rusty/ccontrol > >
