Many people have written many things about sharpening the axe. I think a lot of software developers encounter this type of problem, when the tools – IDE, editors, etc – are good enough, but there is a new one on the horizon. The term toolbox has been around for a while, to describe the various software (or sometimes hardware) instruments at a developer’s disposal. Jeff Atwood wrote a masterpiece using this analogy. So yeah, don’t use PHP double-clawed hammers, if you can help it.

A lot of people think that if they have invested a lot of time and effort into a tool, and it’s actually doing it’s job, then there is no need fixing what ain’t broke, goddamnit. If you don’t believe me, just tell someone who uses vi that there are other text editors. (At your own risk)

For a long time, I thought like that – I was even skeptical of Git! But there is actually no real disadvantage checking out new stuff, and switching, besides a marginal time investment (I don’t consider learning new hotkeys a big commitment) So instead of sharpening my axe, I’m a believer in making the whole toolbox better. Not overdoing it either – there is an actual limit to an axe’s sharpness, and it is reached way before grinding it for four hours (Source(s): dude, trust me). And an axe is not the best tool when you have to tighten some screws, so you have to have multiple instruments. And keep those sharp, filed, grinded, properly oiled, filled with fuel, whichever is applicable. In short, keep the toolbox sharp.

Bearing that in mind, I periodically revisit the (software) tools I use. Not doing so, because I invested a lot of time into this is not a good argument against it. It can be a sunk-cost fallacy Also, often in my job I encountered the situation “We know it’s bad, but it would be a lot of work to rewrite everything”. Most of the cases, it was not that great amount of work, people just like to hang on to their past mistakes decisions. In the end it all boils down to: “But we have to do work“. It is not a good excuse. (Please don’t apply this logic when raising children)

In the past, I carefully weighed the cost of learning something new, and the benefits gained from it. This seems like a smart idea, but I realized, that I can’t really estimate the first part accurately. Also, I can usually find some time which I would just waste watching cat videos (Do people still do that? I still do that) or something – might as well do something useful instead. 

Enough philosophy, onto the actual stuff I did.

I decided to switch to IntelliJ IDEA from Eclipse. I don’t want to hate on Eclipse like so many other people do, but it has it’s share of troubles. And I use IDEA at work anyway, and in general, it seems like a better tool for the job. The nice people at IntelliJ have even provided a handy guide for guys like me. It was a big decision, and I’m sure there are things I will miss.

For some reason, both the Eclipse and the IDEA authors thought that it would be a good idea to bind the ctrl+alt+b, and ctrl+alt+f (or alt gr + these letters) to some very useful function, like refactor, or change a bookmark when there is a full moon. I’d wager most keyboards don’t have a dedicated “[” and “{” button, and these characters are somewhat common in programming circles. Here is how to unbind these (Searching for the shortcut would have been easier, but it didn’t work for me)

In my last post I made the decision to switch to BWAPI4J. I’m going to focus on that for the moment, and document my journey here.

The BWAPI4J repository fortunately has detailed instructions to install it. I don’t expect this will be done without problems, though. (Spoiler alert: I was right)

The first thing was when I was building the bridge i consistently got the “Failed to find file: VsDevCmd.bat” error message. After re-setting, and confirming that my Path system environment variable indeed contained the folder containing this file, I Googled around, and it’s a known issue. Still, it didn’t work for me, so I manually added the correct path.

Next one is somewhat trivial, but I didn’t know at first what happened. So, the gradle script ./gradlew buildVanillaBridgeForWindows failed with the message:

The imported project “C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

Since I’m not experienced with the C++ stack, I decided to annoy my fellow BWAPI4J developer, and beloved proofreader Jabbo.

(One respectful conversation later) the problem turned out that I was missing the C++ tools from Visual Studio. Yeah, stupid. Also, you need version 1.8, and 32-bit JDK, and the JAVA_HOME path should contain a backslash at the end, otherwise the gradlew command won’t find it. 

Current BWAPI4J version requires BWAPI 4.2.0 version installed. You can find the latest release here. 

When building the jar, or the dll files, you might encounter errors where you are unable to write to files, or access ports. I found that running my command line (I use Git Bash on Windows) in administrator mode usually solves these.

I managed to import my bot into IntelliJ with relatively few hiccups. Now it’s time to switch to BWAPI4J. I’m using a lib folder locally like a pleb, and using BWMirror, and BWAPI4J jars from there. Also, because I actively work on BWAPI4J, but mostly because my inherent plebeian tendencies.

This – predictably – caused almost all my code to be invalid. First I tried to just import the existing JumpyDoggoBot codebase and change the parts, but that’s not the way – I need to build it up again, part by part. Fortunately, someone wrote down the exact steeps needed to do that!

I will document the BWAPI4J lib’s workings, and the process of adapting my bot in a different post. Currently, it’s under a great rework, and I don’t want to spend time documenting the soon to be deprecated methods – Also, it’s gonna be a greater topic, so better begin it in a separate post.