From: Ali I. <aha...@ho...> - 2004-06-06 15:16:46
|
Hi, A player (squirecam) yesterday commented on a bug in the movement validation of planes where it would not let him perform a legal move. I went and looked at the code yesterday and it appears to be broken. I started thinking of how to fix this, but it is a very annoying problem. The biggest issue is that of being able to commit to move carriers non-combat. This creates all sorts of problems (think about how you have to make sure a carrier is not committed to multiple place, actually moves there if necessary, a ui for allowing the user to commit the carrier, etc.). One suggestion maybe to scrap the can land validation until we have a solution since otherwise it will cause problems for gameplay whereas without it, users will just have to be aware that they must determine the validity of plane movement themselves. Regards, Ali Ibrahim |
From: Sean B. <sbr...@ya...> - 2004-06-06 18:01:05
|
I think adding a ui to commit to non combat carrier movement might be more troublesome than its worth, and confusing for the users as well. The validation for the carriers doesnt have to be perfect. We can just let the logic be flexible enough that a carrier *could* move to a spot where it can pick up a plane, rather than forcing the user to declare that the carrier will move to such a spot. We can also ignore corner cases where a carrier might have to move to 2 different places to pick up fighters. I was thinking a long time ago about changing the logic so that it checks that planes can land at the end of combat move, and forces you to make changes then, but if the planes come under aa fire the moves cant be undone, and it is possible to get into a situation where you are stuck. Ali, I think that one thing that needs to be done is that fighter (ie things that can land on an ac) and non fighter can land validation should be seperated. Right now they are sort of mished together, and that makes it more difficult. Plane landing validation is quite complex to program correctly. Scrapping the validation as a temporary measure is ok. It may be better to have that validation overwritable. A dialog pops up that says the planes cant land, but the user can still press a button that says something like "I know what Im talking about, let me do it". Sean --- Ali Ibrahim <aha...@ho...> wrote: > Hi, > > A player (squirecam) yesterday commented on a bug in > the movement > validation of planes where it would not let him > perform a legal move. I > went and looked at the code yesterday and it appears > to be broken. I > started thinking of how to fix this, but it is a > very annoying problem. > The biggest issue is that of being able to commit to > move carriers > non-combat. This creates all sorts of problems > (think about how you have > to make sure a carrier is not committed to multiple > place, actually > moves there if necessary, a ui for allowing the user > to commit the > carrier, etc.). One suggestion maybe to scrap the > can land validation > until we have a solution since otherwise it will > cause problems for > gameplay whereas without it, users will just have to > be aware that they > must determine the validity of plane movement > themselves. > > Regards, > > Ali Ibrahim > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new > InstallShield X. > From Windows to Linux, servers to mobile, > InstallShield X is the one > installation-authoring solution that does it all. > Learn more and > evaluate today! > http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Triplea-developers mailing list > Tri...@li... > https://lists.sourceforge.net/lists/listinfo/triplea-developers |
From: Ali I. <aha...@ho...> - 2004-06-07 01:10:02
|
Hi, I am just wary of implementing something which gives the appearance of enforcing the plane movement rules, but doesn't actually do so completely. There are actually two separate issues which we should consider. 1. Validating whether the planes can land somewhere including on a carrier. 2. Enforcing non-combat moves for carriers which were needed for plane movements. I can improve the current algorithm so it works correctly not considering carriers there are not at the end of the route (I believe there is a small bug there, I can elaborate if someone wants me to). Writing the correct algorithm is doable, but you would probably have to introduce some new data structures to keep track of what set of territories a carrier is committed to and how many planes have been commited to that carrier. It would take a lot of thought, because I think you would have to search for a solution to land all the planes everytime you made a move (In a sense you have some sort of scheduling problem). Anyway, I know this situation doesn't occur a lot, but when it does happen it is pretty bad. I am guessing it is easier to write something that helps the user decide if the move is valid but doesn't totally prevent invalid moves. In that case, we should make it clear to the users the level of validation that is occurring. Regards, Ali Ibrahim Sean Bridges wrote: >I think adding a ui to commit to non combat carrier >movement might be more troublesome than its worth, and >confusing for the users as well. > >The validation for the carriers doesnt have to be >perfect. We can just let the logic be flexible enough >that a carrier *could* move to a spot where it can >pick up a plane, rather than forcing the user to >declare that the carrier will move to such a spot. > >We can also ignore corner cases where a carrier might >have to move to 2 different places to pick up >fighters. > >I was thinking a long time ago about changing the >logic so that it checks that planes can land at the >end of combat move, and forces you to make changes >then, but if the planes come under aa fire the moves >cant be undone, and it is possible to get into a >situation where you are stuck. > >Ali, I think that one thing that needs to be done is >that fighter (ie things that can land on an ac) and >non fighter can land validation should be seperated. >Right now they are sort of mished together, and that >makes it more difficult. > >Plane landing validation is quite complex to program >correctly. Scrapping the validation as a temporary >measure is ok. It may be better to have that >validation overwritable. A dialog pops up that says >the planes cant land, but the user can still press a >button that says something like "I know what Im >talking about, let me do it". > >Sean > > > >--- Ali Ibrahim <aha...@ho...> wrote: > > >>Hi, >> >>A player (squirecam) yesterday commented on a bug in >>the movement >>validation of planes where it would not let him >>perform a legal move. I >>went and looked at the code yesterday and it appears >>to be broken. I >>started thinking of how to fix this, but it is a >>very annoying problem. >>The biggest issue is that of being able to commit to >>move carriers >>non-combat. This creates all sorts of problems >>(think about how you have >>to make sure a carrier is not committed to multiple >>place, actually >>moves there if necessary, a ui for allowing the user >>to commit the >>carrier, etc.). One suggestion maybe to scrap the >>can land validation >>until we have a solution since otherwise it will >>cause problems for >>gameplay whereas without it, users will just have to >>be aware that they >>must determine the validity of plane movement >>themselves. >> >>Regards, >> >>Ali Ibrahim >> >> >> >> >> >------------------------------------------------------- > > >>This SF.Net email is sponsored by the new >>InstallShield X. >>From Windows to Linux, servers to mobile, >>InstallShield X is the one >>installation-authoring solution that does it all. >>Learn more and >>evaluate today! >>http://www.installshield.com/Dev2Dev/0504 >>_______________________________________________ >>Triplea-developers mailing list >>Tri...@li... >> >> >> >https://lists.sourceforge.net/lists/listinfo/triplea-developers > > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the one >installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Triplea-developers mailing list >Tri...@li... >https://lists.sourceforge.net/lists/listinfo/triplea-developers > >. > > > |
From: Sean B. <sbr...@ya...> - 2004-06-07 04:06:36
|
--- Ali Ibrahim <aha...@ho...> wrote: > Hi, > > I am just wary of implementing something which gives > the appearance of > enforcing the plane movement rules, but doesn't > actually do so > completely. The question is it having it work 95% of the time while allowing a few illegal moves better than having it work 100% of the time and forcing the user to go through an unintuitive ui step to declare future carrier moves. >There are actually two separate issues > which we should consider. > > 1. Validating whether the planes can land somewhere > including on a carrier. > 2. Enforcing non-combat moves for carriers which > were needed for plane > movements. Case 2 is not handled at present. > introduce some new data structures to keep track of > what set of > territories a carrier is committed to and how many > planes have been > commited to that carrier. It would take a lot of > thought, because I > think you would have to search for a solution to > land all the planes > everytime you made a move (In a sense you have some > sort of scheduling > problem). Anyway, I know this situation doesn't > occur a lot, but when it > does happen it is pretty bad. Yes, we would need code that would analyze a board and return a wether everything could land (and hopefully give a somewhat intelligent error message). We probably dont need to add a new persistent data structure unless we want to enforce carriers moving to pick up fighters in non combat. > > I am guessing it is easier to write something that > helps the user decide > if the move is valid but doesn't totally prevent > invalid moves. In that > case, we should make it clear to the users the level > of validation that > is occurring. > I think this is the best solution. Inxduk, do you have any comments? How did you handle it in firethroat? Adding some documentation about the limitations of this would be good as well. Ali, if you want to write a 100% solution, and you can figure out a good way to handle the ui for declaring non combat carrier moves it would be great. Im not against doing the code the right way, but I dont see how the ui is going to be easy to use and intuitive. Sean |
From: sean <se...@nc...> - 2004-06-07 04:30:53
|
> I think this is the best solution. > > Inxduk, do you have any comments? How did you handle > it in firethroat? Adding some documentation about the > limitations of this would be good as well. > I didn't care and let planes drown if your carriers couldn't reach. It is somewhat difficult because if it is remotely possible for a carrier to be in range the plane's move is legal. For instance, if there are 50 enemy bb's blocking a carrier from moving, and you attack them with 1 sub, it is possible the sub destroys all and in non-combat the carrier can move in and through the seazone allowing planes to land on the other side. so you basically need to see if a carrier can get close enough to let the plane land, then if there are enemy units on this path, make sure at least one path found will have combat in all of the spaces needed (to clear the enemy) Another problem is 2 planes and 1 carrier where each plane needs the carrier in a different place. So what you need is when the user tries to end the turn or maybe even when they move a plane have an allocation system that tries to find ways all of the planes without land in range can land, brute force should work fine by trying all the possibilities and making sure a path exists. I could probably design some sort of recursive algorithm to do this... -- sean <se...@nc...> |
From: Sean B. <sbr...@ya...> - 2004-06-07 04:53:26
|
Hey, I added a new package to commit troys ai code. games.strategy.triplea.troxAI I broke the code in major ways by moving it to a new class, and trying to seperate it from the ui code, but its in and it compiles. Its not working right now (my fault), and its disabled unless you run with the option -Dtriplea.ai=true Sean |
From: Sean B. <sbr...@ya...> - 2004-06-09 14:38:13
|
I added a menu option "Confirm Enemy Casualties". Its enabled by default, but if its disabled, then you will not be prompted to press continue when the game shows your enemies casualties. It uses the Preferences API to save the value across usages of the game. |