Utility PyEye1.33 dom-III client. Now 3.20 compliant. - Page 4

Jurri · #31 November 26th, 2007, 09:56 AM

Sweet! I'll put it to test tonight

Hey, I thought of a feature that might be fun. (Maybe you wanna close the books on this one already though, seeing how I'm probably the only user

) Anyway, it's this: how about adding a password field for the games? I mean, I have my passwords in a text-file on my desktop , but that's not pretty and well, I launch my server-games through this program anyways. So the query-screen for each game would be a natural place to have the password, or maybe have it show it when you select the play game -option? Anyway, just a thought, certainly the benefit would be limited to such shallow folks like me

WraithLord · #32 November 26th, 2007, 10:21 AM

You are *very* wrong about being the only user, in fact, I estimate there are *two* users to the program

The passwd field is cool, I also have the same awkward solution for my passwords. For this however there are two options:
1. Not safe, save the passwords in plain text
2. Safer, ask for a master password and encrypt the game passwords according to it. The master password will not be saved (duh) and hence is less convenient, but OtOH its safer.

My intuition tells me to go for the 2nd option, but I'm very interested to hear your opinion.

Jurri · #33 November 26th, 2007, 11:07 AM

Hah, at least a 100% error in my guess then!

Of course, I know jack about these things, but how would it be a security risk at all even without any fancy encryption? The text-file with the passwords wouldn't be transmitted anywhere, would it? (Or can you make it input the password via command-line or something? I think not, but that would be even more convenient.)

And anyways, I would say that there's not really any need for security even if there was some scenario where the passwords could be mined: I mean, it's just passwords for games is all it is

Thus, certainly my preference would be for the most convenient and hassle-free option: of course, you could make it optional to encrypt them to side-step the issue by providing both options. That's extra work, though, so in the end you should go with the option you feel more like doing

WraithLord · #34 November 28th, 2007, 05:52 PM

Yeah, I guess you're right. Its just that years working on encrypting stuff can kinda make one a paranoid.

I'll add passwords to the next version, but this will take time since lately work is taking its toll on me.

WraithLord · #35 February 1st, 2008, 08:37 PM

I'm experiencing some issues with the client when working with 3.14 hosts. Mainly it gets confused about nations status. It probably has to do with the upgrade changing something in the protocol itself (not very likely) or on the nations information (numbers for example).

I'll try to get more information on the changes brought by 3.14 and get a fix done (and also add bogarus)

lch · #36 February 1st, 2008, 10:06 PM

Funny, my remote stats script does get the nation status just fine, but it doesn't get the turn number right anymore.

WraithLord · #37 February 2nd, 2008, 05:56 AM

Darn, I just noticed my script doesn't show the right turn number any more as well.

Bad bad script

Maybe I'll try to contact IW and ask about possible changes to the protocol.

WraithLord · #38 February 5th, 2008, 08:45 AM

I have made some more tests with the client against 3.14 server. I could confirm that all the functionality is working except that for human controlled nations it does not display whether or not their turn was played. I'm currently debugging the utility and will release a fix soon.

This fix will also support the nation of Bogarus.

BTW, mod writers that would like their nations to be supported by the utility can PM me or post here with nation #, name, description and a flag icon.

lch · #39 February 5th, 2008, 02:46 PM

Quote:

WraithLord said:
Darn, I just noticed my script doesn't show the right turn number any more as well.

Bad bad script

Maybe I'll try to contact IW and ask about possible changes to the protocol.

Well, I had a quick look why my socket-based PHP script still got the number of players which played their turn versus those that didn't play their turn right - I just counted the Ones for that. Then it dawned on me why the other stuff doesn't work anymore. They didn't change anything about the protocol at all, but they added more nation slots! Instead of 80 possible nation numbers, there's now room for 95. So the tables scale a little differently. Once you change the code to have tables with 95 nations instead of 80, everything is working like it used to.

Off-topic, it's good that they increased the number of nations, but on the other hand, why only so little? 15 more nations, from 80 to 95, that's just raising the bar a widdle bit higher. That's like saying "ok we acknowledge that now it's getting crowded with all the nation slots so we're going to add some more slots, but not too many because we're cool like that". Why not raise it to a sensible power of 2?

Endoperez · #40 February 5th, 2008, 03:33 PM

Good question. You should ask Illwinter, though.