Topic: Online Campaign Interface (OCI) Feedback

[Hexx]

Not that I'd ever think about abusing the system(and keeping in mind I really haven't looked at the details).. but

say some pilot without honour or a soul even (call him Dfly) decides that he needs to have more PP than anyone.

Create account (Dfly)
Creat a 2nd account (Dfly1)
Log in (Dfly1)
Has 2K prestige to start
uses webyard to buy smallest ship possible (@400 pts)
sell current ship (for 2K+/-)
Now has an account with @3600 prestige.
Transfer pp
Logout
Create account (Dfly2)
rinse
repeat.

OR abuse version 2.0

Remember one race always seems toi have a starting ship worth several k more pp on trade in than anyone else.
With the ability to flip accounts around it wouldn't be hard for the alliance to notice that say (for example) the Gorn starting ship
was worth 2k more than anyone elses. So everyone starts off in a Gorn ship, sells it right away and banks 2K prestige faster than even one of those DF's can bang out a mission .

Really it seems like a very cool setup . Just throw a rule in that bans players who create more than one account.

[Lepton]

Ya, good ideas, Lepton. We are ALL about automation here, bro. Less work = more fun. But we have been all over this issue like flies on sh*t. But check out the kills page and tell us how the format looks. We just threw up a concept job to do what we need it to do. Suggestions on that?

Well, I think the obvious complication is that PvP whores like yourself won't remember when and where and how many PvP battles you have been in that may or may not be worth VCs.  Are you going to want to stop after every VC-worthy PvP battle to do some data entry on the site?  What if disengagements were worth VCs??  The problem grows exponentially at that point.  Further, I think players are not going to remember their ship names if this indeed is required information to make the battle report.

I don't know the capabilities of the application, but I would think that merely pulling up the kills pages should bring up any unconfirmed PvP battles based on your dynaverse forums id which is hopefully tied in some manner to the dynaverse server id for your character. Select the PvP battle you wish to confirm from a select list.  Info is automatically populated via DB qurey. Check facts.  Hit confirm.  You're done.  Other side is required to confirm the battle as well.  VCs are recorded and tallied.

That's still quite a bit of clicking to do and typing to do, but it would seem that if the information for PvP battles can be reliably queried from the DB then it may not be necessary to report the VC battles as soon as they are concluded.  That seems to be the real problem as drops and bugged missions are also potentially queried out.  If I knew the structure of the tables and the manner if which the server kits logs such analomous battles, I might be able to make a suggestion but as I do not, I can only say that it would seem to bn a vast improvement over manual entries on the forums that need to be tallied manually.

[Hexx]

Oh man I just looked at it- Bonk you are a firckin genius!!!! (can I say firckin?)

No more having to count up stupid hexes as an admin! Just call black holes worth X vp, asteroids Y vp each and do the math.

It's brilliant!

[Bonk]

Bonk,

I am curious if you can create temporary tables within the MySQL DB that supports the dyna in which events might be logged such as PvP battles. As the battles are logged in this table, they can be confiirmed at the players leisure without having to hit a number of tables with a complex query.  PvP battles once reported could potentially be deleted from the table if the tally were only important detail which might be held in a separate table or even in some global variable.

Yes that could be done, but would have to be done from within the mission script. Like the way DarkElf's Economic missions altered the economy of a hex, such an SQL enabled mission could just as easily report PvP info to another table, but spilt missions may or may not still be a problem... (nah one could account for that in such a script). Since MySQL 5 now has triggers and stored procedures, one could also use those facilities to detect PvP missions but they would be subject to the split mission issue.

But you have given me the idea ot run a scheduled script to analyse the battle logs and then summarise it in a nice small table to display on a webpage from a scripting language.  Good thoughts... no way I'll get that done for SG6 but I'm definitely filing all these ideas for future reference. 

[Bonk]

Not that I'd ever think about abusing the system(and keeping in mind I really haven't looked at the details).. but

say some pilot without honour or a soul even (call him Dfly) decides that he needs to have more PP than anyone.

Create account (Dfly)
Creat a 2nd account (Dfly1)
Log in (Dfly1)
Has 2K prestige to start
uses webyard to buy smallest ship possible (@400 pts)
sell current ship (for 2K+/-)
Now has an account with @3600 prestige.
Transfer pp
Logout
Create account (Dfly2)
rinse
repeat.

OR abuse version 2.0

Remember one race always seems toi have a starting ship worth several k more pp on trade in than anyone else.
With the ability to flip accounts around it wouldn't be hard for the alliance to notice that say (for example) the Gorn starting ship
was worth 2k more than anyone elses. So everyone starts off in a Gorn ship, sells it right away and banks 2K prestige faster than even one of those DF's can bang out a mission .

Really it seems like a very cool setup . Just throw a rule in that bans players who create more than one account.

Ah I gotcha, thanks for the detailed explanation.

I'm definitely going to add a configurable "Tax" and limit on PP transfers so that tranfers can be taxed and limited to a maximum value that the admin chooses. That should cover it.

Also, it would not be too hard to spot excessive abuse of it and simply ban the player by IP address if it came right down to it. I'm sure most here are quite honourable and wouldn't cheat like that. Where's the fun in that?

[Bonk]

Oh man I just looked at it- Bonk you are a firckin genius!!!! (can I say firckin?)

No more having to count up stupid hexes as an admin! Just call black holes worth X vp, asteroids Y vp each and do the math.

It's brilliant!

Yes you may...  Though it is probably not true...

The latest flatfile webmap also has the map summary page so that feature is available for plain old flatfile servers too.

[Lepton]

Not sure why you would need a special mission to generate the PvP entry into a PvP battle table.  It seems as if you are able to query out those instances now from the DB in the manner you utilize in the destroyed ships procedure.  Yes, I would use a stored procedure or other scripting method to trigger a query of the DB for recent PvP battles, add those to the PvP battle table and you are set.  The query could be run periodically, every half hour or so.  The data need not be on demand if the information can be queried accurately, then the player woulkd merely need to confirm what the database has already assessed to be true. 

I have never done anything with SQL or PHP like that.  My experience is limited to simple mysql queries to generate dynamic content via php, but I am sure you are capable of executing what I am sure you are already thinking of.  Good luck.

[Bonk]

Yes, I understand what you are saying, I did start on that once (SG5), but got bogged down and took the lazy way out this time. I would like to get it automated at some point.  Though it would be nice to get some SQL enabled missions going at some point - lots of potential there, and I could pass the buck on some stuff. 

RE: PP transfer abuse: I just thought of a solution to the proposed abuses - rather than just a tax and maximum transfer - add a configurable MINIMUM PP transfer so that it can be set to a value greater than the sum of the starting PP and ship - problem solved! 

[Midnight Tech]

One word: WOW! Bonk, you have outdone yourself with this....congrats on the hard work!

[Hexx]

RE: PP transfer abuse: I just thought of a solution to the proposed abuses - rather than just a tax and maximum transfer - add a configurable MINIMUM PP transfer so that it can be set to a value greater than the sum of the starting PP and ship - problem solved! 

Yeaahh.. not sure if this works for me..

Those Fed CVA's are usually kinda pricey you know?

[Dizzy]

Bonk that wont work either. All the main account has to do is transfer a few bucks to the second account and bring it up to the required transfer level and they pocket their 2nd ship pp and the starting pp.

You have to have a pp transfer charge. It has to equal the starting cash and ship trade in.

[Bonk]

I will put in configurable minimum, maximum and taxes on the PP transfers, between these we should be able block it for the most part. And like I said, if we suspect it is happening, I can just search the character table by IP address and if I see indications of the exploit, ban the player by IP address (and e-mail if necessary). I don't think its that big an issue, as it can be easily detected and stopped if it happens.

[Riskyllama]

A nitpick of mine from the original that i never voiced was the defense layer, it seems to rate each hex's defense value on the server's maximum. Then again this might be how you intened it to act. If all hexes had a uniform max this would be ok(in my mind), but on the forge, with some hexes topping out at 10 and some at 100, it gets hard to tell by the webmap if a hex is at maxDV or not, since maxed hexes with a 10 maxDV show the same color as a hex at 10dv out of 100max. 

On a slightly related side note, I hope the preceding run on sentence made some sense...

Also is it possible to have colors instead of shades of grey? The middle two grey look kinda close to me sometimes.

[Bonk]

A nitpick of mine from the original that i never voiced was the defense layer, it seems to rate each hex's defense value on the server's maximum. Then again this might be how you intened it to act. If all hexes had a uniform max this would be ok(in my mind), but on the forge, with some hexes topping out at 10 and some at 100, it gets hard to tell by the webmap if a hex is at maxDV or not, since maxed hexes with a 10 maxDV show the same color as a hex at 10dv out of 100max. 

On a slightly related side note, I hope the preceding run on sentence made some sense...

Also is it possible to have colors instead of shades of grey? The middle two grey look kinda close to me sometimes.

I think I understand what you are saying.

I used a cold to warm color scale in the past and Dizzy and I decided it was too busy looking and went with a greyscale instead. I think I'll keep it that way. (Using colors for the filter made it too hard to see the hex borders that indicate hex ownership.)

The greyscale is five shades:






Check out my monitor calibration poll if they look too similar. Though I could try adjusting the scale, or I could put a small number on the grayscale images...

Hexes are then rated as a percentage of the highest current DV hex on the map and assigned an image. The Defence filter is based on Current DV and not Maximum DVs. 

I added the Maximum DV to the tooltip popup text on the Admin map editor version, I suppose I could do the same for the main map, that way you could just hover the mouse over a hex to see its max DV... Alternatively I could add a filter for Maximum Defence in addition to Current Defence... which do you think would be better?

[Dizzy]

5 are fine and the colors are good. About the maximum regular DV you'll see on SG6 is 15. Most start at 10. Some are as low as 3. So if your shading followed in 3's... we'd have 0-3, 4-6, 7-9, 10-12, 13-15 to top it off.

[Bonk]

5 are fine and the colors are good. About the maximum regular DV you'll see on SG6 is 15. Most start at 10. Some are as low as 3. So if your shading followed in 3's... we'd have 0-3, 4-6, 7-9, 10-12, 13-15 to top it off.

The code excerpt concerned:

Code: [Select]

<?php
$maxdv = max($dv);

if($FNmtype == "Defence"){
$hexhtml .= "<img border=0 src=$ociroot/images/hexUL";
$hexhtml .= round(($FNdv/$FNmaxdv)*5);
$hexhtml .= ".gif width=$FNimgwidth height=$FNimgheight ";
$hexhtml .= "style=\"position: absolute; left:";
$hexhtml .= $FNtx;
$hexhtml .= "; top:";
$hexhtml .= $FNty;
$hexhtml .= "; z-index: 1\">";
}

?>

Hardcoding to DV ranges instead of percentages in 20% increments as above would require editing the map code for every server or a considerably more complicated approach and another set of OCI configuration parameters. It is going to remain as an incremented relative scale.

[Bonk]

Configurable PP transfer limits applied:

Code: [Select]

<?php
$usePPtransfers = 1; // Allow character to character prestige transfers, set to zero to disable
if ($usePPtransfers == 1) {
$PPtransfersMin = 6000; // Minimum transfer
$PPtransfersMax = 1000000; // Maximum transfer
$PPtransfersTax = 10; // Transfer service charge in percent, charged to donor
}
?>


[Bonk]

At Dizzy's request ( ), I have modified the ship assignments code such that the assignee is debited the value of the assigned ship (and thus must have sufficient PP for the assigned ship) and RMs may assign a ship from any allied playable race to any allied player (admins may assign a ship from any playable race to any player - though I could open that up to non-playable races as well I think...).

[Bonk]

By filter I actually meant a mandatory filter that would prevent you from seeing where the enemy is attacking, and who is winging together. As is it shows a little too much info IMHO.

I agree with tool. I dont want info available to one side that will show where your enemy is.

(Player location display is already disableable with one parameter for the roster and who's online pages... so that's covered)

I think it makes the most sense to make the Recent Battles and Destroyed Ships pages disableable by configuration parmeter and just disable them for SG6. You can always find out what is going on with your side by asking for the news on teamspeak. Or just take a look at the server news where its all there to see anyway. It would be a hassle to move those pages into the Player controls and filter out all battles that any enemy players have participated in...

Oh wait, I just had an idea! What If made those pages only display battles more than say an hour old... (or a configurable time interval) would that do?

[Dizzy]

$PPtransfersTax      = 10;            // Transfer service charge in percent, charged to donor

I'd rather have a flat rate.