I can smell the arms race heating up again

I guess it's hardly surprising: my fixing attempt didn't pan out too well. My compressor was huffing and my airbrush was puffing but the paint - it didn't bother moving anywhere. These results were recorded earlier today, in the late afternoon, when I tried it out.

My scapegoat

That's it. The replacement pipe doesn't hold or pull or anything. So a new airbrush is to be bought!

If you think that (as far as I know) this device was a thing worth about 15 euros when I received it and I've used it very, very happily for a bunch of years, it hasn't been a bad tool at all! Of course this doesn't mean that I wouldn't lose it when I go and get a successor for this worthy piece of handyness...

Baby steps in the cockpit

The workstation first

Following the honoured traditions of aircraft assembly, as always, I started this build with the cockpit. To my great surprise I already found myself thinking of doing some belts for the crew, because "they need their seat belts, you can't fly without them". So yeah, I've totally and officially lost my marbles.

There wasn't anything strange in this compartment. Just the typical seats and stuff and something that I assumed to be a FuG setup. Of course I forgot to attach the machine gun despite telling myself constantly to add it. I'll glue it in place later this evening before I start doing anything else on this.

Horrified excitement

I've delayed everything quite a bit, because I haven't been too confident in my success at fixing my airbrush a while ago. If that replacement tube for the paint jar doesn't hold, I can't use the damn thing and that'd be quite an suboptimal situation regarding my hobby. So, we'll proceed with a strange mix of fear and excitement.

"Cross your fingers for me" is what I'd ask if I believed in such nonsense :p

Project I/14

Unboxing

My January has been astonishinly busy so far. Hence I declare my Stuka project to be started based on the fact that I got the box open, its content checked and some "how to attack this" ponderings pondered. The old wisdom says that "well planned is half done". And another old wisdom says, after some minor tweaking, that "no plan survives an encounter with reality". What's the result going to be, then? We'll find out when I declare my bird built. As always.

The material

So that's the pile of pieces I'll be working with for a while. I guess that I'll first assemble the cockpit, at least partially and then paint it. Then finish that up, proceed to the hull and finally paint the whole thing up over a couple of iterations.

Priority override in work queue

I'm always mumbling about my FIFO-work queue (first in, first out). Now there's an exception to the rule!

The new item at zero-index

On my vacation that spanned over the Saturnalia, new year and "Reyes" I got a scale model as a gift. The box says it's by Academy and there's a propeller plane printed on it. Those who read the title may already have guessed that it's something incredibly beautiful, as I'm breaking my own rules for this kit. I'm pushing this thing past my OmniMechs and two tanks and laugh while doing it.

Ju-87 G-1 "Kanonenvogel"

I don't think I need to explain this any more than this. Stuka is in its ugliness may be the prettiest airplane that has ever graced the skies of this planet. That's why it goes first.

Before I start for real I think if I manage to fix my airbrush with the spare rubber pipe I got or not. Of course I could start the assemblage without it, but at least the cockpit would be demanding some paint pretty soon, anyway.

edit: I replaced the broken piece of rubber tube with a new one.The new piece is a bit larger than the old one, so let's see if warming the end up for a better fit help or not. In case it didn't, now I have another excuse for myself to get a new toy.

My coding project, part IX

Searching for life

Having only asteroids and ships wouldn't be that exciting content for a game. In this phase I decided that maybe a single planer per sector would be enough. Especially as my sectors were only 1024x1024px, you couldn't fit many planets there anyway. Maybe later the scale will be a bit more grand, we'll see.

In the first iteration of my game project the planet was rendered as a pygame.circle, but it looked a bit sad, because all the other gameobjects were antialiased polygons. So, rather expectedly, I decided that my planets would be (at this point at least) 16-edged polygons. Otherwise the planets are just like the asteroids, they just don't move or spin.

According to a fuzzy mental image a guy I know asked in the comments (in the finnish version of this thing) much, much earlier something about the planet types. So I pulled a few (for example: industrial, farming) out of my nonexistent hat. In the future they'll get more attributes as just type, mass and population don't really get us far. Oh, and to somehow simulate the effects of those cobalt-shelled bombs, I guess that (background) radiation should be one of them... Muah muah muah.

What next?

Physics

I guess I'll return to the QuadTree and collision checks next. After the collisions are handled, the deflections need to be worked on so that they'd work sanely. And of course I have to fix the ship's acceleration so that flying would feel a bit more real than the current jerky movement.

Weapons, destruction, death

When I've at least started with the collision checks (so I can test them), I guess I could proceed to work on some sort of a weapons system. Death rays may not be the first ones, anyway, but autocannons or missiles are much more likely. We'll see what tickles my fancy at that point.
Those also need to be tested on something, either asteroids or my dummy spaceships. I believe I'll start with the asteroids, because they'e mostly done already, or that's what I tell myself at night.

Odd ideas

How can a player dock to a space station? Or can the player do absolutely anthing with a planet?
I got an idea from the old, fun Zone 66. In it if you flew slowly enough over a landing pad, you'd land on it and if you went too fast you'd just fly over it. The exact same could work here: flying slowly enough by a space station would put the game in a docking / docked mode. Or flying slowly over a planet (no, you can't crash into a planet, they're on a different z-plane in this game) would put the game in an orbit mode where you could do things.

Up to this moment my only absolute requirement regarding that is known as orbital bombardment. Of course the player has to be able to sow his/her arch-nemesis' home planet full of mutated bubonic plague if they so desire. Naturally this requires the planets to have some sort of methods to defend themselves against all kinds of psychopaths with bioweapons and low moral standards. Methods such as the planet's surface bristling with missile silos, ion cannons standing by, swarms of fighters on their launch pads and orbits packed with armed weapons platforms. This is a good place to start with, right?

Everybody (I do at least) hates those telepathic factions in games. These well-known buggers know instantly if you have, for example, robbed their brother on the other side of the known universe without anyone seeing/hearing and get raving mad at you. If I managed to avoid this, I'd be ultrahappy.

A distant dream?

As a funny example: you attack a cargo freighter and sneakily kill its only escort with a lucky surprise attack. You murder the crew, steal the cargo and escape. No one has seen anything, no emergency broadcasts could be sent because everything happened so fast of your scrambler overpowered their weak radio transmitter's signal. Your pre-existing wonderful reputation is still unstained and why not? In the eyes of the whole galaxy you're still the saint they believe you are.
Or at least until you start selling the potentially recognizeable cargo...


This is what I've been pondering in my sick mind.

My coding project, part VIII

Move it!

Now that I had something random on the screen, I proceeded to my flying methods. After a bit of pondering I decided to stick to my speed vector approach and use a heading information for convenience. Because the displayable area was tied to the ship's position, moving the ship moved the viewport around the sector.

Rotating the ship around its axis was really simple and that's as much as I'm going to blabber about its rotate-methods. Acceleration was a big subproject the last time and it didn't let me go easily this time, either. While I'm writing this the whole accelerate method is still a work in progress, so I have to return to it later. Now I was content with being able to fly around the sector, even if it wasn't that elegantly done.

First it calculates the dx and dy values based on the heading and the acceleration. Then it checks where the nose is pointed and uses that to decide the sign of the values. If the new speed is going to exceed the ships's maximum speed, the full acceleration is not allowed. As I said, there's something fishy in my current implementation.

From one sector to another

At this point I came up with the next question: what happens when you pass the sector's boundaries? You fly to the next sector, of course. Because I hadn't set up the neighbour links to the sectors before, I had to return to the world's init. And because the sectors are initialized in a simple loop, I had to work a bit to get to the neighbour info to begin with.

In the end it took a few hours on a few evenings and caused some refactoring here and there (at least in classes Player, Sector, World and Game). My world init was slowing down considerably: when the sectors are first created, they're iterated again to first find out and set the neighbour links to directions north, south, east and west, based on their "coordinates" on the map.

When the sector's being changed the player needs to have the new sector set, the ship is to be thrown to the nearest end of the new sector (when you go north, you're moved to the southern end of the northern neighbour), it needs to be detached from the current sector and inserted into the new one. And then the sector's gameobjects are to be loaded into the world's quadtree.

I was pretty proud of my work right now, after all the swearing. In addition to everything mentioned above I also refactored the world init to be a bit prettier. Each of the sectors got a randomized amount of asteroids in them, while the vegetative enemy ships were just commented out for the time being. This was all done so that the debugging got a bit simpler.

My coding project, part VII

After a long break

My pygame project has advanced more than you could guess by the amount of posts about it. Mostly I've been fooling around with the background stuff, not much of what I've done will be directly visible to the user. Then again, if you look at the previous post, quite a bit has changed.

The last time we got to a part where the game world and its sectors were created and a map based on that was shown to the user. At this point there's absolutely nothing to play so I refuse to call it a "player". The map could be opened and closed and the game could be (un)paused. Basic stuff but nothing spectacular.

Next steps

In the first iteration of my project the game's view was fixed and the ship flew around freely. The first thing I had to do was to attach the viewport to the ship. So the ship would always be in the center and the viewport would scroll around the sector, following it. Because the sector would always be (much) bigger than the viewport, there was no sense in rendering objects that weren't inside the viewport's area. Therefore the sector would need a data structure for its gameobjects that would give all the necessary information to achieve this.

QuadTree

The idea of a QuadTree is that whenever a single cell's capacity is used up, it subdivides into four subcells where the objects will be redistributed. And so on and so on until the maximum depth of the tree is reached. No explanation I give can be better than the existing ones so you can read more from wikipedia, for example.
The necessary explanation is that I implemented my own version (or a part of it) of a QuadTree. At this point, when its mere existence is enough, all the sector's contents is inserted into the qtree. The aforementioned need of finding all the gameobjects inside the viewport was the first real use case. Because the sectors are squares, all my gameobjects are basically squares and all the quadtree cells are squares, everything can be solved with pygame's colliderect methods.

def get_contained_objects(self, rectangle):
  contained_objects = []
  if self.gameobjects:
    for gameobject in self.gameobjects:
      if rectangle.colliderect(gameobject.get_rect()):
        contained_objects.append(gameobject)
      if self.top_left:
        contained_objects.extend(self.top_left.get_contained_objects(rectangle))
        contained_objects.extend(self.top_right.get_contained_objects(rectangle))
        contained_objects.extend(self.bottom_right.get_contained_objects(rectangle))
        contained_objects.extend(self.bottom_left.get_contained_objects(rectangle))
  return contained_objects

What's most important in the code above is the rectangle parameter, which is the surface area of the viewport. That viewport is calculated around the centerpoint of player's ship. While working on that also the offset of the ship from the sector's 0,0 point is calculated. That offset is needed to render all the other gameobjects related to the ship.

Maybe (most likely, even) I explained it a bit funnily, but what can I do. Solving this small set of problems took a few evenings and sessions. I was pretty proud when I finally got it working properly. My biggest problem had been that I thought of it way too complicatedly - yet again.

Return of the GameObjects

Of course I needed something to be rendered on the screen, so that I could check the basic functionality of my QuadTree. In  the beginning I had those three subspace pirate ships I mentioned a related post or three ago. In addition to those I wanted to return the Asteroids back to the screen as well, but better than the last time. While I was on it, I'd test the insert and division methods of the tree with some randomly generated content.

My old asteroid code was almost directly transferrable. Mostly I added some more randomness to the init. Based on a 2d6 toss, a result between 9-12 spawns an ice asteroid, otherwise a rock asteroid. Anohter 2d6 decides the size with the old familiar small / medium / large / enormous options. The material affects both the color, the randomized mass and the rotation speed. Those asteroids that consist of rock are both heavier and slower than the icy ones.

Redoing the camo pattern

Yesterday evening I brushed a new camo pattern on the Turkina. I have to say that the result is still suboptimal but better than the previous attempt. Mostly that's because I had to beware of the preexisting detailing and such. Had I started all new, it'd been (hopefully) much better.

I think I'll apply a brown wash on this one, just like I did with the previous four OmniMechs. Unless I run out of paint. No matter what I'll report about that next year earliest, because I'll be on a vacation without pieces, paints and all those things.

Ongoing tiny fixage

December and all the other random things, also known as other projects, have eaten most of the resources from the 'Mech fixing. I've also had little inspiration for this for some reason, so other projects have actually had the chance to steal my time from this stuff. Mostly I've been educating myself about Alex Denton's adventures or had the PyCharm running, but more about that in a couple of weeks.

A guinea pig

The Assault 'Mech of the Jade Falcons - Turkina - that might end up being the Cluster Commander's ride, needed some repainting. The problem with this one and the others painted in the same batch was that the Dark Green I used (on top of black, no less!) was way too dark. Something needed to go over that and I chose Sick Green (Game Color 72029) from my storage and started brushing around.

Turkina before

Turkina now

I didn't even remember (or realize) how awful my paintjob had been. Almost the whole can was repainted without a rat's behind given about the pre-existing excuse of a camo pattern. As my next task I'll redo the pattern with semidark gray and fix the jade highlights.
Why didn't I repaint them as well while I was at it? Because I really liked the Galaxy insignia on both sides of the torso, destroying them would've been a huge shame.

Based on my experiences with this mini I'll put the rest of them in the grinder the same way. As long as I get this one done out of the way first.

Quick fixes III/13

Going through all the old minis

I was  bragging earlier that I'd go through all the OmniMechs I had assembled and painted years ago and redo their cockpits. Sometimes I'm a man of my word, so here's a quick report:

The beginnings of the fifth Trinary

Numerically my smallest and therefore easiest to fix was the set of four Points of my Aerospace Fighters. It really didn't take long as the cockpits are tiny and there were only four of the fighters to be fixed. In the more or less distant future I'm going to need to work on more of these, but when do I have the time for that? Not soon, I guess.

Two-legged monsters

While I was painting the cockpits I also separated the broken minis for fixing. I had also once accidentally bought an old sculpt of a Summoner that was sold as a D variant, and that was a horrible piece. That one I didn't bother touching at all as I'm going to reuse it as random ruined pieces on the bases of other, proper miniatures.

This jungle of 'Mechs isn't too clear so I'll show the pieces in a few separate rounds. First you'll find a Nova prime, Cougar prime, Cougar C, Ice Ferret and an Cauldron-Born Ebon Jaguar prime. The C-Cougar had lost its right arm at some point, so it marched on towards the Mech Bay and restoration.

Next up: heavier units. First a Mad Dog, Hellbringer, Summoner as primes and a Summoner B to round them up. Each was in prime condition and without anything to complain about. Unless you want to complain about the painting decisions I'd done all those years ago, that is.

In the Assault class I had an Executioner, Gargoyle, Dire Wolf, Turkina and Warhawk, each in their prime configuration and then my absolute favourite: the totally, absolutely sick C-variant of the Warhawk (2x LPLas, 2x ERPPC, flamer, TC). Funnily enough the first four were those I had intended to repaint because I had painted them with too dark a green. I just didn't have the time to repaint them at this point, so that had to wait for a while still.

The first Timber Wolf of my Cluster (I've got two, because I like them but no more than that because they're not supposedly typical for Falcons) is naturally a prime, like so many others:

Novas

My two Novas were armed with somewhat lighter equipment than the rest of the Cluster, with the idea "run quickly to the grinder and drop the Elementals". I admit that it can fight against the very idea of a Talon Cluster's description so I'm prepared to set them up later with Heavy/Assault class 'Mechs. The point was, that personally I found the fast Omnis much more likely to be found in a Nova.

So here they are, first three Stormcrows. The ones at the edges are primes and the one in the middle's a random custom.

The next set had three Kit Fox primes and two Fire Moth primes. I can't even rememeber if at the time I ordered these there were any customizing options avaiable. Or if customizing had been even sensibly doable.

The Nova and Ice Ferret that you saw in an earlier pic were assigned to these Novas in addition to these eight.

Some damaged ones

Critical Hits had been delt out more than just once. The reason to that was of course in my own assembly methods, because the custom joints were done before my Dremel period and generally however. The first sad example is my early Hellbringer A, that got its right arm AC made from a topz pipe. This one had taken two criticals in its both Lower Arm Actuators. With some pinning they'll stay put in the future.

The second Timber Wolf of my Cluster is an A variant and it had lost half of its left arm. Just like the Hellbringer above this one had taken a critical hit in its LAA.

Luckily only three Points had lost limbs. Oh, and that one pitiful excuse of a Summoner that had gone in two pieces from its hip. But we don't talk about that because it's going to be replaced completely.
The fault in these breakings is only mine and that's why I'm going to fix them to the best of my abilities. Well, I'd do that anyway, even if it wasn't my fault.