No, you need the Boss Star V to do that (not available to users yet, only to the devs). BS IV however, does allow you to command Paladins tho.
Speaking of which, how are you defining your āpaladinā? I tested your move code using one of the ā1000 Flowersā levels. I had to summon a soldier, instead of a paladin, but the move concepts are the same. My test soldier move where I told him to. However, it took me a couple of tries to get his definition correct.
I compared your paladin heal statement against one I used in another level and it looks fine.
That leaves the definition of your paladinā¦in my test, I used:
Oops, I just realized I was incorrect on the summon paladin pointā¦obviously, IV does give that ability. There was a thread about that, somewhere, and I mis-remembered.
Unless you command him to do so, he should not.
When I run the code, I follow the paladin all the way to the east edge and keep attacking until heās dead, taking no damage myself.
where is the paladin going: left, right or staying at the same place?
hero.summon("paladin")
condition1 = True
condition2 = True
paladin = hero.findByType("paladin")[0]
hero.moveXY(hero.pos.x +5 , hero.pos.y +5 )
while True:
if condition1:
hero.command(paladin, "move", Vector(paladin.pos.x + 1, paladin.pos.y))
if condition2:
hero.command(paladin, "move", Vector(paladin.pos.x - 1, paladin.pos.y))
# the hero "movement" is obvious
if condition1:
hero.move(Vector(hero.pos.x , hero.pos.y + 1))
if condition2:
hero.move(Vector(hero.pos.x , hero.pos.y -1))
Iām asking @dedreous, @Deadpool198, @brooksy125 because almost all answers to questions about issuing successive commands are a mess ( example: Grim determination level)
That is a pretty good question! Iām going to pose: while the āmoveā command is prevalent in both the paladin and hero statements, the methods are different. It appears that once the paladin move fires, it is forgotten (code is ignored).
Check out this test:
while True:
# the hero "movement" is obvious
if condition1:
hero.move(Vector(hero.pos.x , hero.pos.y + 1))
hero.command(paladin, "move", Vector(paladin.pos.x + 1, paladin.pos.y))
if condition2:
hero.move(Vector(hero.pos.x , hero.pos.y - 1))
hero.command(paladin, "move", Vector(paladin.pos.x - 1, paladin.pos.y))
# if condition1:
# hero.command(paladin, "move", Vector(paladin.pos.x + 1, paladin.pos.y))
# if condition2:
# hero.command(paladin, "move", Vector(paladin.pos.x - 1, paladin.pos.y))
In my initial test, I moved the hero conditions above the paladin and result was identical. With this next test, I combined the move statementsā¦both are dancing now.
Okā¦I can only guess at the method. Iām thinking that the hero.command move is actually leveraging the moveXY method.
Try swapping the +1 and -1ā¦the paladin then moves to the right. And, if you add another condition1 (or 2) statement, reversing that last paladin moveā¦that is the direction he goes. Itās stopping at the final condition statement, in spite of the loop. Since it does not do this for the hero moves, the methods must differ.
Beyond that, I donāt have an answerā¦perhaps Danny or Brooksy might.
Make this search. User htrnblr was maybe the first to show how to issue successive commands - itās in the āGrim Determination - paladin problemā , but I think all these topics show the right solution.
I guess Iām not understanding the question then. As was stated in that post, āif, elif, else is already understoodā. That was my assumption too.
Are you asking why only the last statement is being fired in a stacked series? If yes, then you might need Nick for that oneā¦no, I wonāt give him a shout
if paladin.canCast("heal"):
hero.command(paladin, "cast", "heal", target)
hero.command(paladin, "shield")
hero.command(paladin, "attack", enemy)
##############################################
if enemy:
hero.command(friend, "attack", enemy)
if friend.health < friend.maxHealth:
hero.command(friend, "move", {'x':44, 'y':44})
######################################################
hero.command(friend, "move", {"x": 40,"y": 35})
if enemy:
hero.command(friend, "attack", enemy)
###############################################
## and this code is accepted as solution
if enemy:
hero.command(paladin, 'attack', enemy)
inNeed = lowestHealthPaladin()
if inNeed and paladin.canCast('heal'):
hero.command(paladin, 'cast', 'heal', inNeed)
if paladin.health < paladin.maxHealth * 0.5:
hero.command(paladin, 'shield')
``` Can you foresee what piece of code will be executed and why? This kind of errors are almost never spotted and corrected, because the code somehow works...
I never realized you couldnāt layer the commands for your friends like that, especially when using conditional if statements. I do remember some times when I couldnāt understand why it wasnāt working like I expected and this may have been part of that issue.
Now I just know to use if-elif-else to determine the condition before commanding. I recognize the 2nd one on your list. I commented on that one today. I didnāt run the code they had, just gave the suggestion to build your checks so you only run one command. Now that I run their code, I see my comment wasnāt accurate, the code jumps to the second if command.
So essentially, you can only command each ally once in a loop and the last command is the one it will follow. These are the details that need to be explained better in the levels. The specific commands could use more detail. hero.command ("move") seems to act more like hero.moveXY() instead of hero.move() as @dedreous puts it fire and forget.
Lack of documentation would be my biggest complaint about CodeCombat.
Same. I first came across this properly, and realised what was going on in Kelvintaph defiler; I always found they just went with the last command, if the conditions of the two actions they had to choose from were both true.
Now, like brooksy, I use if-elif-else.
I think youāre on to something here.
Iām afraid I canāt really add anything to that.