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.