The arms race goes on and the cockpit gets some decoration

Popping by the toy store

Finally I got around to invest in a new airbrush. Call me mad, if you well, but I got a Badger's Renegade R1V-Velocity. A two-action top-cup thingamagick. It felt pretty nice and sturdy - and it even seemed to accept my existing air hose. Of course I didn't have the time to actually try it out, but what's the hurry anyway?

Fasten the seat belts

Once again I cut a few strips of masking tape to give the pilot and the gunner their seatbelts. All those that go over their laps do seem a bit too wide compared to the last ones I made, those being the shoulder belts for the pilot.  Yeah... Maybe I have to cut those fatties in halves or something to avoid this looking way too ridiculous.

The instrument panel

My approach to the dials was simple: I painted the dial faces black. Originally I had planned to paint some thin white lines to represent various dial needles, but this piece might be a tad small for that... I will be pondering on this before I seal the cockpit, but I doubt that I'll risk ruining it.

Cockpit paintage

From empty promises to actual action

When a model is waiting for some paint on its surface, it needs to get it. Therefore I applied the primer on all the cockpit surfaces so that I shouldn't encounter any "ha ha, funny!" surprises later on. Supposedly.

Primed grey

According to the instructions the cockpit should be painted grey-black. I still had some of that left in my Model Air bottle (note to self: acquire more asap). After it had dried properly, I drybrushed the mg and just about everything else with Vallejo's gunmetal - more or less carefully.

These last two photos from last evening are horrendous as they were taken in a rush and with bad light. My deepest and humblest apologies yet again.

Grey-black

After some serious gunmetalizing

Further development

I was thinking that all those radios, dials, indicators and whatnots could be highlighted a bit. The stick can also be whitish, according to my image search.
Following my weird ways of working, I'm once again going to omit the decals and do everything myself. That means that the dashboard will be done next. The dial faces with black and then some white lines on them, pointing at semirandom directions. It may sound a bit hazardous, but that's how I like to do things.

Also, before I'm going to seal the cockpit inside the hull halves, I'm definitely going to attempt some sort of seat belts for the crew. I'm not going for a "himmel!" effect this time, either, but a "hey, there's seat belts as well!" kind of a reaction instead. All in all: tiny improvements with a small effort, improvements that would annoy me to no end if they were missing. Once again following the finest traditions of the Project Mumblings.

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.