New Partymine sugesstions

[Jeff W]

[ QUOTE ]
Also, I assume you are aware that it's possible to open multiple instance of the party software without multiple windows accounts? Just click the icon really fast. It's not compatible with PartyMine.

[/ QUOTE ]

Yep, I'm aware of the trick, but it's easier to use Partymine.

[teddyFBI]

1) Yes, even at 99 minutes, the auto-import is triggered before the previous one has finished (as i mentioned, it takes 2-3 hours sometimes

2) Jeff W: can you tell me more about the multiple-XP-user-accounts option? I've never really understood the user account thing, nor how I would take advantage of it to mine a lot.

3) Supa: about auto-moving the HHF files...I don't think that's necessary: let me explain. Nor, by the way, do I think this requires a choice between Real McCoy's two options...I think the ideal program is one that looks and acts just like PartyMine, except can recognize multiple instances of the Party client. I use my copy/paste workaround because I have found that with the number of tables I have open (80 or so), the auto-import process can't run smoothly. But for others who only want to mine 30 or 40 and whose autoimport process runs just fine, well then nothing needs to be moved, right? Now, the reason that even high-vol miners like me don't need anything moved automatically is because of how the HHF files are spawned and edited.

For example, if table XYZ is opened by your mining program when it has 9+ players, then XYZ.hhf is spawned in the party parent directory. If the # of players drops to less than 9 and table XYZ is closed, the HHF file does not disappear. It stays until the client is closed. Now, if the # of players then INCREASES back above 9+ and XYZ is RE-opened, then Party does not spawn a NEW XYZ.hhf, but rather just adds text to the XYZ.hhf that it created the FIRST time that table was opened. Anyway, this means that Party never creates more than 80 or 100 hhf files, even if tables are closed and re-opened.

Actually, I have no idea what the above paragraph has to do with anything, but the take home message is that I just don't see the point of having an auto-move feature...it takes about 30 seconds for me to do, and I actually like having that level of physical control over my HHF files to trouble-shoot, etc.

Like other posters have said, just get basic functionality operable, let me and a few other beta testers loose on it, and we'll go from there.

4) more name suggestions: TeddyMine, MetaMiner << pick this one, MegaMiner, GigaMine, TeraMine, InfiniMine.

Well the main reason I suggested that it could be done automatically is because its a really simple task. But yes I'm working on the basic functionality first and will phase in anthing else that could be included.

[teddyFBI]

[ QUOTE ]
Well the main reason I suggested that it could be done automatically is because its a really simple task. But yes I'm working on the basic functionality first and will phase in anthing else that could be included.

[/ QUOTE ]

I just want to make sure you realize that you actually CAN'T move the HHF files while the Party client is still open because they're still 'in use' (even if the table itself isn't open anymore), so it won't let you move them. That's why you need to copy and paste them to a new folder.

[ QUOTE ]
[ QUOTE ]
Well the main reason I suggested that it could be done automatically is because its a really simple task. But yes I'm working on the basic functionality first and will phase in anthing else that could be included.

[/ QUOTE ]

I just want to make sure you realize that you actually CAN'T move the HHF files while the Party client is still open because they're still 'in use' (even if the table itself isn't open anymore), so it won't let you move them. That's why you need to copy and paste them to a new folder.

[/ QUOTE ]

I can delete HHF from games that have finished and the table has been closed.

[teddyFBI]

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
Well the main reason I suggested that it could be done automatically is because its a really simple task. But yes I'm working on the basic functionality first and will phase in anthing else that could be included.

[/ QUOTE ]



I just want to make sure you realize that you actually CAN'T move the HHF files while the Party client is still open because they're still 'in use' (even if the table itself isn't open anymore), so it won't let you move them. That's why you need to copy and paste them to a new folder.

[/ QUOTE ]

I can delete HHF from games that have finished and the table has been closed.

[/ QUOTE ]

i stand corrected.

Good news today I've managed to make a ton of progress...Going through and testing some of the specialty mining 6max, nl, pl etc. Should have something for you guys to see real soon and you can start tearing it apart...

[Jeff W]

[ QUOTE ]
1) Yes, even at 99 minutes, the auto-import is triggered before the previous one has finished (as i mentioned, it takes 2-3 hours sometimes

[/ QUOTE ]

Strange. Are you importing the actual hand histories along with the stats?

[ QUOTE ]
2) Jeff W: can you tell me more about the multiple-XP-user-accounts option? I've never really understood the user account thing, nor how I would take advantage of it to mine a lot.

[/ QUOTE ]

It's basically a way to open multiple Party accounts in a way that you can automate datamining w/ PartyMine. The bug where you can open multiple party clients is superior for maximum mining, but it's incompatible w/ PartyMine.

[teddyFBI]

[ QUOTE ]

It's basically a way to open multiple Party accounts in a way that you can automate datamining w/ PartyMine. The bug where you can open multiple party clients is superior for maximum mining, but it's incompatible w/ PartyMine.

[/ QUOTE ]

But in order to be use this method, you have to have more than one Party account right? Unless you just want to have 4 tables on each XP user account...right?

[Jeff W]

[ QUOTE ]
But in order to be use this method, you have to have more than one Party account right? Unless you just want to have 4 tables on each XP user account...right?

[/ QUOTE ]

Yes.