Another Broader Rule Question...Logic in motion..

[Krusty]

Perhaps we are misunderstanding.

Perhaps the folks that ought to weigh in are the ones that have to review all the logs. The CMs and so forth.


I think a reporting tool would be nice. However, the way in which you describe it seems (to me) to have far-reaching implications into the rules and makeups of all future scenarios.

Hence my caution.

[oneway]

I was trying to land upon a phrasing or wording I had in my mind to describe it, but couldn't. Now I've realized what I wanted to type:

Lost potential. Player X shoots down Player Y. Had X not broken the rules with 1 extra life, player Y could, would, should, have accomplished his mission, gains countless kills, bombs, points for his team, perhaps even single handedly saved the entire campaign.


How do you even predict that to score a penalty in the first place? Answer: you can't. You have to move on, give a warning. If it repeats penalize or boot the player X.

It's such an intangible thing that logic really can't compute the impact of any one given event. It's all subjective.

Look at Snaphook intentionally missing a bomb near a GV, not causing one iota of damage. Look at the subjective outcry of whining on the forums afterwards. Logically it's absurd....

but it happened 

You cannot account for something that didn't happen...only that which did...if a player in an invalid sortie kills a player...the dead player is as dead as he would have been without a tool...nothing has changed...

My argument is that the invalid act should not be counted or accredited...

This is not about PENALTY...

This is about denying REWARD...

To some people denying REWARD is synonymous with ASSESSING PENALTY...I don't see it that way at all....

To take away a kill from a pilot flying an invalid sortie, or take away destroyed object from a pilot that dropped on an inactive target is not a PENALTY....

You want to talk penalty...that is available too down the road...if one wants it...in other words if you kill a guy on your extra life...its going to subtract 5 kills from your TEAM

NOW THAT'S A PENALTY...

LOL

Oneway

[Strip]

That in fact is not a problem at all...the user of the program sets up the more variegated rules such as a certain squad can kill ground vehicles...in your case the fact you killed a ground vehicle (be it friendly or not) is totally irrelevant...

Only the chosen squad kills of vehicles are counted as kills. As to the kills your squad got on vehicles...the squad is not penalized at all...the program would simply look at the killer of the vehicle, and check whether he was authorized to kill vehicles...in fact the program checks what type of vehicle was killed, by what type of aircraft, in what squad...

Ultimately in the final stat crunch, your kill of the vehicle is simply marked as invalid...no penalty whatsoever to the pilot of the squad...your kill of the vehicle is simply not a kill, doesn't count as a vehicle destroyed/lost...everything else in your sortie is valid...as long as it was a valid target or valid kill by other params...unless of course you took off from the wrong field, wrong plane...then everything you did was invalid...and whether you killed a vehicle or not becomes irrelevant...you shouldn't have even been the air with that plane or from that base...

The logic flawless...and is not interpretable by humans...it simply looks at the guy, what he did, checks the rules...and then acts...

Lets go further...let say a pilot ups the wrong plane from a field...the program could care less...unless or until the pilot actually does something with that plane...in other words...normal human errors of upping the wrong field or the wrong plane is completely ignored...UNLESS...that invalid sortie has a consequence...such as a kill, assist or an object destroyed...

Thus...guys who grab the wrong plane...and figure out their mistake and land...NO CONSEQUENCE...NO EVENT OCCURRED...

I carry that logic forward with the Multiple Lifers...if  guy ups 20 times in an event...totally irrelevant...all that is relevant are his actions and consequences. In other words some nooby who ups an extra half a dozen times and crashes and bails...is nothing...but if some veteran grabs an extra ride by honest mistake...and goes and kills 5 guys...tough luck for him...no points are awarded the team...

Its perfectly equitable...the logic works...

Mistakes have consequences, leadership has responsibility...as it is in real life, so should it be in our scenarios...

Oneway

By the rules a B-25 killing a vehicle near a structure is very much a valid target and should count as such. There in lies the problem with an black and white program, it cant easily decipher a situation like that. It either is or it isn't, technically B-25s are not specifically allowed to target vehicles per the rules. Without context (film or screen shot) the only way to separate valid from invalid is to look for structure kills in the same time frame.

Ultimately the kill Beefcake described is valid....your logic is not as flawless as it might seem. I appreciate what your trying to do, but like Beefcake I dont want see a Florida recount every frame.

Strip

[oneway]

Perhaps we are misunderstanding.

Perhaps the folks that ought to weigh in are the ones that have to review all the logs. The CMs and so forth.


I think a reporting tool would be nice. However, the way in which you describe it seems (to me) to have far-reaching implications into the rules and makeups of all future scenarios.

Hence my caution.

Your caution is both warranted and prudent...

That is exactly why I posted this...

This is a powerful tool...and will be an Open Source Code ...totally public ...in fact if AH is interested, we could have an Open Source forum in the BBS and create an awesome tool that benefits everyone...sharpens our game and events...

A collaboration of both coders and non-coders, gamers and anyone else interested...owing the product...

We can change the dynamics for the good here...

That is my goal...

Oneway

[Krusty]

Oneway:
"My argument is that the invalid act should not be counted or accredited"

For pure points-related computations, I'm all for that! But one guy ups a 262 and downs 5 B17s in it, that he should not have, right? Sure, he doesn't get any points if the tool rules it "invalid" -- but he's done the damage, the B17s just barely miss the points they needed to win the war, the pilots lost their lives, can't help out anymore.

I would say just denying reward isn't always going to suffice. Probably a lot of violations need to be reviewed. Much like GVs in a scenario, a single pilot doesn't exist in a vacuum. While you can negate his points on invalid missions, what about those he interacts with? Can you think of some way to take the ripples into effect?

Strip: Florida recount!  

It is possible that with something like this, cut-and-dried, all things on the table, that there won't be a need for any recounts or quibbles. On the other hand, it could lead to nit-pickery, devolution of the esprit d' corps that is part of the scenario atmosphere. It depends on how much impact such a report-generating-tool has. If we turn over all control to it, I would be afraid. If, on the other hand, CMs still tally scores, and this is the "suggested automatic penalty report" that they can weigh, pick, and choose, then I would be much more comfortable with a human still in control.

Back to oneway:
"We can change the dynamics for the good here..."

See that's what scares me. A social dynamic like that which supports scenarios is fragile. You start monkeying with it and bad things can happen. All of a sudden scenarios leave a bad taste in participants' mouths, or they lose interest in the next one, or something negative drives them away. Any changes should be small, unintrusive, and subject to revocation if deemed unfitting. In other words, baby steps. Many increasing layers of baby steps.

[oneway]

By the rules a B-25 killing a vehicle near a structure is very much a valid target and should count as such. There in lies the problem with an black and white program, it cant easily decipher a situation like that. It either is or it isn't, technically B-25s are not specifically allowed to target vehicles per the rules. Without context (film or screen shot) the only way to separate valid from invalid is to look for structure kills in the same time frame.

Ultimately the kill Beefcake described is valid....your logic is not as flawless as it might seem. I appreciate what your trying to do, but like Beefcake I dont want see a Florida recount every frame.

Strip

Try not confuse program logic with your own interpretation of the rules...

If you want it to be OK to bomb Koko the Clown we can make that OK too...and when you do the logic will be flawless because the variable StripCanBombKokoTheClown = True == True...

Regards

Oneway

[Strip]

Krusty,
I would agree, scenario players can be a finicky beast, one only needs to look at Snaphooks bomb incident. A report that gives CM's a place to look would be an excellent idea in my eyes. How they would use it would ultimately up to them, but without oversight I would feel uncomfortable. For a black/white program to have a primary role in scoring it would open to door to some issues.

Oneway,
Thats not my interpretation of the rules, that is how they are stated in the rules. Seeing how your intent on enforcing the rules you might consider that in between your humorous wisecracks.

Funny guy....

Strip

[oneway]

Krusty,
I would agree, scenario players can be a finicky beast, one only needs to look at Snaphooks bomb incident. A report that gives CM's a place to look would be an excellent idea in my eyes. How they would use it would ultimately up to them, but without oversight I would feel uncomfortable. For a black/white program to have a primary role in scoring it would open to door to some issues.

Oneway,
Thats not my interpretation of the rules, that is how they are stated in the rules. Seeing how your intent on enforcing the rules you might consider that in between your humorous wisecracks.

Funny guy....

Strip

The rules are the rules are the rules...

They can be anything you want if your the designer...

Perhaps we could put this to bed by simply stating in the future rules:

Multiple lives are not OK
If you up a multiple life your team will be penalized 1 point
If you bomb 10 objects while on your multiple life sortie, your team will earn 10 points
Multiple lives, while not OK, are are sure to win n-1 points where n = points gained.
Thus, multiple live sorties are max -1 points, and unlimited positive points for the Team
Have at it...enjoy your Scenario Experience!

Or how about this...

You must fly from an active airfield
If you decide not to, nothing will happen
Everything you destroy counts
Everything you kill counts
If the CM forgot to shut down aircraft at V-Bases thats ok too
Up them all you want and kill anything you want
There is no penalty and your TEAM WINS the points
Have at it...enjoy your Scenario Experience!

Focus on what I am trying to do here...

Oneway

[Strip]

Well, like anything else with Aces High sometimes the only way to find an outcome is gather your marbles and give it a shot.

The inverse what your saying is true to though....

If you code the program logic one way (pardon the pun) and the designer wishes to deviate from them you run into issues there. There are certain situations that will crop up and you may need to add to or modify the program. If you can program a user selectable menu that incorporates past, present and possible future changes my hats off to you. Scenario rules are very fluid and dynamic often changing drastically from one to the next. I guess this isn't insurmountable and you obviously know your way around coad so I look forward to seeing something.

(I think your idea has a lot of merit when applied to a rule violation output that is over seen by a human operator despite any differences of opinion though.)

Sometimes you are a weird one oneway....nice edit.

Strip

[oneway]

Well, like anything else with Aces High sometimes the only way to find an outcome is gather your marbles and give it a shot.

The inverse what your saying is true to though....

If you code the program logic one way (pardon the pun) and the designer wishes to deviate from them you run into issues there. There are certain situations that will crop up and you may need to add to or modify the program. If you can program a user selectable menu that incorporates past, present and possible future changes my hats off to you. Scenario rules are very fluid and dynamic often changing drastically from one to the next. I guess this isn't insurmountable and you obviously know your way around coad so I look forward to seeing something.

(I think your idea has a lot of merit when applied to a rule violation output that is over seen by a human operator despite any differences of opinion though.)

Strip

That is why you open source the project...the designers should be driving the code...not victims of it...

Designers are hemmed in by the current state of affairs...they are stuck with log outputs on the public level that are anemic, and the raw logs (still out of my reach) that are so tragically under utilized...

If you want dynamic events, than give the designers the confidence that their designs are no longer contstrained by the current state of affairs...

Rather they are unleashed in collaboration with an AH open source group that is working with them to create robust flexibility and scoring dynamics...

Worried about black boxes?...

Right now we have black bags...full of holes...

I would rather shine the light of day on the whole thing, score our stuff accurately, unleash our designers...and unburden our poor CM's who put these things on...

Most importantly to me...I want to know as a CO...as a commander....the playing field is DEAD LEVEL...and its Mind against Mind....A-Game against A-Game...

Nothing that can cloud the result...

Oneway

[Strip]

Although its towards the bottom of your post I would like to touch on our CM's and their efforts. When I hear about some of them going through thousands of lines of log I cringe. That time could be spent doing better things in real life or planning new events. Anything that would help them is okay in my book and I am sure everyone elses.

Moving on, most of the designers that I know of have access to the logs, even detailed ones. I cant picture how they are hemmed in with the current scheme though. Your discussing a bit of analysis software when the event is over and done with, it comes into play. Would you care to elaborate on that? You certainly have my curiosity, I feel like other than unique scoring methods our designers are far more limited by in-game features than anything else.

Your last sentence is a bit intriguing....

Strip

[oneway]

Although its towards the bottom of your post I would like to touch on our CM's and their efforts. When I hear about some of them going through thousands of lines of log I cringe. That time could be spent doing better things in real life or planning new events. Anything that would help them is okay in my book and I am sure everyone elses.

Moving on, most of the designers that I know of have access to the logs, even detailed ones. I cant picture how they are hemmed in with the current scheme though. Your discussing a bit of analysis software when the event is over and done with, it comes into play. Would you care to elaborate on that? You certainly have my curiosity, I feel like other than unique scoring methods our designers are far more limited by in-game features than anything else.

Your last sentence is a bit intriguing....

Strip

You touched on it your self...

The CM's crunch the logs...the designers know it...under the present schema even the slightest creative design idea adds more work for the CM to score...

Connect the dots...the designers don't want the log crunchers to be overworked...thus the designer is hemmed in or limited because it...

If the designer could design with impunity...and the log cruncher never had to crunch logs...

We end up with designers utilizing broader pallets...and log crunchers no longer crunching logs, but focusing on the running of the event...

The designer should never have to ask the CM's can we score this like this?...The designers should be asking the OpenDev guys can you set the program up to do this?...

An mentioned aspect of this a program that can also create tables for each frame of each scenario automatically for the CM...that is such a rather simple matter to do...yet another work load item lifted from the CM...

Think about it for a moment...when the fields are set up, and the rules set for each field in incorporating the proposed rules for a scenario...the primitive text files that AH uses for 'tables' become and incredibly routine matter to produce...

No longer would the designer or CM have to laboriously have to use the game interface for such activity...or go to Excel tables  and then output that to a usable txt file format...

Its rather elementary...its freedom for both groups...its flexibility for everyone...

Its another layer of involvement for the community...

Oneway

[Tilt]

Its quite easy to rule for the direct consequences of rule breaches.

It is very difficult to "rule" in advance for the consequences of the consequences (otherwise known as "indirect consequences")

IMO Penalties (or indeed non penalties) applying to the indirect consequences of a rule breach can only be ruled retrospectively by the CM incharge once he/she has considered all the circumstance in play and taken such advice as he/she sees fit.

In this instance his/her decision is final IMO.

[humble]

Personally I think you will always have a bit of "fog of war". IRL orders were missed, botched or entirely misunderstood. Sometimes the results were horrible and other times they carried the day. A pilot or squad upping from the wrong field or attacking the wrong target falls in that context IMO. As noted the vast majority of violations are inadvertent, in those cases where intent is readily apparent the CM's have the ability to resolve the situation. After all participating in a scenario is a privilege not a right. To me the perception of a violation seems to have more impact then the transgression itself.

The logs clearly show that no A-20 violated the rules of engagement (as defined by the rules and interpreted by the CM's) and no damage (assist or kill) was inflicted in any frame yet the perception of a violation had a profound affect on the outcome...to the point where it may very well have determined the final outcome. To me this is the underlying core issue, a player (or in this case a significant number of players) basically walking off a scenario midstream over a perceived infraction that did not in fact occur.

I'm not sure exactly what course of action is best but at some point over overemphasis on trivial transgressions can further erode player tolerance (again just my opinion). In every scenario I've flown in the command and squad leadership has done a fine job of policing the side I was on if it was needed (which has been rare). From reading the Axis command forum it appears some type of major issue developed early on (I've never seen a CiC step down before). I have no idea if this factional infighting somehow tied into the issue above but it appears that a fundamental lack of respect for both the CM team and the axis command team seriously effected things on the axis side. So if you want to write a program then track those who consistently don't show up or who create issues for the whole based on a perception of what they feel should happen.

[Tilt]

When I hear about some of them going through thousands of lines of log I cringe.

Actually its not a Problem.

Long ago in a scenario GV's always had to "originate" from their command base (as set by the CiC) for that frame. However they could "travel" by driving to another base and "landing successfully" then spawn from the base they had just landed at to another base and so on. In this way they would travel across the map during a frame but if one of the bases en route had been interdicted by enemy action (hangers down!) they had to find another route.

OK how do we track this from the logs........... actually it was easy and I tracked every journey every player made for every frame. Time taken was 5 or 10 minutes each frame via excel and sort command.