After my findings from my other post, where I manually modified a tileset to add a bleed around my tiles, I got lazy and decided never to do that again. From that decision rose a small project to handle various changes to tilesets, aptly named: tileset tooling. My first use case: automating bleed addition to tilesets. In this post, I’ll go over a few of the details on how I built the tool and a few usage examples.
Getting the tool
The tool relies on imagemagick. The first thing to do is to install that library:
sudo apt-get install imagemagick.
Then there are two ways of getting the tool:
- the easiest way is by adding the tool directly in your path by installing through RubyGems:
gem install tileset_tooling
- follow the documentation in the project readme and setup as a developer to run directly the checked-out code
As previously said, the tool only has one real feature: adding a bleed to a tileset. The tool handles two use cases:
- a tileset that already has a margin, where one pixel of said margin will be replaced with the bleed
- a tileset that does not have any margin, where the tool will add a 1-pixel margin and put the bleed there
Running the tool for both of these scenarios is done the same way:
tileset_tooling bleed insert test/data/simple_no_margin.png.
Right now, there is not much more to say. More information can be found in the tool’s wiki and a rdoc file contains all arguments and commands.
Future of the tool
Right now, nothing specific is planned for the tool. I do plan on playing with Unity, and tilesets, so a few more features might come from there. Users are also free to request features directly through GitHub.
As a developer, I do not have any real Ruby experience. Also, I’m quite new to the whole Unity/tileset world. Any help is welcome, from anyone with any background 🙂
When I started this blog, one of my goals was to push myself to work on more personal projects. While setting things up for the blog I wanted to start tracking things I need to do using Google Tasks but had trouble handling recurrent tasks. Basically: they don’t support recurrent tasks.
That gave me the idea for my first little project: a simple script to handle recurrent tasks. Basically, I want to go for a flow that roughly looks like:
- Build a configuration file to describe the recurrent tasks I want; In there, I’ll describe at least:
- The task, aka name, description, etc.
- The period (every month, every first Monday of the month, etc.) and the deadline;
- Have a script to ensure that the tasks that are currently needed are created (or completed already);
- Run said script in a cron task on my RaspberryPi;
I did try to find a clean way of doing this. Some people do it through recurrent events in their calendar, but I really wanted tasks, not a weird workaround. I know I could use some other tool, but I’m trying to get in touch with Google services and I felt like this was a nice-enough reason to start looking into these.
Once I get the basic flow working, I’ll also be able to piggyback on this small project to do a little something with my GPIO setup or play with an Android App. I’ll see once I get there, there are still quite a few things I want to do before getting to these subjects.
I haven’t even created the GitHub project yet, I’ll do this and the basis of the script this week and update my blog next week!
Do you know of anything that allows recurrent tasks in Google Tasks? Is there anything you’d like in a tool like this?
Thanks for reading!
* Update: more information about the project in a new post: Introducing RTasker basis and vision