Named pilots problem (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> War In The Pacific - Struggle Against Japan 1941 - 1945 >> Tech Support



Message


Rikimaru -> Named pilots problem (6/4/2006 7:09:15 PM)

I have a problem with named pilots. I use 1.801 and Nik mod. I started '41 campain as japanese, and I disbanded a lot of groups, so I got about 500 named pilots. I attacked pearl harbour, I check pilot pool, and what I see? 0 named pilots. They just disappeared. And everytime I disband some group I see these pilots in pool, I wait one turn and just disappear. I have no idea what to do about this:S




pauk -> RE: Named pilots problem (6/4/2006 7:33:13 PM)

IIRC NPP doesn't work - it is bugged.

Wait for new patch....




Halsey -> RE: Named pilots problem (6/4/2006 7:36:59 PM)

Yes, they all go on indefinite leave after one day.[:D]

If you want to use it before it's patched, the pilots have to be taken by a new group the turn they are disbanded.




Rikimaru -> RE: Named pilots problem (6/4/2006 7:38:30 PM)

So I cannot start new campaign until new patch, or my pilots will be lost:(




Don Bowen -> RE: Named pilots problem (6/4/2006 8:11:15 PM)


Do not use the Disband into Pool function. Everything else will work OK.





GaryChildress -> RE: Named pilots problem (6/4/2006 11:39:27 PM)

Woops I just now saw this. I posted something similar in the main forum. Are there plans afoot to implement a patch to fix the problem? I really did think it was an awesom addition to the game. [:(]




Don Bowen -> RE: Named pilots problem (6/4/2006 11:54:42 PM)


The Disband Into Pool function has opened a significant cheat and will probably be removed.





GaryChildress -> RE: Named pilots problem (6/5/2006 12:06:28 AM)


quote:

ORIGINAL: Don Bowen


The Disband Into Pool function has opened a significant cheat and will probably be removed.




Will the "draw plane from the pool" function remain?




wworld7 -> RE: Named pilots problem (6/5/2006 12:11:14 AM)


quote:

ORIGINAL: Don Bowen


The Disband Into Pool function has opened a significant cheat and will probably be removed.




Good!!!

Flipper




Nemo121 -> RE: Named pilots problem (6/5/2006 12:27:56 AM)

Since the "cheat" was obvious AND the bug was also obvious on even cursory testing the question which must be asked is why was neither thought of prior to release?

Since the bug showed up obviously to anyone who disbanded a unit, didn't use all of the pilots and then went on to the next turn ( something which I think any competent testing would have uncovered) the question of how it could have gone unspotted is particularly pertinent. Was this feature, in fact, tested at all and if it was how did no-one notice that all of the unused disbanded pilots disappeared after 24 hours?




Rainer -> RE: Named pilots problem (6/5/2006 12:46:17 AM)

I understand beta testers are not paid for what they're doing.
Therefor it doesn't make much sense to look for scape goats.
Instead beta testers (and moderators, also not paid) should get all the help from the community as possible.
Like stating questions and bug reports with concise and complete information.
Otherwise the motivation of said beta testers and moderators may suffer, the last we all want to happen.
Cheers
Rainer - NO beta tester, NO mod, but also unpaid ;)




Nemo121 -> RE: Named pilots problem (6/5/2006 1:32:09 AM)

Rainer,

I think you misunderstand my point. I'm not looking for scapegoats. I've alpha and beta-tested myself and know that it is a frank impossibility to expect every bug to be found.

On the other hand it seems to me that to expect the following is not unreasonable:
1. Disband air unit on Turn A.

2. Allocate  pilots to various units but have a few left over and finish turn.

3. Check Named Pilot Pool on Turn A+1.

4. Notice that the pilots you left in the pool have no disappeared.

5. Report same to programmers as possible bug.


Within 24 hours of the patch being released numerous players had noticed and posted about this bug. Now, while there's no-one trying to find scapegoats in order to beat up on testers and programmers there IS value in asking why such an obvious bug was missed. Why is this? Simple, when you know why it was missed you might be able to put something in place to catch a similar one next time. If you avoid asking these sorts of questions then systemic failures remain and the same results occur again and again.

E.g. If it was missed because this fix got to testers too late for them to test the fix then the solution is to give more time to final testing. If it was missed because it was no-one's responsibility to check its functionality from turn to turn then that, also, can be fixed. Perhaps it was missed because none of the testers involved has a naturally analytical mind ( that's not to say they are dumb or anything like that. There are certain general ways in which minds work and naturally analytical minds are just one small category which tend to be very useful in analysing rule-based systems... aka computer games.). I'm sure they bring many other things to the table but, perhaps, this particular skillset is missing from the testing team. The solution there is to bring on someone with that skillset.
etc etc ad nauseum.

Asking questions as to why mistakes happen is NOT looking for scapegoats as you seem to think. It is precisely the sort of analysis which SHOULD be going on in order to create the appropriate system within which testing can be carried out in as effective and efficient a manner as possible. Note the implication that the system is flawed and not the individuals.

I stand by my assertion that pre-release testing of a patch which fails to notice such an obvious bug is highly likely to have suffered from a systemic flaw which, if unresolved at this stage, will continue to rear its ugly head in future failures in the pre-release testing of future patches. I think it is entirely valid questioning which, if reflected on by the people behind this and future patches, could result in improvements which might prevent such simple bugs making it into future releases. If you think that pointing that out is "unhelpful" and akin to looking for scapegoats then so be it. I doubt there will be much I can say to change your mind. 




Rikimaru -> RE: Named pilots problem (6/5/2006 9:04:09 AM)

quote:

ORIGINAL: Don Bowen


The Disband Into Pool function has opened a significant cheat and will probably be removed.




Omg, how u can cheat with this function? I would really like to get this function, just unbugged, its very useful:)




jwilkerson -> RE: Named pilots problem (6/5/2006 4:36:04 PM)


quote:

ORIGINAL: Nemo121

Since the "cheat" was obvious AND the bug was also obvious on even cursory testing the question which must be asked is why was neither thought of prior to release?

Since the bug showed up obviously to anyone who disbanded a unit, didn't use all of the pilots and then went on to the next turn ( something which I think any competent testing would have uncovered) the question of how it could have gone unspotted is particularly pertinent. Was this feature, in fact, tested at all and if it was how did no-one notice that all of the unused disbanded pilots disappeared after 24 hours?


This is a good question - one I've asked myself - and there is only one answer - NO EXCUSE SIR !!!





wworld7 -> RE: Named pilots problem (6/5/2006 5:34:09 PM)


quote:

ORIGINAL: jwilkerson


quote:

ORIGINAL: Nemo121

Since the "cheat" was obvious AND the bug was also obvious on even cursory testing the question which must be asked is why was neither thought of prior to release?

Since the bug showed up obviously to anyone who disbanded a unit, didn't use all of the pilots and then went on to the next turn ( something which I think any competent testing would have uncovered) the question of how it could have gone unspotted is particularly pertinent. Was this feature, in fact, tested at all and if it was how did no-one notice that all of the unused disbanded pilots disappeared after 24 hours?


This is a good question - one I've asked myself - and there is only one answer - NO EXCUSE SIR !!!




No white-wash, just the truth.

REFRESHING!!!

Flipper

P.S. I wish you improved succes in the future.





Nemo121 -> RE: Named pilots problem (6/5/2006 5:34:38 PM)

Well, I belong to the school which doesn't put much stock in people beating themselves up for mistakes ;). If I did I fear I'd be in hospital with contusions and concussion most of the time myself ;) ( especially after what happened at Bombay in my current PBEM.. *sigh [:(][:(][:(] ) . The important thing is to learn from it and try to make sure the same mistake doesn't happen again.

And, BTW, fair balls to you for admitting a mistake. I can respect people who own up to mistakes ( after all, we all do) but cannot respect those who dodge the question.

Kudos.




Halsey -> RE: Named pilots problem (6/5/2006 5:38:34 PM)

I was tired sir, is always a proper answer for this kind of oversight.
Fatigue will cause many unusual things to happen.

After a long time working on a specific process they all start to look the same.[:D]




Halsey -> RE: Named pilots problem (6/5/2006 5:40:42 PM)


quote:

ORIGINAL: Nemo121

Well, I belong to the school which doesn't put much stock in people beating themselves up for mistakes ;). If I did I fear I'd be in hospital with contusions and concussion most of the time myself ;) ( especially after what happened at Bombay in my current PBEM.. *sigh [:(][:(][:(] ) . The important thing is to learn from it and try to make sure the same mistake doesn't happen again.

And, BTW, fair balls to you for admitting a mistake. I can respect people who own up to mistakes ( after all, we all do) but cannot respect those who dodge the question.

Kudos.



A year ago this would have been reported to be working as designed.[;)][:D]




Nemo121 -> RE: Named pilots problem (6/5/2006 5:59:18 PM)

Ok, I know it is probably unwanted/unneeded but rather than see the entire thing go out the window I will post a possible solution which I think could meet most people's needs. Don't know the codebase so can't judge the feasability...

1. Allow players to "create" training squadrons in-game. These squadrons would have to use airplanes created in-game and would not have any combat missions available to them. It is probably not possible given the codebase since I'm sure no provision was made for "creating" squadrons in-game which didn't exist historically.

E.g.
Turn A: Player creates "Training Squadron 101" and assigns 27 Claudes to it as well as 27 total rookies.
Turn A+1: Player chooses between the two types of training available to all training squadrons ( ground training--slow improvement, no flying and thus no operational losses, aerial training-- quicker improvement, the only way to increase experience above 60 or 70, pilots fly and can suffer operational losses ).

Turn A+many: Player decides these pilots are now trained to a sufficient standard and disbands the training squadron. All pilots go into the pool. The squadron does NOT come back after 90 days. It just gets deleted and if the player wants to start a new band of trainees he can create another training squadron.

Since there would be no limit on the number of training squadrons created ( excepting the 30,000 pilot limit) it would allow a Japanese player with a lot of airframes and supply to set up a really major training system without having to resort to milk run missions. Since these squadrons wouldn't be available for combat there would be an in-built limit on their impact on unanticipated areas of the game. About the only area I could see them impacting would be over-crowding on airfields and the results if the enemy bombed those fields.


2. Similar to the above but somewhat more limited as it assumes that the ability to create "training squadrons" on the fly cannot be retrofitted into the game BUT that one can add a specialised training aircraft to the game.

Simply start the game with a factory producing a few of these training aircraft and have a lot of training squadrons in the reinforcement queue. These training squadrons will only have the two mission types outlined above ( so no use for combat... although I would suggest allowing them to switch to Kamikaze after 1st January 44 as was historically done) and, if possible, they could be coded so as not to be able to upgrade to any other aircraft type. If the aircraft carried no guns but could carry a 250Kg bomb or somesuch then they would conform closely to the historical trainers and their use as kamikazes from 1st January 44.

If the players in a PBEM choose to view these training squadrons as gamey then all the Japanese player has to do is switch the factories to something else and the groups in the queue will never appear on-map ( being left in the limbo of "organising").

If the players think that the on-map training is a good idea but want to limit its rate they can simply choose to leave the production of training aircraft at its initial, low, level which would only be sufficient to just fill out the training squadrons and keep up with a low level of training losses.

If the players agree to a lunacy game or otherwise put no limits on Japanese training then the Japanese player could massively expand the training aircraft production thus allowing himself a major increase in the rate of production of trained replacements.


3. If one cannot add a specialised training aircraft to the game then simply adding training squadrons but allowing them to use any type of aircraft would allow the player to use his older planes for training. All of the other limits ( kamikazes, mission types etc) could be maintained and you'd still end up with a system which would have fewer unanticipated knock-on effects than the current system AND which would be much easier to govern using house rules ( since there would be no combat mission for the training squadrons).


There are a few exploits still obviously but there's no point going into them unless someone official shows interest in one of the options and says it is feasible. If there was interest and it was feasible I'd be more than happy to outline the exploits and possibly unanticipated knock-ons in other areas.

I just thought I'd post it even though uninvited since I really think the solution is not to scrap what was a good idea but to seek a more complete fix. The implementation of training squadrons, if feasible, and with the appropriate thought put into preventing exploits and foreseeing knock-on effects would be a pretty good fix IMO.




Nemo121 -> RE: Named pilots problem (6/5/2006 6:04:03 PM)

Halsey,

yes, I've read most of the posts on this forum all the way back to mid-2004 and can see a very welcome evolution in how input is received. I must admit that I think that jwilkerson and Don Bowen have adopted a much better reaction to input/criticism etc. Mistakes/bugs are admitted and then something is done to fix them. Sometimes it works, sometimes it doesn't but, in my experience, most players will settle for a good faith effort. We just get annoyed when obfuscation is, intentionally, used as seems to have been the case in the past.




jwilkerson -> RE: Named pilots problem (6/5/2006 7:00:23 PM)

If we do decide to "scrap it" - the intent would be that the "scrapping" would be temporary - with the twin ideas that the original concept still makes sense - but that the closing of the loop holes will take a greater effort than was envisioned for the goal of this feature.





Halsey -> RE: Named pilots problem (6/5/2006 8:22:29 PM)

I agree.

The effort being put forward by these "volunteers" is outstanding.[;)]




Don Bowen -> RE: Named pilots problem (6/5/2006 10:47:59 PM)


quote:

ORIGINAL: Nemo121

Rainer,

I think you misunderstand my point. I'm not looking for scapegoats. I've alpha and beta-tested myself and know that it is a frank impossibility to expect every bug to be found.

On the other hand it seems to me that to expect the following is not unreasonable:
1. Disband air unit on Turn A.

2. Allocate  pilots to various units but have a few left over and finish turn.

3. Check Named Pilot Pool on Turn A+1.

4. Notice that the pilots you left in the pool have no disappeared.

5. Report same to programmers as possible bug.


Within 24 hours of the patch being released numerous players had noticed and posted about this bug. Now, while there's no-one trying to find scapegoats in order to beat up on testers and programmers there IS value in asking why such an obvious bug was missed. Why is this? Simple, when you know why it was missed you might be able to put something in place to catch a similar one next time. If you avoid asking these sorts of questions then systemic failures remain and the same results occur again and again.

E.g. If it was missed because this fix got to testers too late for them to test the fix then the solution is to give more time to final testing. If it was missed because it was no-one's responsibility to check its functionality from turn to turn then that, also, can be fixed. Perhaps it was missed because none of the testers involved has a naturally analytical mind ( that's not to say they are dumb or anything like that. There are certain general ways in which minds work and naturally analytical minds are just one small category which tend to be very useful in analysing rule-based systems... aka computer games.). I'm sure they bring many other things to the table but, perhaps, this particular skillset is missing from the testing team. The solution there is to bring on someone with that skillset.
etc etc ad nauseum.

Asking questions as to why mistakes happen is NOT looking for scapegoats as you seem to think. It is precisely the sort of analysis which SHOULD be going on in order to create the appropriate system within which testing can be carried out in as effective and efficient a manner as possible. Note the implication that the system is flawed and not the individuals.

I stand by my assertion that pre-release testing of a patch which fails to notice such an obvious bug is highly likely to have suffered from a systemic flaw which, if unresolved at this stage, will continue to rear its ugly head in future failures in the pre-release testing of future patches. I think it is entirely valid questioning which, if reflected on by the people behind this and future patches, could result in improvements which might prevent such simple bugs making it into future releases. If you think that pointing that out is "unhelpful" and akin to looking for scapegoats then so be it. I doubt there will be much I can say to change your mind. 


So, are you applying for a position??






Rainer -> RE: Named pilots problem (6/5/2006 11:08:28 PM)

Nemo, I see your point and fully agree with what you said.
My earlier response was more geared towards the "kids" here in the Maxis forums (you probably know what/who I mean), who sometimes come on with fairly unreasonable requests/demands.
I stand corrected and apologize.
Cheers
Rainer




Nemo121 -> RE: Named pilots problem (6/5/2006 11:43:32 PM)

Rainer,
No worries at all and no apology required. Discussion is good and we must always be prepared to exchange views and, at times, disagree. I see exactly what you were getting at and, for what its worth, I agree with you as regards some of the comments and requests made.


Don,
LOL! Are you offering? ;). Suffice it to say it'd be a pretty poor show if I wasn't willing to put my money where my mouth was. If you want a precis of my previous experience etc drop me an email and I'll be happy to oblige. You can then make the call as regards whether or not I could be of use. Hpwever I certainly wasn't writing the above with a view to securing a position on the team... Anyone who had a naturally analytical mind would do, IMO.




Halsey -> RE: Named pilots problem (6/6/2006 12:04:55 AM)


quote:

ORIGINAL: Nemo121

Halsey,

yes, I've read most of the posts on this forum all the way back to mid-2004 and can see a very welcome evolution in how input is received. I must admit that I think that jwilkerson and Don Bowen have adopted a much better reaction to input/criticism etc. Mistakes/bugs are admitted and then something is done to fix them. Sometimes it works, sometimes it doesn't but, in my experience, most players will settle for a good faith effort. We just get annoyed when obfuscation is, intentionally, used as seems to have been the case in the past.


Yes, these guys are doing a great job.
Kudos to all of them![sm=Cool-049.gif]

I dropped off from this forum for 6 months because I was sick and tired of lame excuses, contradictions, lame reasonings and infighting.
The posterior kissing made me want to puke everytime I read one of their posts.[:@]

As a side note, anyone who hates the River Shock Attack can blame me.
I suggested it and Kid liked the solution, even though they couldn't make the entire mechanics thing work.
Units were supposed to stop shock attacking after the river was line was breached.

It was my contribution to WITP.[;)]




jwilkerson -> RE: Named pilots problem (6/6/2006 12:13:42 AM)

quote:

Units were supposed to stop shock attacking after the river was line was breached.


Ah !
Not sure we knew that till now - I guess another case of fixing the hole was harder than making it ... hum ... this can probably be fixed one day ... but now we know the "design intent" !!! [:D]
At somepoint, someone suggested that we check the AV already in the hex and if is greater than something (1000?) then no shock attack. This sounds do-able.




Nemo121 -> RE: Named pilots problem (6/6/2006 12:56:32 AM)

A better solution ( and more historically accurate) would be, if possible, to add a check of the relative combat power in the hex being moved into and decreasing the losses suffered in a river crossing as the relative combat powers change.

E.g. If a 100 AV unit crosses a river into a hex containing a 100 AV defender then the relative combat power check would be 100 : 0 (since no friendly units are currently in the hex) and so the full loss currently applied to units moving across a river into a contested hex would be applied to the attacker.

On the other hand if a 100 AV unit crosses a river into a hex containing a 100 AV defender AND a 50 AV friendly unit then the relative combat power check would be 100 : 50 and the new unit moving into the hex would suffer only half of the losses currently applied.

I think that it would be fair to eliminate the river crossing losses when the attacker's pre-movement AV is equal to the defender's AV ( this would model troops crossing a river into territory held securely be large numbers of friendly troops) and scale the ratio of losses as the attacker's AV value falls below the defender's AV value.

This would eliminate the situation where forces moving across a river into a contested hex in order to bolster very strong friendly forces suffer massive losses due to the Shock Attack rule... which seems to be the biggest problem with the current system. I, personally, have had many artillery regiments almost completely wrecked moving across a river to support friendly troops which are several times strong than the Chinese troops they are besieging. The proposal above would have avoided this issue.




Halsey -> RE: Named pilots problem (6/6/2006 5:09:52 AM)

quote:

ORIGINAL: jwilkerson

quote:

Units were supposed to stop shock attacking after the river was line was breached.


Ah !
Not sure we knew that till now - I guess another case of fixing the hole was harder than making it ... hum ... this can probably be fixed one day ... but now we know the "design intent" !!! [:D]
At somepoint, someone suggested that we check the AV already in the hex and if is greater than something (1000?) then no shock attack. This sounds do-able.



A solution related to levels of AV sounds like the answer.
If the mechanics can support this.[;)]

I'll leave it to the new gurus to tackle this.
If it can be done, the shock/river attack will be seen as a more viable option for land combat defense.

Heck, who knows, maybe the WITP community my even accept this. [:D]

By the way, I apologize for hijacking this thread.[:'(]




Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
3.15625