Soldat Logstat development - statistics program

[Xxypher]

Hmm, yes that's even a better idea.

I've got yet another question. Currently, the program should fit in a 640*480 screen resolution. If no-one here uses that old screen resolution anymore I could take it up to 800*600 so I can make those bars a bit wider, which will make the difference between them alot clearer. What do you think?

Grtz, DePhille

I use 1024x768, a very widely used one...

[FliesLikeABrick]

that's a whole bunch of work to do in Visual Basic. There are currently already over 200 controls in the program, and making it scaleable would require me to calculate a relative width and height for every one of them.
I'll switch to 800*600 though.

It only brings one extra problem: How should I fill the general statistics now?

Grtz, DePhille

I don't have a client installation anywhere (I'm on Linux-only for the summer, my windows installation got screwed up and I don't care to fix it until I have to), does the client log console stuff or only kills (still)?  I know it used to be like this but I'm not sure if it does or not

[Xxypher]

Can... I test this for you?
I WANT IT!

[DePhille]

Yeah, beta-testers are very welcome once the beta-version is released.

The Soldat Client is logging both kills and the console, however, it makes a new file for the killlog everytime you restart Soldat. This does not apply for the consolelogs, it just overwrites the existing ConsoleLog.txt.

1024*768 is indeed widely used, but there are around 10% who still have 800*600 though.

Yes, everything is pretty simple to implement, except for the player specific data. In PHP I could use arrays: $playerstats[$player]['kills']++; which doesn't work in Visual Basic. So I'll have to look for a very short and fast alternative there.

Grtz, DePhille

[urraka]

I'm up to help you test it. Just for you to know

[DePhille]

Alright, thanks alot
I'm thinking of already opening up the program for some beta-testers, though it will slow down the development a bit.
Add me to MSN if you're interested:
DePhille -at- hotmail -dot- com

Grtz, DePhille

Date Posted: 29-06-2007, 14:41:19Okay, some updates in the development process.

First of all, I launched the beta-testing. I made a public discussion for the beta-testers on SoldatPage: LINK.
I will keep this topic updated however, but all the small changes will be posted in the discussion above and when they've piled up I'll post them here.

Secondly, I managed to fill up the general statistics window.
I made a statistic breakdown of every single logfile along with the kills and suicides found in them. Since the logfiles have a date in their name you can also use it to see how many kills you made that specific day. I've also optimized the program for 800*600 resolution.

Grtz, DePhille

[Xxypher]

Since every time I try to get on MSN it times me out every 3 minutes...
Its been like that since I got 1.4.1 =O

[HeisGetRaeNk.]

It would be nice, if there was the ability of letting the program add all the bots names from Soldat\Bots to the "Excluded Soldat nicknames" List, so there won't be all those annoying entries from testing new maps,mods etc. with bots.

[jbigz]

Or move to VB.NET
Scaling is so automatic there. Oh, and everything is so easy to do lol

So, if you got, say 153 Deagle kills, that would be considered 100%

If you got 39 knife kills and 21 grenade kills, how would the program determine the percentages?

153kills -> 100%
39kills   ->  X

X = 39kills * 100% = 25,490196078431372549019607843137%
           153kills

A small problem with your calculations resulted in a number that is ENORMOUSLY too big.
simply do 39/153. That takes you to that big decimal. Move the decimal over twice, tada:
25.490196078431372549019607843137%; not with a comma x]

[SpiltCoffee]

Or move to VB.NET
Scaling is so automatic there. Oh, and everything is so easy to do lol

So, if you got, say 153 Deagle kills, that would be considered 100%

If you got 39 knife kills and 21 grenade kills, how would the program determine the percentages?

153kills -> 100%
39kills   ->  X

X = 39kills * 100% = 25,490196078431372549019607843137%
           153kills

A small problem with your calculations resulted in a number that is ENORMOUSLY too big.
simply do 39/153. That takes you to that big decimal. Move the decimal over twice, tada:
25.490196078431372549019607843137%; not with a comma x]

Uh... mate... Europe uses a comma, not a point, for their numbers.

[truup]

In PHP I could use arrays: $playerstats[$player]['kills']++; which doesn't work in Visual Basic. So I'll have to look for a very short and fast alternative there.

Grtz, DePhille

In VB you have to use types, for example:

Code: [Select]

Private Type TPlayer
    kills As Integer
    deaths As Integer
End Type

Dim Players() As TPlayer

Private Sub Form_Load()
    Players(1).kills = 10
    Players(2).deaths = 234
End Sub
You should get the idea by that.

It says here that it may look like it is not responding, so maybe you should use DoEvents inside your loops, for examle:

Code: [Select]

    Open "C:\logfile.txt" For Input As #1
    Dim line As String
    Do Until EOF(1)
        Line Input #1, line
        'parse the line
        DoEvents
    Loop
    Close #1If you do that, then it shouldn't look like it's not responding. You may want to put it almost in every loop that uses CPU a lot.

Uh... mate... Europe uses a comma, not a point, for their numbers.

In nearly every programming/scripting language you use . instead of , and that's because almost every function separates its arguments by a comma. For example, if there was a function that changes between currencies, it could be something like this (in VB):

Code: [Select]

The proper format would be ConvertCurrency <value>, <from>, <to>

So it would be like this:
ConvertCurrency 12.50, EU, US

Instead, if you use a comma instead of a dot, it would be:
ConvertCurrenct 12,50, EU, US
So it would give 50 as a flag for the function.

-
asd

[chrisgbk]

In VB you have to use types, for example:

Code: [Select]

Private Type TPlayer
    kills As Integer
    deaths As Integer
End Type

Dim Players() As TPlayer

Private Sub Form_Load()
    Players(1).kills = 10
    Players(2).deaths = 234
End Sub


Forgot the ReDim to redimension the array before accessing it

[DePhille]

Thanks all for the help!

What I meant with the PHP example is that I could use $players[$playername]['kills']++; where $playername is a string. This way I don't have to see if there already is an entry for that player and I can just add one to kills, deaths, suicides or whatever other value. The types might come in very handy already, though I'm still looking for something similar to the PHP-method, as it won't increase the parse-time alot. If I have to look up every name in every entry to see if it's already in the TPlayer array the parse time would be several minutes instead of one second.

From what I've found on the internet, named arrays (or any equivalent) do not exist or are not possible in VB. However, I'm leaving this idea open for a few days, and if nothing comes out I might be thinking of having a long parsetime but saving the results instead of parsing all logs again (which will also be a pain in the ass, especially because I'd have to ship alot of OCX controls with the final release in order to avoid errors).

Also, since the lack of interest for the beta-testing, I'll be launching a public beta-test (see main post).

Grtz, DePhille

[urraka]

Uh... mate... Europe uses a comma, not a point, for their numbers.

In nearly every programming/scripting language you use . instead of , and that's because almost every function separates its arguments by a comma. For example, if there was a function that changes between currencies, it could be something like this (in VB):

Code: [Select]

The proper format would be ConvertCurrency <value>, <from>, <to>

So it would be like this:
ConvertCurrency 12.50, EU, US

Instead, if you use a comma instead of a dot, it would be:
ConvertCurrenct 12,50, EU, US
So it would give 50 as a flag for the function.

When I posted that I wasn't talking about coding, I just did the calculation with windows calculator and pasted the result here. So SplitCoffee made a good point, even though I'm not from Europe
But same rules apply in my country.


About the speed and VB... i'm afraid VB isn't too friendly with speed. If you want something fast use C/C++. Maybe there is a way to make a dll for the parsing job, and use vb just for the interface. I know it can be done, but right now i wouldn't know where to start

[chrisgbk]

Thanks all for the help!

What I meant with the PHP example is that I could use $players[$playername]['kills']++; where $playername is a string. This way I don't have to see if there already is an entry for that player and I can just add one to kills, deaths, suicides or whatever other value. The types might come in very handy already, though I'm still looking for something similar to the PHP-method, as it won't increase the parse-time alot. If I have to look up every name in every entry to see if it's already in the TPlayer array the parse time would be several minutes instead of one second.

From what I've found on the internet, named arrays (or any equivalent) do not exist or are not possible in VB. However, I'm leaving this idea open for a few days, and if nothing comes out I might be thinking of having a long parsetime but saving the results instead of parsing all logs again (which will also be a pain in the ass, especially because I'd have to ship alot of OCX controls with the final release in order to avoid errors).

Also, since the lack of interest for the beta-testing, I'll be launching a public beta-test (see main post).

Grtz, DePhille

You need to remember that in PHP, an array isn't -really- an array, it's an ordered map. That is why you can have virtually any value as an index.

Using a binary search, you can decrease the time it takes to find an entry in an array by a lot, but that requires you to know how to do that.

You can also do other things, such as hashing names and using the hash to access an array, but using VB it's still going to end up very slow.

[DePhille]

Yeah, and I don't see the gain in studying C/C++ just yet, I'll have enough time to do that when I go to university .
Anyway, PerroAZUL posted a nice list of bugs on the SoldatPage forums, which I'll look into asap! Thanks!

Grtz, DePhille

[The Philanthropist]

Er, I don't have a kill log in my kills folder.