Spring RTS Engine

Recently, I had a bit of free time and thought of porting my old Java AI (it was never released) to the new interface. After a bit of fiddling, I managed to have it compile again and have it run.

Now I still seem to have some odd problems with it.
1) Building structures [SOLVED]
At the start of the game, I have my commander create a number of buildings. Once he finishes building one structure, I give him a new build order. I only give him build orders, no movement or otherwise. However, it seems that with the new AI, after he has finished building, he returns back to where he was when the order was given, meaning he's always returning to his spawn location whenever he builds something, and then doubling back for a new build order.
Old code: Code that makes him work somewhat better, but still broken (he needs to travel outside of the build place every time): timeout is 10000, and opts are -1.
So I'm mostly curious what caused the change, and how can I have the old behavior (only build orders were necessary) back?

2) Building units [SOLVED]
It does not work. I have a vehplant which is supposed to be building jeffys, flashes and construction vehicles, but it seems to simply be ignoring the commands (and I have confirmed that the vehplant is finished and can build those unitdefs, it used to work fine before).
This is code that I have tried so far: I've also tried the timeout factor (15 in examples above) to be 10000 with no effect. Also it may be worth noting that I get kind of errors after a while (not soon after the vehplant is built and units should be being built). I tried looking at how the interface and wrappers work, but it all seems solid - no idea on what's causing the problem, and I'm getting no errors, which is the worst part.

3) Missing command-ID constants
Usually, I'd have units work with commands, and as soon as it finished something, and caused unitIdle to trigger, I'd look at what it's completed (by commandTypeId) and then based on that send it off to do other things. While it's still possible to do that, it seems the files that had commands with their type-ids, are gone, so one would have to write down type-ids himself (42 is moving, 35 is building and so on) instead of using an enumeration like .
Sure, nothing is stopping me from creating those enums myself, but I would've hoped they existed in the generated Java interface/wrappers (maybe they do already?), instead of forcing me to have an open C/C++ .h file where those are written (took me some time to find, and I'm not new to spring).

1

That's because you are always passing the location of the builder as the target for the structure your building, rather than finding a more appropriate place.

AF wrote:1

That's because you are always passing the location of the builder as the target for the structure your building, rather than finding a more appropriate place.

Sorry if I failed to explain it properly, but that's not what I'm doing at all. The "position" argument is something that I have previously calculated (a metal spot location, a suitable building position and so on).
The example (second code snippet in 1) where I used to move the commander to the position before I gave it the build command was done so he wouldn't be returning all the way back to the spawn.
To try better explain it (what's happening in first code snippet in 1):
Imagine commander spawns at (10, 10) (let's ignore height for now)
I send the "build mex at (50, 50)" command.
It does the following:
Goes near (50, 50) and builds the mex, goes idle, and returns back to (10, 10).
If I send another "build mex at (120, 70)" command it will go from (10, 10) to somewhere near enough (120, 70) and then back again to (10, 10)

It seems that the "move back" command is somehow automatically given to the commander, and my next build order is appended (much like the shift commands in GUI), instead of overwritting it.

You dont need to tell a builder to move to the building site, it will do that automatically. If you DO however there need to be set options for queueing commands, or you can use Unit Idle to chain events, but Im unfamiliar with command options in the Java API

AF wrote:You dont need to tell a builder to move to the building site, it will do that automatically. If you DO however there need to be set options for queueing commands, or you can use Unit Idle to chain events, but Im unfamiliar with command options in the Java API

I don't want to tell him that, in fact I used to be able to just send the build command, he would then automatically move there and build stuff, and stay there.
Now however he would always return back from where he came. I've posted a few example pictures of what's going on with just the .build(..) command:
You can see the initial build order there, when it's building the 2nd and 3rd mex, and going off to build a solar plant, it is going back to the spawn for some reason

hmmm that should not be happening, are you sure there's no other code or command queueing that's interfering? It doesn't happen in the other AI interfaces, and the code that controls the sub-AI is in the engine, so it should be happening for all AIs ( and human players too ), yet it isn't.

Well, I have checked and double checked my code, but I will keep looking as I may yet end up finding something. The thing is, I'm not issuing any move orders, I even disabled the "military" and "economy" managers (military issues attack move orders, but only for vehplant units). The only thing I'm doing now is building stuff, and only using the .build command. And well, the code did work before the interface change (2 years ago or so), I might've screwed something in the transition progress, or the Java API has some errors - I'll search the code a bit.

Btw, are there any other working Java bots (with the OO interface)? I may find the problem by looking at their code.

Well, damn, I figured 1) and 2) out, it seems the "options" parameter shouldn't be -1, setting it to 0 fixed both problems. Wish it was documented in Java so I had a clue of what it did without having to go to that .h file. Seems it would set a couple of flags improperly, shift, control, alt, right mouse click and don't repeat, judging by (assuming -1 is represented as 0b11...10):

[f=0026298] Warning: Waiting packet limit was reached for gajop AI #1 [packets dropped]

thats because your ai sends to many packets / second. this limitation was added because of some broken widgets.

edit: posted a pull request, so this isn't needed