Mission 1-3 goto() bug

[Smok94]

Try code:
object o = radar(BlackBox); goto(o.position);
Returns error: Location is occupied, so robot can't get to blackbox.

[tomangelo2]

Couldn't reproduce that, robot goes to Blackbox like it should.
Do you have dev or release build?

[krzys-h]

goto() is known to be sometimes unable to find a path even if it's clearly there. Moving the bot around usually helps. We don't know what causes that yet.

[Smok94]

Version master 0.1.6 (more stable). It happens even i paste this code to my Wheel Grabber right after mission start. It happens for Tracked Grabber to. goto() is very high level function in my opinion, but sometimes get stuck or choses path in the way we don't want. It would be nice to see this function lower level components as Cbot functions, so we would be able to easily customize "goto".

[tomangelo2]

goto() alghoritm will be rewritten in future.

[melex750]

I think goto() finds GoalArea object and thinks it's occupied by BlackBox.

similar to:
int types[] = {Converter, Titanium};
object[] obj = radarall(types); // will return the same object twice. (Two Titaniums)

[Smok94]

My research so far:
Tried too restart mission many times. I happens every time. Tried to download again and overwrite game files (thought maybe mission file is corrupted). Tried to download and run 32-bit portable version (currently using 64 portable). No effect. If i pick up and drop BlackBox i place before program starts everything works right. Tried to launch program standing in front of BlackBox (before was picked up) - still nothing. Tried to launch program when robot stands behind BlackBox (between box and transmitting station) and it worked... one time.

[Smok94]

Trying to reach ExchangeStation and GoalArea with goto aslo makes problem. I think it's may be something about "z" position of objects.

[ghost]

I just tested this with our older master compilations and I think it's actually something wrong with our official compilation of that unfortunate 0.1.5 & 0.1.6 releases or maybe even with whole current master branch! Latest dev builds and, uh, the 0.1.4 works fine with goto() that was a little corrected by @krzys-h for 0.1.4 release back then as long as I remember, but somehow 0.1.5 & 0.1.6 is almost completely disaster. In the dev branch still it's buggy but not as much unplayable that couldn't find a Black Box in mission 1.3.

I think it's time to verify our final compiling methods or master branch, it's looking mysterious...

[ghost]

It's working in latest pre-0.1.7 dev builds so I think this issue can by related to this milestone and officially closed. I hope 0.1.7 master will not repeat the same mistakes again :) .

[tomangelo2]

To check that someone have to build that as a Release build, then test it. Release builds have -O3 flag, that might do some optimizations making goto() alghoritm less reliable.

[krzys-h]

I did test that some time ago, goto() is actually a bit more reliable on release builds because it calculates faster so it sometimes manages to finish before the command times out

[ghost]

@krzys-h I don't get that. How goto() in release builds is more reliable when it refuses to goto'ing to position of the objects more often than in dev builds? I personally prefer to wait some more time for calculating precise way to objects than wait a second and often get ridiculus message that object is inaccessible from very beginning of the program. Stability > speed.

[krzys-h]

Stability SHOULDN'T differ between debug and release, the speed (and therefore allowed complexity of the path before it assumes there is no valid one) does, and the speed is BETTER in release builds. This is confirmed by testing I did some time ago.

[ghost]

Ok, so why it stops the program instead of trying it's best to find the way in such obvious cases like this? IMO it only makes it less reliable and you can't even use this for example in Diversity contests.

[krzys-h]

Like I said previously, I have no idea why it fails in such obvious cases. I only know why debug vs release build matters in more complex paths.

[krzys-h]

I did some testing yesterday and found a commit which caused this

• bad: [88c6818] Fix code style issues
• good: [98124cd] Removed polish README
• good: [1be66b4] Update translation files
• good: [8922bb5] Renamed CGLDevice to CGL14Device
• good: [397e312] Fix RestoreState for subclass instance vars
• bad: [81aae35] Updated translation files after 4a14a44
• good: [b9d4d57] Syntax sugar: Accessing members of returned objects (Syntax sugar: Accessing members of returned objects #808)
• good: [e3b3d7c] Enable debug info for MSVC
• bad: [84c9854] Merge pull request Method chaining for constructor calls in CBOT #819 from melex750/dev
• bad: [859cec7] Added comment explaining container choice
• bad: [88227a3] Allow multiple objects with exactly the same distance to be returned by radarall
• first bad commit: [88227a3] Allow multiple objects with exactly the same distance to be returned by radarall

[krzys-h]

No idea what actually caused it to fail after this commit, I'll look into that later

[krzys-h]

It seems to be related to CTaskGoto::SearchTarget. When using std::map, the function returns:
ID=37 BlackBox
but when using std::multimap, it returns:
ID=35 GoalArea

[immibis]

I always wondered how goto knew which object to line up with...