Aces High Bulletin Board
Special Events Forums => Scenario General => Topic started by: oneway on December 15, 2009, 10:18:42 PM
-
To Any and All,
If you had a program that could accurately tell if a pilot sortie was Invalidated for any of a number of reasons, would it not then be Logical to invalidate the kills and objects destroyed for that sortie?
Take for instance a pilot, that half way through a frame decided that instead of flying his squadrons assigned aircraft from their assigned field, he decided to pick another plane from another field. For the sake of this hypothetical, this pilot then goes on to get 2 kills and destroy 7 objects...
Would it not then be logical to invalidate those kills and objects in the course of scoring the event?
What about multiple lives?
Under the present understanding and manifestation of the rules, the team is assessed a 'life violation'...a single negative point....wouldn't it be more logical and appropriate to nullify all activity and gain of pilots that flew multiple lives?
What about pilots that fly from Non-Active airfields?
Shouldn't we nullify everything they do...basically erase it from the record?
This question assumes we have a program that can do that...accurately detect such violations on a sortie by sortie, event by event basis...and simply set the event to invalid...
Do we even want such a tool?...
If we had one, what impact would it have on Command?, what impact would it ultimately have on OUR game?...is this something good?...is something we want?
I am rapidly approaching the point I can deliver this...but I am totally unsure whether anyone wants it?
Oneway
This question is the same as asking on Country in MA: "Do you want me to drop the hangers?, I am in position to do so...or are you having too much fun with your fur-ball?...let me know...I am lined up to drop now..."
-
Where do you draw the line and how much do you penalize the group for a single players action?
Worst case scenario....a player using too many lives captures a field, only to find out after a day or two that the maproom is voided.
Would it matter that the people around him/her were following the rules? Would it matter that three people behind him were following the rules? And that they could have affected the capture by themselves?
I feel like such draconian measures would take away the fun for me, even as someone who follows the rules to the best of his ability.
Strip
-
Where do you draw the line and how much do you penalize the group for a single players action?
Worst case scenario....a player using too many lives captures a field, only to find out after a day or two that the maproom is voided.
Would it matter that the people around him/her were following the rules? Would it matter that three people behind him were following the rules? And that they could have affected the capture by themselves?
I feel like such draconian measures would take away the fun for me, even as someone who follows the rules to the best of his ability.
Strip
Interesting question you ask...
Simple Answer: By denying the gains of the player to the group...
Is nullifying a single players achievement, a direct or magnified penalty upon the team?
Which leads to yet more questions...
If Command makes a mistake and an entire squadron is nullified in an event...are the pilots in fact penalized if the nullification only shows in the broader teams output or result?
Discussing "penalty" as a result of such capability must be couched in the context of Team.Group.Squad.Player...in that order...
How would penalizing a Team...ever have an impact on an individual...unless that individual was a commander?...and if so...then where is the draw back?
One would expect that the temper of Command is ready to assume the fallout of failure...its the nature of being a Commander...great risks accompanied by great reward...
For the record we are not talking about voiding captures...that is a far too complex an issue to deal with...such as nullify gains gained from nullified captures...I am not remotely interested in probing that dark hole...
We are talking about an elevated scoring logic system at its most basic capability...anonymously...
Oneway
-
Well the thing is most dedicated players in scenarios do not break the rules intentionally, but that being said I can understand where someone may use to many lives which could change an outcome.
I know that in frame four 13 GvBAP had a walkon (a child) that used up both his lives crashing on takeoff. When we told him he was done for the day he apparently began upping IL2s at another base but was shot down almost every time. Had I know he was doing that I would've had a CM eject him instantly. The reason I post this is because I know I would be mad if my squad was penalized because a walkon was disobeying the rules 300 miles away from where the rest of us were flying....and obeying the rules.
-
Well the thing is most dedicated players in scenarios do not break the rules intentionally, but that being said I can understand where someone may use to many lives which could change an outcome.
I know that in frame four 13 GvBAP had a walkon (a child) that used up both his lives crashing on takeoff. When we told him he was done for the day he apparently began upping IL2s at another base but was shot down almost every time. Had I know he was doing that I would've had a CM eject him instantly. The reason I post this is because I know I would be mad if my squad was penalized because a walkon was disobeying the rules 300 miles away from where the rest of us were flying....and obeying the rules.
Lets make this crystal clear:
We are not talking about differentiating between Intentional and Accidental violations...
Most can be deductively reasoned to be Accidental...by simply applying some context and logic to the events...
But make no mistake...the list of 'violations'...and the 'violators'...is filled with 'top brass' of the game...players who are exemplary...and make mistakes...sometimes huge ones as commanders and they have far reaching consequences...
Beefcake...
You said this: "The reason I post this is because I know I would be mad if my squad was penalized because a walkon was disobeying the rules "
The system I am proposing would not penalize your squad...in fact its less arbitrary than the present system...Instead of automatically penalizing the team for a life violator...it simply deducts the violators achievement. Under the present system, some walk-on could violate lives 10 times and destroy nothing...yet your Team would be penalized for his 10 life violations...
Again the question:
Do we want to know the truth?
Do we want a system that accurately applies the rules to an event and scores it dead nuts, spot on?
If we don't want that, then explain why?
Oneway
-
Well, I am not against nullifying someone like Beefcake mentioned but it just seems like a slippery slope. Frankly penalizing an entire squad (by making their team contribution zero) for a command error is a bit harsh on them yet could be considered warranted. I agree with Beefcake though, having your efforts nullified for a walkons transgressions would be severely disappointing. For command this includes the week of planning, and the players showing up ready to rock for three hours or more. Although the battle is a large portion of the fun knowing I contributed to a team victory is just as important.
Strip
-
Lets make this crystal clear:
We are not talking about differentiating between Intentional and Accidental violations...
Most can be deductively reasoned to be Accidental...by simply applying some context and logic to the events...
But make no mistake...the list of 'violations'...and the 'violators'...is filled with 'top brass' of the game...players who are exemplary...and make mistakes...sometimes huge ones as commanders and they have far reaching consequences...
Again the question:
Do we want to know the truth?
Do we want a system that accurately applies the rules to an event and scores it dead nuts, spot on?
If we don't want that, then explain why?
Oneway
At what point do you take away from the event with finger pointing? If its anonymous, well, it still wont change the past, a rule was broke. Souring an otherwise great event over a misunderstanding of the rules seems counter productive (ie command error).
Statistically rule violations would equal out over the duration of the event. Changing the final core is likely to have little effect on the average player. A few points subtracted for a rule breaker is fairly understandable. Telling a squad your efforts will not be counted for reasons beyond their control would be a sure fire way to lose players.
Strip
-
At what point do you take away from the event with finger pointing? If its anonymous, well, it still wont change the past, a rule was broke. Souring an otherwise great event over a misunderstanding of the rules seems counter productive (ie command error).
Statistically rule violations would equal out over the duration of the event. Changing the score is likely to have little effect on the average player. Telling a squad your efforts will not be counted for reasons beyond their control would be a sure fire way to lose players.
Strip
Than it shouldn't matter should it?
And we are not talking about past events...
We are talking about the future...
And again I ask the question:
Why would you not want to score an event based on the rules?
Oneway
-
Well, I wont say the rules shouldnt matter....they should, and I do my best to make sure I fly by them as well as anyone following my lead.
In my mind its diminishing returns, the event is over, what good could come of very detailed finger pointing?
(Little bit of irony here but live and learn...)
Strip
-
Say you anonymously adjust the final score, team x is deducted 100 points, team y is deducted 58.
If you keep the process anonymous you forgo any chance for that team to defend their actions and you are basically the Judge/Jury/Executioner.
If you keep an open process you get the finger pointing and souring of an event after the fact which seems already to be too common.
That summarizes my concerns.....scoring by the rules is always a good thing though.
Strip
-
Lets make this crystal clear:
We are not talking about differentiating between Intentional and Accidental violations...
Most can be deductively reasoned to be Accidental...by simply applying some context and logic to the events...
But make no mistake...the list of 'violations'...and the 'violators'...is filled with 'top brass' of the game...players who are exemplary...and make mistakes...sometimes huge ones as commanders and they have far reaching consequences...
Beefcake...
You said this: "The reason I post this is because I know I would be mad if my squad was penalized because a walkon was disobeying the rules "
The system I am proposing would not penalize your squad...in fact its less arbitrary than the present system...Instead of automatically penalizing the team for a life violator...it simply deducts the violators achievement. Under the present system, some walk-on could violate lives 10 times and destroy nothing...yet your Team would be penalized for his 10 life violations...
Again the question:
Do we want to know the truth?
Do we want a system that accurately applies the rules to an event and scores it dead nuts, spot on?
If we don't want that, then explain why?
Oneway
The problem with a cold hard system is it doesn't account for errors that can be explained or understood by a human.
Take for example the bombing of tanks by planes that are not IL2's or F8s. There is the possibility that a B25 could be bombing a hanger and kill a tank thats parked next to it. Now by the "system" thats a violation and the B25 or the team gets penalized for it. However, any scorer looking at that (maybe through a film) is going that say "no thats collateral damage". OR another example would be a F8 or an IL2 thats NOT apart of the assigned ground attack squad for that frame killing a tank. Per the system there is no violation, however, the plane should not be credited with kill points.
Oneway, I respect what you're trying to do and have no problems with a system like this "helping" with scoring. But I just don't want scenarios to turn into court cases were each team has to bring in lawyers to examine every detail to ensure the event was scored correctly.
-
The problem with a cold hard system is it doesn't account for errors that can be explained or understood by a human.
Take for example the bombing of tanks by planes that are not IL2's or F8s. There is the possibility that a B25 could be bombing a hanger and kill a tank thats parked next to it. Now by the "system" thats a violation and the B25 or the team gets penalized for it. However, any scorer looking at that (maybe through a film) is going that say "no thats collateral damage". OR another example would be a F8 or an IL2 thats NOT apart of the assigned ground attack squad for that frame killing a tank. Per the system there is no violation, however, the plane should not be credited with kill points.
Oneway, I respect what you're trying to do and have no problems with a system like this "helping" with scoring. But I just don't want scenarios to turn into court cases were each team has to bring in lawyers to examine every detail to ensure the event was scored correctly.
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
-
I think it would take a lot of discussion to define what an "invalid" sotie would be comprised of...
Say player X ups 1 life too many... Say in that last life he shoots down player Y. Makes no difference to player Y that this was removed from the score -- his mission was cut short, he's done for the frame!
I think that unless it's a realtime calculation it will be hard to determine invalidity of a sortie. I think it'll be a useful tool between frames and whatnot, useful in scoring, but I don't know if I philosophically agree with negating entire sorties.
On that topic, though, I seem to recall once or twice in past scenarios where a base capture was reverted after a frame because of rules violations (Stalin's Fourth, probably is the most prominent in my mind). It's not unheard of. Short of using too many lives, and short of violations taking maprooms (or bombing things illegally -- often a major points issue), I think you might want to define or refine the tool's objective before going too far into making it.
-
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 :aok
-
I think it would take a lot of discussion to define what an "invalid" sotie would be comprised of...
Say player X ups 1 life too many... Say in that last life he shoots down player Y. Makes no difference to player Y that this was removed from the score -- his mission was cut short, he's done for the frame!
I think that unless it's a realtime calculation it will be hard to determine invalidity of a sortie. I think it'll be a useful tool between frames and whatnot, useful in scoring, but I don't know if I philosophically agree with negating entire sorties.
On that topic, though, I seem to recall once or twice in past scenarios where a base capture was reverted after a frame because of rules violations (Stalin's Fourth, probably is the most prominent in my mind). It's not unheard of. Short of using too many lives, and short of violations taking maprooms (or bombing things illegally -- often a major points issue), I think you might want to define or refine the tool's objective before going too far into making it.
Invalidating sorties is actually a rather simple affair of flipping some switches...
Either launching from an inactive field is OK or its NOT OK...
Either changing planes is OK or NOT OK...
Either multiple lives are OK or they are NOT...
.......
It goes on an on...you decide...all I am saying is I have a tool that lets decide whether its OK or NOT OK and then pump out the results...
I don't care one way or the other whether multiple lives are OK or NOT...I don't care whether bombing your own base is OK or NOT...
All I am saying is I have the tool that does that...just like my question regarding troop carriers with no lives left...either its OK or NOT OK...flip a switch...
I think folks are not understanding what I am trying to do here...
Do you want a tool that lets you simply toggle on an off switches according to a set of Scenario rules, that goes far beyond the present capability of what we have, and pump out the score?
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.
-
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 :aok
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
-
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
-
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
-
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! :rofl
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.
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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.
-
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.
-
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.
-
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.
That whole sordid affair about the A-20 and the alleged tank bombing was indeed unfortunate, though I only heard bits and pieces of it...I was not privileged at the time to view the forums...nor have I bothered to look into to the details of it now that the forums are open...
The program that I have written and continue to write would have ended that discussion in 5 minutes by simply running the log for the frame in question and then outputting the BBS code showing clearly that no violations had occurred. What started as a spark, and grew to a conflagration would rarley happen with this tool at our disposal; here is yet another tremendous benefit of such a tool.
Rapid response to such claims and innuendo is the surest way to stop that sort of thing from happening...
As to A-20's during the Scenario...like all groups or plane types, they had their share of issues including multiple life, invalid departure fields, invalid strat targets, rtb to wrong base...
Oneway
-
Your analysis of the A-20 situation is a bit off, Fencer immediately tried to put that fire out. He had a detailed post about his findings within mere hours after being made aware of it. He specifically said not one A-20 violated the rules that frame. That was a bomb looking for a fuse, regardless of having ended the discussion as far as rules were concerned. A few players made up there minds with apparently little regard for what really happened.
No amount of software or code could have stopped that in my opinion....
Edit: I started to question my timeline and looked back at the particular thread I had in mind. It was a little over two days before Fencer posted his findings, my mistake. Still stand by my comments tho....
Strip
-
Your analysis of the A-20 situation is a bit off, Fencer immediately tried to put that fire out. He had a detailed post about his findings within mere hours after being made aware of it. He specifically said not one A-20 violated the rules that frame. That was a bomb looking for a fuse, regardless of having ended the discussion as far as rules were concerned. A few players made up there minds with apparently little regard for what really happened.
No amount of software or code could have stopped that in my opinion....
Edit: I started to question my timeline and looked back at the particular thread I had in mind. It was a little over two days before Fencer posted his findings, my mistake. Still stand by my comments tho....
Strip
48 hours is a long time to wait...maybe it wouldn't have made a difference to have an answer in 5 minutes...again I was not privileged to what went down and the time line...I just picked up bits and pieces of it via PM's...spanning a few days...
I stand by my comments that it would make difference, and it certainly wouldn't hurt a thing to be able to able to respond rapidly and definitively.
-
To me the issue wasn't the possibility of an infraction, it was the response. The moment that I read the relevant post on the BBS I immediately posted a link to my film for review. It clearly showed not only the actual event but the context. If nothing else this made it very clear that my intention was to actually mark the tank in question, very different from someone actually trying to hit the tank missing and then claiming another intent. Regardless of any individuals feelings on the subject both my intent and the event itself were clearly within the rules. To be candid the response was (and actually still is) very disturbing to me. My goal was to contribute in any way possible (within the rules) to achieve our goals for the frame. To me this little bit of ad-lib was exactly what a scenario is all about, finding a way to get the job done within the structure of the scenario. Obviously reading the axis forums its clear this was an ongoing issue predating this scenario and that a faction within the side had a very distinct agenda (curious if this caused the internal issues). When they got spanked they chose to focus on an perceived wrong and use it as an excuse to cut and run vs man up and do better the next frame.
To me this all ties in to the original post in that we're looking more and more to police transgressions. Specific to the A-20's I am unaware of any A-20 departing from anything other then the correct base at any time in the 4 frames. I am also unaware of any issues specific to multiple life's, invalid strat targets. RTB to "wrong base" is perfectly fine as long as a life is deducted...
I didn't read the oui oui oui thread till the next morning, Fencer responded in the thread in less then 3 hours, jolly also confirmed that I was in fact coordinating with him and that the tactic did in fact enable him to located the tiger in question. The issue isn't the action or the "lag" in response, its the reaction from those who disagrees with both my action and the CM's decision. Having a program that confirmed no actual damage was done sooner wouldn't have changed the response by the "offended parties". So in the end I'm somewhat upset that I inadvertently pissed in someones cheerio's and caused such discontent...but i'm more angry that a small group felt they had some unalienable right to manufacture an artificial sandbox to play in and caused what I feel were tremendous issues for the axis if we consider that the Tiger unit was unquestionably the lynch pin for both the axis ground defense and offense. To unilaterally bail over this is an unpardonable breach of scenario etiquette and i'm dismayed it wasn't dealt with more severely.
-
----
RSKS output...without rules applied...
Refining BBS code output and crunching data....accurate and thorough scoring capability is just around the corner....
The switches are ready to be flipped according to the rules of the NEXT Scenario....
It will be in the hands of the switch designers and switch flippers if accuracy and totality is welcomed and/or warranted...
The capability is near to apply pure rule logic to the data sets...
Look out in the 2-3 weeks to see the comprehensive report output and capabilities of this program, ranging from Overall Scenario Stats to Individual Pilot Reports...including Fighter to Fighter, Machine vs Machine, Friendly Fire, and the dreaded 'Dark Side Report'... and much more...
Oneway
========================
Red Storm / Krupp Steel Frames 1 through 4:
|
| Allied | | | | | Axis |
| Pilots | 193 | | | | Pilots | 188 |
|
| Kills | 776 | Bailed | 34 | | | Kills | 635 | Bailed | 42 |
| Assists | 471 | Captured | 64 | | | Assists | 340 | Captured | 55 |
| Deaths | 451 | Crashed | 58 | | | Deaths | 548 | Crashed | 58 |
| Landed | 1130 | Ditched | 42 | | | Landed | 513 | Ditched | 28 |
| Destroyed | 2353 | Diso'd | 47 | | | Destroyed | 1338 | Disco'd | 38 |
|
| Killers: | | Destroyers: | | | Killers: | | Destroyers: |
| Sethbag | 39 | Sethbag | 141 | | | dr7 | 36 | KKEN | 106 |
| WMLute | 29 | cactus | 140 | | | Sloehand | 34 | TheMaj | 82 |
| COLLEEN | 28 | GypsyB | 134 | | | Coprhead | 22 | Nutzoid | 68 |
| DrBone | 26 | Tippo | 132 | | | shamus | 19 | whiskers | 67 |
| Dantoo | 23 | Krusty | 118 | | | HiSpd | 17 | pope14 | 63 |
| SirNuk3 | 23 | Strip | 116 | | | kansas2 | 17 | lothmog | 61 |
The People:
| Kills: | Sethbag | 39 |
| A2A Kills: | WMLute | 28 |
| A2G Kills: | A8Moray | 9 |
| G2G Kills: | Sethbag | 38 |
| G2A Kills: | COLLEEN | 3 |
| F2F Kills: | Dantoo | 18 |
| F2B Kills: | SirNuk3 | 15 |
| B2F Kills: | Soulyss | 6 |
| Assists: | Snefens | 17 |
| Awarded: | flight17 | 3 |
| ---- |
| Destroyed: | Sethbag | 141 |
| Base Objects: | Sethbag | 93 |
| Strat Objects: | GypsyB | 117 |
| ---- |
| Departures: | Tippo | 56 |
| ReArms: | HiSpd | 8 |
| Landed: | USRanger | 37 |
| ---- |
| ShotDown: | XXXX | 22 |
| SD-Captured: | XXXX | 1 |
| SD-Crashed: | XXXX | 7 |
| Bailed: | XXXX | 3 |
| Captured: | XXXX | 4 |
| Crashed: | XXXX | 4 |
| Ditched: | XXXX | 2 |
| Disco'd: | SD67 | 4 |
The Machines:
| Fighter | Sorties | Kills | Deaths | K/D | Destroyed | Field | Factory |
| La-5FN | 145 | 79 | 25 | 3.16 | 108 | 37 | 71 |
| La-7 | 250 | 241 | 51 | 4.73 | 98 | 89 | 9 |
| P-39Q | 148 | 33 | 19 | 1.74 | 164 | 56 | 108 |
| Yak-9U | 249 | 153 | 62 | 2.47 | 16 | 16 | 0 |
| Bf 109G-14 | 90 | 80 | 41 | 1.95 | 1 | 1 | 0 |
| Bf 109G-6 | 121 | 38 | 61 | 0.62 | 2 | 0 | 2 |
| Bf 109K-4 | 119 | 82 | 52 | 1.58 | 3 | 3 | 0 |
| Bf 110G-2 | 28 | 6 | 14 | 0.43 | 161 | 0 | 161 |
| Fw 190A-8 | 40 | 10 | 7 | 1.43 | 1 | 1 | 0 |
| Fw 190D-9 | 162 | 143 | 59 | 2.42 | 1 | 1 | 0 |
| Fw 190F-8 | 183 | 99 | 78 | 1.27 | 477 | 145 | 332 |
|
| Bomber |
| A-20G | 78 | 18 | 20 | 0.90 | 264 | 15 | 249 |
| B-25C | 152 | 29 | 25 | 1.16 | 1078 | 157 | 921 |
| Il-2 Type 3 | 141 | 31 | 67 | 0.46 | 166 | 163 | 3 |
| Ju 88A-4 | 91 | 9 | 60 | 0.15 | 505 | 137 | 368 |
|
| Tank |
| Sherman VC Firefly | 163 | 70 | 82 | 0.85 | 62 | 59 | 3 |
| T-34/76 | 3 | 0 | 0 | ---- | 0 | 0 | 0 |
| T-34/85 | 166 | 100 | 65 | 1.54 | 236 | 188 | 48 |
| Panzer IV H | 93 | 30 | 60 | 0.50 | 27 | 11 | 16 |
| Tiger I | 104 | 121 | 70 | 1.73 | 67 | 23 | 44 |
|
| AAA |
| Ostwind | 28 | 0 | 1 | 0.00 | 41 | 11 | 30 |
| Wirbelwind | 76 | 14 | 14 | 1.00 | 150 | 5 | 145 |
|
| Troop |
| M3 | 124 | 2 | 27 | 0.07 | 30 | 14 | 16 |
| SdKfz 251 | 106 | 1 | 37 | 0.03 | 21 | 21 | 0 |
|
| FieldGun |
| Gun Ship or Field | 157 | 14 | 0 | ---- | 12 | 12 | 0 |
|
| Gunner |
| Gunner-Observer | 93 | 8 | 2 | 4.00 | 0 | 0 | 0 |
BBS Code Generated by AcesHigh.Scenario.LogReader Class
A Scenario Planning, Management & Analysis program written by Oneway in C# .NET 3.5
Number of Auto-Generated Chars = 8953
-
Allied La-7 Group Leaders,
The Kill/Death ratio of the La-7 in RSKS is an astounding figure when you consider its predicated not on pilot ability, but the Machine driven...and more importantly the leadership of the La-7 groups....
Well done Allied La-7 Leaders....
A supreme effort to say the least
:salute
Oneway