Here are a few more issues that I've noticed:

I tested out the Hunter bot in the new version of Pogamut, and although I was pleased to see that the bot was smart enough to jump over obstacles, I also noticed that it sometimes jumped freakishly high, much higher than humans can jump, even using a double jump. I know that in Gamebots the JUMP command has a parameter that allows the height to be customized, but this custom jump also results in bots jumping to a height that is cheating. This is especially a problem for those of us coding bots for BotPrize.

Other than making you aware of this issue, I'm wondering how to edit bots so they can only do regular jumps, and not custom jumps.

-Jacob

Just remembered one more:

The path executor used to have an option to set the focus of the bot, i.e. where the bot looks while it is running around wherever its running. This is important for telling the bot to look at an opponent it is firing at even though it is actually moving towards a nearby item. The class IPathExecutor doesn't seem to have any kind of method associated with setting the focus, so I'm wondering where this functionality moved to.

-Jacob

Hi!

1) Regarding use of parameters, check older thread here:

http://diana.ms.mff.cuni.cz/main/tiki-view_forum_thread.php?comments_parentId=221&topics_offset=6&topics_sort_mode=lastPost_desc&forumId=4
My last big message desribes how to do that, if you would still have doubts after that, please create a new thread and I will expand my comment.

2) Regarding PathExecutor

Yes, it was totally redesigned, the focus is missing in 3.1 but it is present again inside the repository as of yesterday. So I would recommend you to use version from the SVN, may be we will try to make version 3.1.1 but I doubt that as we're trying to move to Maven which is pretty big thing.

3) JUMP command should not allow cheating - its parameters are clamped to certain max/min values which is done inside GameBots2004. Which map you were using when observing Hunter? Where is the place where Hunter is jumping too high? May you provide two NavPoints id? (I.e., FROM/TO where big jump is happening?)

Best,
Jimmy

Thank you very much for the reply. The other post you directed me to did a pretty good job of explaining how to launch multiple bots of different types. The next step for me is creating my own subclasses of UT2004AgentParameters to pass parameters the way I want, so I'll give that a try.

In the meantime, could you post a link to the class that adds the setFocus functionality?

You didn't mention Floyd Warshall. I've found some classes in P3.1 that are associated with Floyd Warshall, but I haven't found anything that looks like a PathPlanner. Are you still working on that?

Maybe I was just imagining things with the Hunter jump behavior ... I'll keep an eye on it and if I still feel like it is jumping in a weird way I'll open a new thread on the issue.

Thanks again.
-Jacob

Hi!

The trick with UT2004AgentParameters will surely work, we're actually using it already in test cases for navigation, so if you have any problems I'm sure we will help you to sort them out.

Regarding Floyd-Warshall, I'm not sure whether I've refactor it, there is a FloydWarshallMap that can serve as a path planner but you will have to wrap it into IPathPlanner interface for yourself. There is actually a problem with FloydWarshall because FloydWarshall works only with NavPoints so you always have to provide it with some starting point which might mean your bot will at first return to that navpoint and then start to run somewhere ... I'm going to fix UT2004PathNavigator soon to prevent such behavior (but this may take month or two...).

When you notice Hunter to perform some big jump, please locate the concrete place first and than try it as a real player for yourself... I've tweaked jumping constants of LoqueNavigator to match heights which normal player may jump to (I've been double-jumping as a player in UT2004). Especially on DM-Goliath there are some nasty double-jump links, which are hard to jump over even as a real player.

Best,
Jimmy

Oh and about setFocus()...

in SVN there is IUnrealPathExecutor that extends from IPathExecutor which is adding setFocus() / getFocus() methods to the interface. UT2004PathExecutor is actually implementing this interface and UT2004BotModuleController is now using that IUnrealPathExecutor instead of IPathExecutor thus you may use setFocus() on the pathExecutor right away (when running version from the SVN).

Cheers!
Jakub

Ok, I think I've found the files I need from SVN.

Regarding the jumping behavior, my point was that using the custom jump looks unnatural no matter how it is used. When a human double jumps, it looks different from a bot using a single jump up to the same height that a human reaches with a double jump. You can actually see humans getting the extra boost at the top of the first jump when doing a double jump. I'm guessing there is some fundamental problem in Gamebots that prevents human-style double jumps. Or does the problem go all the way back to UnrealScript? Therefore, even though I may not be able to jump to certain locations, I would prefer not to use custom jumps at all. I just have no idea where in the code to adjust for this.

Regarding UT2004AgentParameters, I've already put a post in the previous Thread on this issue regarding how to get the passed parameters from the UT2004AgentParameters instance into the actual bot.

-Jacob

Hmm, interesting observation that humans are doing the double jumps differently. Do you have any video where we might check that and compare it with the way the bots are doing it?

GameBots2004 are actually performing true double-jump, that means it first initiate max jump and after a certain (prespecified in the command) time, it performs another jump. It is true that there is another
constant (in JUMP command) "JumpForce", the LoqueNavigator is actively using, may be the problem lies there?

Best,
Jimmy

I think its not about force, but about delay between the first jump in double jump sequence and the second jump in double jump sequence. The default delay I've put into GAmeBots is 0.5 seconds. With this delay it could be seen that the bot actually does the second jump at the top of the first. I know you've been changing this delay to something less when you were implementing Loque PathFinding - i think this is the issue. With smaller then 0.5 second delay, the two jumps just look as one.
So the solution is a) change it in the implementation, b) allow to configure it (which is maybe better)?

best,
Michal

To be honest, I would rather not poke LoqueRunner more - this should be left to guys trying to create bot for the BotPrize competition. Currently the LoqueNavigator handles a lot of jump-edges which is fine, LoqueNavigator was never sought to be "human-like".

Also there is very easy way to plug your own "IUT2004PathNavigator" into UT2004PathExecutor and you can actualy copy-paste code from LoqueNavigator/LoqueRunner and try to adjust whatever needs to be adjusted.

Best,
Jimmy

One more thoughts to BotPrize competition.

(It is actually not mine thought but Michal's) ... anybody trying to create bot for BotPrize competition should adjust LoqueNavigator/Runner as this is the main place that can fail to be "human-like". Movement is a big part of human-likliness in UT2004 so BotPrize developer should target that!

Best,
Jimmy

I think I've found a bug associated with the newly added addFocus functionality. Here's the error message:

(Hunter ENGAGE) SEVERE 03:31:10.987 Fatal error happenned - component bus is stopping.
FatalErrorEvent[
Component: UT2004SyncLockableWorldView
Message: Exception raising event InfoMessageEndMessage | Time = 505.67 |
Cause: class cz.cuni.amis.pogamut.base.component.bus.exception.ComponentNotRunningException: SocketConnection-Writer: In state: STOPPING. (at cz.cuni.amis.pogamut.base.communication.connection.impl.AbstractConnection$ConnectionWriter.write(AbstractConnection.java:537))
Stacktrace: cz.cuni.amis.pogamut.base.component.controller.ComponentController.fatalError(ComponentController.java:607)
cz.cuni.amis.pogamut.base.communication.worldview.impl.EventDrivenWorldView.raiseEvent(EventDrivenWorldView.java:105)
cz.cuni.amis.pogamut.base.communication.worldview.impl.EventDrivenWorldView.innerNotify(EventDrivenWorldView.java:127)
cz.cuni.amis.pogamut.base.communication.worldview.impl.EventDrivenWorldView.notify(EventDrivenWorldView.java:224)
cz.cuni.amis.pogamut.base3d.worldview.impl.BatchAwareWorldView.notify(BatchAwareWorldView.java:83)
cz.cuni.amis.pogamut.ut2004.communication.worldview.UT2004SyncLockableWorldView.notify(UT2004SyncLockableWorldView.java:242)
cz.cuni.amis.pogamut.base.communication.mediator.impl.Mediator$Worker.run(Mediator.java:315)
java.lang.Thread.run(Thread.java:619)
Caused by: cz.cuni.amis.pogamut.base.communication.connection.impl.AbstractConnection$ConnectionWriter.write(AbstractConnection.java:537)
java.io.Writer.write(Writer.java:175)
java.io.PrintWriter.write(PrintWriter.java:412)
java.io.PrintWriter.write(PrintWriter.java:429)
java.io.PrintWriter.print(PrintWriter.java:559)
cz.cuni.amis.pogamut.base.communication.command.impl.Act.sendCommand(Act.java:136)
cz.cuni.amis.pogamut.base.communication.command.impl.Act.act(Act.java:157)
cz.cuni.amis.pogamut.ut2004.agent.navigation.loquenavigator.LoqueRunner.iterateDoubleJumpSequence(LoqueRunner.java:663)
cz.cuni.amis.pogamut.ut2004.agent.navigation.loquenavigator.LoqueRunner.runToLocation(LoqueRunner.java:192)
cz.cuni.amis.pogamut.ut2004.agent.navigation.loquenavigator.LoqueNavigator.navigToCurrentNode(LoqueNavigator.java:623)
cz.cuni.amis.pogamut.ut2004.agent.navigation.loquenavigator.LoqueNavigator.navigAlongPath(LoqueNavigator.java:369)
cz.cuni.amis.pogamut.ut2004.agent.navigation.loquenavigator.LoqueNavigator.keepNavigating(LoqueNavigator.java:204)
cz.cuni.amis.pogamut.ut2004.agent.navigation.loquenavigator.LoqueNavigator.navigate(LoqueNavigator.java:96)
cz.cuni.amis.pogamut.ut2004.agent.navigation.AbstractUT2004PathNavigator.navigate(AbstractUT2004PathNavigator.java:60)
cz.cuni.amis.pogamut.ut2004.agent.navigation.UT2004PathExecutor.navigate(UT2004PathExecutor.java:172)
cz.cuni.amis.pogamut.ut2004.agent.navigation.UT2004PathExecutor.eventEndMessage(UT2004PathExecutor.java:155)
cz.cuni.amis.pogamut.ut2004.agent.navigation.UT2004PathExecutor$2.notify(UT2004PathExecutor.java:47)
cz.cuni.amis.pogamut.ut2004.agent.navigation.UT2004PathExecutor$2.notify(UT2004PathExecutor.java:44)
cz.cuni.amis.pogamut.base.communication.worldview.impl.AbstractWorldView$ListenerNotifier.notify(AbstractWorldView.java:98)
cz.cuni.amis.pogamut.base.communication.worldview.impl.AbstractWorldView$ListenerNotifier.notify(AbstractWorldView.java:77)
cz.cuni.amis.utils.listener.Listeners.notify(Listeners.java:274)
cz.cuni.amis.utils.listener.ListenersMap.notify(ListenersMap.java:76)
cz.cuni.amis.pogamut.base.communication.worldview.impl.AbstractWorldView.notifyLevelAListeners(AbstractWorldView.java:629)
cz.cuni.amis.pogamut.base.communication.worldview.impl.AbstractWorldView.innerRaiseEvent(AbstractWorldView.java:700)
cz.cuni.amis.pogamut.base.communication.worldview.impl.AbstractWorldView.raiseEvent(AbstractWorldView.java:604)
cz.cuni.amis.pogamut.base.communication.worldview.impl.EventDrivenWorldView.raiseEvent(EventDrivenWorldView.java:103)
cz.cuni.amis.pogamut.base.communication.worldview.impl.EventDrivenWorldView.innerNotify(EventDrivenWorldView.java:127)
cz.cuni.amis.pogamut.base.communication.worldview.impl.EventDrivenWorldView.notify(EventDrivenWorldView.java:224)
cz.cuni.amis.pogamut.base3d.worldview.impl.BatchAwareWorldView.notify(BatchAwareWorldView.java:83)
cz.cuni.amis.pogamut.ut2004.communication.worldview.UT2004SyncLockableWorldView.notify(UT2004SyncLockableWorldView.java:242)
cz.cuni.amis.pogamut.base.communication.mediator.impl.Mediator$Worker.run(Mediator.java:315)
java.lang.Thread.run(Thread.java:619)
]

Don't know about the bug, but if you want to adjust the delay of the second double jump, then you should create a subclass or change implementation of class LoqueRunner. There the method that is responsible for double jumps is initDoubleJumpSequence .

Best,
MIchal

Hi Jakub!

This bug should have been fixed in SVN, could you please test it?

Thanks!

Jimmy