Questions about checkAIPlayer(s)/isAIPlayer(s)
-
With @Alexei-Svitkine help, we are developing a way for map makers to query players AI status. There are a few questions about this, which I would like to ask before submitting the final request.
<!-- Allowing **players** option: --> <attachment name="conditionAttachmentAlliedAreAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="checkAIPlayers" value="true"/> <option name="players" value="Russians:British:Americans:Japanese"/> </attachment>
Here the Italians player is checking the status of Russians, British, Americans, and Japanese players, and the method should in with s. If the players options is not used then the above would only check the Italians player, as they are the attachTo player, and the method should not have an s on the end.
Each player could be checked separately and their conditions could be AND/OR together to provide the same results.<!-- check the false value --> <attachment name="conditionAttachmentItaliansNotAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayer" value="false"/> </attachment>
The above will return true if the false value is checked and the Italians are not an AI player and the method would be called isAIPlayer. If the false value is not checked then the above will return true even if the Italians player is AI controlled, because false would mean not to check, and call the method checkAIPlayer.
My thoughts only check the attachTo and ignore player if that option is used, also ignore the false value if used, since the invert will give the same result.
<!-- the Italians are not AI controlled so this returns false--> <attachment name="conditionAttachmentItaliansAreAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="checkAIPlayer" value="true"/> <!-- this is ignored and only attachTo="Italians" is checked --> <!-- <option name="players" value="Russians:British:Americans:Japanese"/> --> </attachment> <!-- invert used instead of "false" --> <attachment name="conditionAttachmentItaliansAreNotAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="conditions" value="conditionAttachmentItaliansAreAI"/> <option name="invert" value="true"/> </attachment>
Confusing, LOL I understand.
Cheers...
-
Im not sure these suggestions are valid but here goes.
Is below a simplier version of your examples above?
<!-- Are All Allied also all AI ? --> <attachment name="conditionAttachment_Are_Allied_All_AI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayer" value="Russians:British:Americans:Chinese"/> </attachment>
<!-- Are Italians AI ? --> <attachment name="conditionAttachment_Are_Italians_AI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayer" value="Italians"/> </attachment> <!-- In both of the above invert can be used <option name="invert" value="true"/> -->
-
Confusing, sorry, trying to think, write, code, take medication, yell at the wife, pet the dogs...
But you do have a different take on this. One that I haven't thought of. Instead of having value="true" your thinking is that value should equal a list of players.
Thank you for your thoughts!
Cheers...
-
@wc_sumpton said in Questions about checkAIPlayer(s)/isAIPlayer(s):
With @Alexei-Svitkine help, we are developing a way for map makers to query players AI status. There are a few questions about this, which I would like to ask before submitting the final request.
<!-- Allowing **players** option: --> <attachment name="conditionAttachmentAlliedAreAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="checkAIPlayers" value="true"/> <option name="players" value="Russians:British:Americans:Japanese"/> </attachment>
Here the Italians player is checking the status of Russians, British, Americans, and Japanese players, and the method should in with s. If the players options is not used then the above would only check the Italians player, as they are the attachTo player, and the method should not have an s on the end.
Each player could be checked separately and their conditions could be AND/OR together to provide the same results.I definitely don't like this thing of having a "checkAIPlayers" and a "checkAIPlayer", and I don't think there is any other case of something which ignores the "players" option. I think that, instead of these two options, there should only be a "checkAIPlayer" (not sure about a better name) option which refers to the attached player if there is no "players" option and to the "players" option in an OR relationship if there is the option. If wanted, this "checkAIPlayer" can have a "count" which means that at least that may players need to be AI controlled (the count being 1 if absent of course).
<!-- check the false value --> <attachment name="conditionAttachmentItaliansNotAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayer" value="false"/> </attachment>
The above will return true if the false value is checked and the Italians are not an AI player and the method would be called isAIPlayer.
This is very confusing and logically wrong as a matter of naming (because, if you have something called "isAIPlayer" which is "false", you are simply stating that that player is not AI), but I don't know what a correct name for this thing would be. Generally speaking, a false boolean in TripleA is normally the same thing as not having the boolean, so I don't feel like this is the right way to do it: if you want something that returns true if a player is not AI, I would rather have a condition which returns false if the player is not AI and using the "invert" to get a "true" out of it (or having a "checkHumanPlayer" but no need thanks to the "invert").
If the false value is not checked then the above will return true even if the Italians player is AI controlled, because false would mean not to check, and call the method checkAIPlayer.
I think this part is too unclear.
My thoughts only check the attachTo and ignore player if that option is used, also ignore the false value if used, since the invert will give the same result.
Is there any other instance in TripleA where something looks for the attached player and ignores the "players" option? I think that the player options as of now absolutely prevails over the attached player and the attached player matters only if the option is absent and is logically the same as having the option with the attached player as the only value? If this is currently the case, I would not start making exceptions to it.
<!-- the Italians are not AI controlled so this returns false--> <attachment name="conditionAttachmentItaliansAreAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="checkAIPlayer" value="true"/> <!-- this is ignored and only attachTo="Italians" is checked --> <!-- <option name="players" value="Russians:British:Americans:Japanese"/> --> </attachment> <!-- invert used instead of "false" --> <attachment name="conditionAttachmentItaliansAreNotAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="conditions" value="conditionAttachmentItaliansAreAI"/> <option name="invert" value="true"/> </attachment>
Confusing, LOL I understand.
Cheers...
Surely.
Anyway, I think being able to check if a player is AI is a nice option ("Feudal Japan" comes to mind), so I hope you'll get this done.
-
@thedog said in Questions about checkAIPlayer(s)/isAIPlayer(s):
Im not sure these suggestions are valid but here goes.
Is below a simplier version of your examples above?
<!-- Are All Allied also all AI ? --> <attachment name="conditionAttachment_Are_Allied_All_AI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayer" value="Russians:British:Americans:Chinese"/> </attachment>
<!-- Are Italians AI ? --> <attachment name="conditionAttachment_Are_Italians_AI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayer" value="Italians"/> </attachment> <!-- In both of the above invert can be used <option name="invert" value="true"/> -->
This is strange because it makes the attached player wholly pointless, so why even having it at all? Moreover, I think it would be the only case in which something else does what is otherwise always only done by the "players" option. Of course, the same can be said of the "players" option itself (about making the attached player pointless), and indeed I think it would make more sense to allow for attaching to multiple players rather than having a "players" option (but this is already what it is).
-
@cernel
I agree, but it does allow condition testing and therefore trigger actions which can be used to help/control AI players.Is there a better way?
-
@cernel said in Questions about checkAIPlayer(s)/isAIPlayer(s):
This is strange because it makes the attached player wholly pointless, so why even having it at all? Moreover, I think it would be the only case in which something else does what is otherwise always only done by the "players" option. Of course, the same can be said of the "players" option itself (about making the attached player pointless), and indeed I think it would make more sense to allow for attaching to multiple players rather than having a "players" option (but this is already what it is).
You are correct the "players" option overrides "attachTo" so if I write a condition like:
<!-- Override "attachTo" with "players" --> <attachment name="conditionAttachmentAlliedAreAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayers" value="true"/> <!-- only Russians, British, Americans, Japanese are checked not the Italians --> <option name="players" value="Russians:British:Americans:Japanese"/> </attachment>
What makes it even more weird is that the calling trigger can be owned by a different player:
<!-- Calling Italians attachTo condition with Germans attachTo trigger --> <attachment name="triggerAttachmentAlliedAreNotAI" attachTo="Germans" javaClass="TriggerAttachment" type="player"> <option name="conditions" value="conditionAttachmentAlliedAreAI"/> <option name="notification" value="ALLIED_ARE_AI"/> <!-- Now the fun part, when can reference Japan --> <option name="when" value="before:japanUserActions"/> <option name="uses" value="1"/> </attachment>
So, yea... Before Japans UserAction, the Germans, only, will be notified if the Allies are all AI controlled. Fun!!
Cheers...
-
So what I have now will evaluate both true and false, and also use "players":
<attachment name="conditionAttachmentAlliedAreNotAI" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayers" value="false"/> <option name="players" value="Russians:British:Americans:Japanese"/> </attachment>
Will only return true if all "players" are not AI controlled. If any "players" are AI controlled, then false is returned.
Ok?
Cheers...
-
As isAIPlayers can only be true or false would it be better to drop the s and just have isAIPlayer?
Do you have to do anything special to make it work with foreach?
Otherwise looking good!
-
@thedog said in Questions about checkAIPlayer(s)/isAIPlayer(s):
As isAIPlayers can only be true or false would it be better to drop the s and just have isAIPlayer?
I've put the (s) on the end to designate the use with "players" option, Then again, isAIPlayer/isAIPlayers either is ok with me.
@thedog said in Questions about checkAIPlayer(s)/isAIPlayer(s):
Do you have to do anything special to make it work with foreach?
Nope, I've used "foreach" in the testing:
<!-- Using foreach to create a true test per player --> <attachment foreach="$All_Players$" name="conditionAttachmentIsAI@All_Players@" attachTo="@All_Players@" javaClass="RulesAttachment" type="player"> <option name="isAIPlayers" value="true"/> </attachment> <!-- Using foreach to create a false test per player for Italians --> <attachment foreach="$All_Players$" name="conditionAttachmentIsNotAI@All_Players@" attachTo="Italians" javaClass="RulesAttachment" type="player"> <option name="isAIPlayers" value="false"/> <option name="players" value="@All_Players@"/> </attachment>
@thedog said in Questions about checkAIPlayer(s)/isAIPlayer(s):
Otherwise looking good!
Thank you kindly!
Cheers...
-
Looking even better!
-
Suggested updates to PoS2 for isAIPlayer:
In the "<!-- National Objectives and Condition Attachments -->" area, line 2939 between "switch" and "turns" (which should be updated to "rounds":
<!-- National Objectives and Condition Attachments --> <!-- ... switch values: "true" or "false" (default is true). This is just a simple on/off switch, which gives map makers some memory function for their conditions. isAIPlayers values: "true" or "false" check if player is AI controlled. rounds values: which rounds this will be checked on (example: value="1:4:6-8:11-+" means rounds 1,4,6,7,8,11, and all rounds after 11) ... -->
And then "conditionAttachment_Americans_Aid_UK" can be changed to reflect the usage:
<attachment name="conditionAttachment_Americans_Aid_UK" attachTo="Americans" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <!-- is the Americans not AI controlled --> <option name="isAIPlayers" value="false"/> <!-- players can be added to check both Americans and British --> <!-- <option name="players" value="Americans:British"/> --> </attachment>
All I can think of---
Cheers...