Auto-Jimmy v0.9.1: Now with custom sector support

CthulhuStig

Mongoose
The time has finally come for me to release the next version of Auto-Jimmy. For those that don't know, Auto-Jimmy is an open source app for Windows, macOS & Linux. It provides a selection of tools for Traveller players and referees, some of these are aimed at people using the Mongoose rules, but many can also be used for other Traveller variants.

This release adds a few new features, the most notable of those being custom sector support. Just to try and temper everyone's expectations slightly, this isn't a full-blown interactive sector editor. You'll still need to create T5 column/row sector files and corresponding XML/JSON metadata. If you've ever used the Traveller Map Poster API to generate images of a custom sector, then it's the same files you used for that.
The sector files can be imported into Auto-Jimmy to allow it to include the data in features such as the jump route planner and trading tools. In addition to this, Auto-Jimmy will use the Traveller Map Poster API to generate a set of images of the sector. Then, as Traveller Map requests the tiles it uses to display the universe, Auto-Jimmy will live composite the posters onto the tiles so that your sectors are (almost) seamlessly integrated into the rest of the Traveller universe. As I said, the compositing isn't quite seamless, but hopefully it's good enough that people will find it useful. The kind of thing you might notice is visual artifacts around the edge of custom sectors, or slight pixelisation if you zoom in as far as it will go.

Release Highlights:
  • Custom Sector Support
    • Custom sector data integrated into all tools
    • Posters of custom sectors automatically generated and overlaid onto Traveller Map views
    • Support for T5 Column & Row sector files and XML & JSON metadata
  • Improved Tile Caching
    • For improved performance, Auto-Jimmy will now maintain a cache of the tiles Traveller Map uses to display the universe
  • Fuel Based Jump Route Calculation
    • Jump route calculation now takes ship fuel capacity and fuel usage per parsec into account when calculating the best jump route
    • Improved lowest cost route calculation
    • Improved support for ships that can jump further than their jump rating without refuelling
    • Support for ships that don't use the standard amount of fuel per parsec
  • Faster Universe Updates
    • Update time down from multiple minutes to just a few seconds
    • Automatic universe update check at startup
  • Interface Scaling
    • A scaling factor can now be set for the user interface to aid readability

Unfortunately, documentation for Auto-Jimmy is still pretty limited, I've been too busy doing feature work to improve it much. I highly recommend you read the welcome messages that are displayed when you first open a feature window, they should cover everything you need to know. Hopefully better documentation will be coming soon. If you do hit a problem you can't get round, leave a comment here or raise an issue on the github project, and I'll see what I can do.

If you're going to use the Windows installer, I should warn you that it's not digitally signed (as that costs money). This means your browser may warn you about it not being a frequently downloaded program and/or make you confirm that you want to download it. Also, when you run the installer, Windows will almost certainly warn you that it's an unknown app and make you jump through hoops to install it.

If you've previously cloned the Auto-Jimmy repo or downloaded the source from github, you'll need to re-run the command to have pip install requirements.txt as the new version pulls in additional Python packages. There is also an optional (but recommended) step to install the Cairo library for better results when compositing custom sectors. Detail on how to do both can be found in the installation instructions in the Auto-Jimmy repo readme.

Project Links:
Source and Docs: https://github.com/cthulhustig/autojimmy
Windows Installer: https://github.com/cthulhustig/autojimmy/releases
Screenshots: https://github.com/cthulhustig/autojimmy/blob/main/docs/screenshots.md
Known Issues: https://github.com/cthulhustig/autojimmy/blob/main/docs/known_issues.md

Finally, a massive thanks goes to Joshua Bell from Traveller Map for his help making the custom sectors possible.

Update: I've add some additional documentation covering custom sectors
https://github.com/cthulhustig/autojimmy/blob/main/docs/custom_sectors.md
 
Last edited:
This is a nice piece of software! Have to check it on my home PC, but from the screenshots and descriptions... wow! Thx for creating this and working on it! On top of that I am a fan of Python myself, though so far I never really found time to dive into it to make something more than "Hello World" (though I started a few times already).
 
Thanks @JoeKundlak. I'm a big fan of Python, there's a huge amount of help/documentation and it does a LOT of heavy lifting, leaving you free to concentrate more on actual feature development. To be honest, Auto-Jimmy probably wouldn't exist if it wasn't for the fact it makes it so easy to get things working quickly, it really helped keep the motivation up. The only real issues I have with Python is, depending on the what your trying to do, the lack of real multi-threading can complicate some things and, when projects get large, the lack of type checking can make some types of changes more bug prone.
 
Weren't both these issues already tackled or approached somehow in the newer 3.x versions? I vaguely remember reading something somewhere, but as I am not working in Python myself (yet?), might have been something else (or just a talk about these negatives).
 
It does have "threads" but it also has the GIL (Global Interpreter Lock) which means it will only ever run code from one thread at any point of time. This means you can have multiple threads and, if one blocks on IO, another thread can do work. However, if you do CPU intensive work in your threads you don't get the benefit from having multiple cores in your system. You can work around it by spawning additional processes. Python makes that really simple to do but the interprocess overheads can be a problem if your doing something that involves a lot of very small jobs that aren't being started in batches, also spawning multiple processes just seems a little ugly. I think there are alternate Python interpreters that get rid of the GIL to allow true multi-threading but I've not tried any of them.
There possibly is a way to do some form of type static/runtime type checking. I've used the typing module to annotate type info on all the Auto-Jimmy code, that lets the IDE do things like auto complete which helps a lot, but I've not found a way to have it automatically generate a runtime error/warning if you do somethig like pass an unexpected type into a function. It feels like something that should be possible when the code has type annotations, I might take another look when I get a chance.
 
Yeah, from looking these up I see this is still an open question generally with patches applied where necessary (i.e. removing GIL would cause backwards compatibility to fail for some code that builds on it and that removing GIL would slow singlethread a bit etc.). Hopefully things can get developed towards remedying this!
 
Back
Top