A fool in the turret

cont.

It's pretty obvious that the turret has been my #1 priority for the last couple of weeks. That's because it's just about the last incomplete subset of the model. There won't be much stuff on the inner walls of the turret, only a couple of machine pistols for close defence, a spare aiming device (I guess that's what it is), a couple of containers and an empty wheel. For a while I was thinking if I should fill the wheel somehow, but as I didn't have a good idea what I could use, I left it empty.
All the pieces got a couple of layers of green paint applied manually at this point. The externals will be airbrushed whenever I get to it.

Turret assembly

When I had finished the two triple sets of grenades in their racks, or at least I get them to look acceptable at this point, I started assembling the turret at long last. To keep my exits covered, this obviously meant that I only built the front- and rear parts and left the sides open. This was mostly because the side panels weren't even complete at this point, so it didn't make any sense to attach them (just look at those insane holes in the photos).

I had somehow imagined that those huge gaps in the insides of the armor panels left by the injectors would've been placed so smartly that the equipment would've hidden them at least half-decently. Oh my, no! There was little stuff to be attached anywhere and all of it was located somewhere else, maybe to underline the ugliness of the mould. Because my benevolent guess was (again) so wrong and I didn't want to leave my machine looking like a teenager's cheeks, I dug out my Tamiya putty and set to work. After a couple of extra layers of paint the result started looking a bit better. Yay.

Test fitting

Of course I had to try and see if my vehicle was going to look like anything acceptable. Yes, it is going to do that. These photos show you that I (once again) changed my mind about the handles. After all I used the kit handles on the hatches of the engine compartment, the driver's and the radio operator's exits. Those customized handles I tried to use didn't really work as I wanted them to. Shockingly the plastic monsters of this kit looked better.

Turreting

Slowly as usual

This week's achievements have been astonishingly few, thanks to the real world pushing my time usage on an interrupt vector a bunch of times. It happens sometimes and there's nothing to it. Anyway, I got the end part of the gun built and attached on the turret ring. Nothing more, nothing less.
One weird thing was tha the instructions pointed at a part 18E twice (in the E sprue the part #18 is the lower rear part of the turret) and in this pic that part should've been a pistol-handle like piece, attached slightly above the wheel. Didn't find anything like it anywhere on any of the sprues. I'm not entirely sure how to fix this thing. Bugger.

A new change to the build order

While I was looking at the instructions I decided that I have to change my approach regarding the next steps in this build. I'll assemble the turret with its toys while manually painting things as they come along. Whenever the turret's completed I'll apply the green paintjob on the whole outer surface of the vehicle. I was going to do it a bit differently in my origianl plan but as it'd be so damn difficult to detail the insides of the turret after its assembly, I must adapt.

The final form can almost be seen!

I got busy

The "let's get stuff done"-bug bit me pretty nicely, so I've been working just about every day on this monster. When I got the hull halves in a good shape, just a few options remained. First: build those custom handles I mentioned a couple of weeks ago, second: assemble the hull. As usual, I didn't remember to dig out my wires, so the handles are still missing in action. I'll get them done one of these days, I promise.

The road wheel cradles

When the hull was in an "almost complete" state, where it was only missing the tools, I turned my eager fingers towards the wheel setup. First things first, I assembled the drive sprockets and glued them in their places, my plan was to leave the idler wheels off until I was ready to attach the tracks. So the next task was to build the weird cradles that house the road wheels.

I think I'll leave them off and paint them separately, so I can attach them on the already painted hull. While I'm at it I could messify these pieces and the lower hull a bit more nicely than if they were all attached. If the whole setup is built they overshadow each other bothersomely while weathering.

Close the tub and get going

Why keep wondering and pondering when everything's just about done - as far as they're supposed to be at this point? After a bit of dry-fitting I slammed the deck on the bottom and let it cure overnight. I know these last pics are foul, I took them in a bit of a rush, I apologise. Though they are work-in-progress photos, so I do reserve the right to share some suboptimal pics at this point. The final pics are going to get a bit more attention from me, rest assured :)

Like so. Of course I have to apply another coat of primer all around, but that's something I knew when I started the whole project. In any case I think I'll attack the turret next and take care of the painting in the end, when everything else's done. Someone may have noticed that all the tools - shovels, sledgehammers and whatnot - are missing, yes, I will attach them when the hull is painted, not a moment earlier. Otherwise the british green might not get applied nicely enough.

Working on the rear and top hull

Business as usual

These last few sessions I've been working on mostly the same things as before. My order of assemblage is pretty random and depends mostly on what I intend to paint next. The latest additions have been concentrated on the rear and top hull parts, yesterday I slapped a couple of hatches on the top hull.
Both the driver's and the radio operator's hatches are still missing their handles because I felt that the cast pieces were way too large in comparison to everything else. I'll try to hunt down my thinnest metal wire, in case I could use that to make some sweet, custom handles. And of course, if I find something else that needs handles I'll customize them as well to maintain a unified style.
Otherwise I believe this'll be a straightforward OOB build because if I start fooling around it'll take even longer. And I would really, really love to complete at least a couple of projects this year ;)

Did I ruin something?

My plan is to leave all the hatches closed so I won't get too stressed with the interior of this vehicle. For some reason the rear hull causes some confusion, anyway. So far all the pieces had gone where they ought to go and without any fighting. But when I started installing the fuel tanks nothing worked. The bottoms didn't go as deep as they were supposed nor did they align properly - the rear wings were grimacing by millimeters! What to do? I mengelefied the pieces until they fit and I got my weird box assembled, because the interior parts aren't as important as the tightness of the exterior hull itself.

Now I'm just pondering in my mind if I should paint this weird box at all or should I apply a quick layer. If I just left them like this, mostly primed but with some bare plastic visible, it'd haunt me. Oh, and you could maybe even see these things from the bottom if you had a really (un)lucky angle!
I guess I have my answer.

Ammo racks

Hey, there were extra parts...

This week's achievements are small but enormous. I made a mess on the floors, so they wouldn't look freshly painted, which suits a filthy warmachine a bit better. At some point I messed  up a bit with the ammo tubes but despite that fact I had decided that I wouldn't try to dump all 32 tubes into the racks as the instructions suggest. Why so? Because I feel it makes the whole model look a bit less staged when everything's not full and perfectly set up.

Trickiness

From some depths of my memory banks  I recalled reading that pieces of tape make good seatbelts for pilots, for example. I applied the idea to my project a bit. Meaning: I cut pieces of masking tape and then split them lenghtwise to make them fit the scale a bit better (judging by the look, not empiric facts). Then I slapped them over the ammo things somehow and gave them a quick Devlan Mud wash to make them less eye-searingly bright. Now they're supposed to be cargo straps truckers use to tie down their loads and whatnot. Of course I didn't even think of scratchbuilding any kinds of lock pieces or anything.

It doesn't look half bad to me, at least.

Back to the paints

Important things first

The real world has again slowed my differend projects (3+) and their advancement. But what can you do, hobbies aren't always on top of the priority queues. Anyway, I grabbed myself gently by the neck and airbrushed the inside pieces I assembled last year. After that I googled a bit to check if there were any colour photos of the Achilles and its insides for reference. This way I might be able to finish with something that at least resembles something real...

The result of careful research

It looks like the radio and that other box should be greenish. Let's see if I could get to paint them a bit later today, even. Of  course that depends solely on the demands of the universe that (rather surprisingly) doesn't revolve around me.

My coding project, part V

Tiny changes

My advancements in this project over the last few weeks have been few, thanks to my almost three-week long vacation and all the other bothersome things. I tried to tinker with the collisions so that if a bigger thing is hit, the bigger one is affected a lot less than the small one. This way the gigantic rock doesn't shoot out after being hit a tiny but fast 'roid. Yeah, a tiny change but it feels better this way. Oh, and if you're lucky, the ultrarock cracks into two large pieces.

Just for the fun of it I checked how this all looks if there's a light blue grid on the background, as if everything was just scribbled on a piece of paper. Maybe it doesn't work as nicely as I thought. Let's give it a try anyway.

Looking for a scribbly effect

It's raining rocks!

While I was fooling around I wrote a tiny Planet class. On the screen all you get is a screen and on the background it has crap like a name, mass, population and some other unimportant things. When the rocks start hitting the ground the population plummets until no one's left. It was surprisingly fun to test it :p

Candyland II

Any things that go boom and death rays are still in the "ideas" state. I did start checking on how to check if two lines cross (and where) but didn't get far with that. Yet.

Other projects

Maybe I'll get to work on the tank model too, when we get to next week, but that depends on everything else. Days have been pretty busy lately. In any case, it interests me quite a lot after all these weeks.

My coding project, part IV

Adding some functionality

I was happy that I had this and that on the screen, doing this and that, but nothing affected anything. This, obviously, wasn't acceptable, so the next attributes added to the GameObject were hitpoints, for example. Of course I added much more junk to it but none of it makes any sense or difference at this point, so we'll just ignore them for now. As I had decided to work on something Asteroids-like (no, I wasn't going to stay there but to add much more weird but interesting junk) project, (not) colliding with things is pretty important, I guess. While writing up this set of posts I've also worked on more than makes sense to explain now.

Collision ponderings

• The rocks can hit the player's ship and vice versa
• The rocks can hit each other
• The speed difference should matter
• Mass differences should matter
• The collision angle is also important

Two-phased collision detection

Because at a given moment there can be quite a good amount of Objects on the lists, there's absolutely no point in checking each and every one by the pixel. It's maybe better to first check if any two objects are about to collide and only then go for a more accurate check, if needed. In the first phase - at the moment - I just iterate through the list of all the 'roids and the player's Ship and compare each other's basic areas for overlapping. To this task pygame's rectangle.colliderect() function is just fine:

def collides_with(self, other):
        collides = False
        if self and other:
            if self.get_rect().colliderect(other.get_rect()):
                collides = self.accurate_collision(other)
        return collides  
def accurate_collision(self, other):
        return True

Naturally the second method is only a stub that I'll implement properly whenever I get to it. Right now it just says "yeah, yeah, they do collide, stop bothering me already" and then both colliding GameObjects get a 2d6 amount of damage until one or both of them are destroyed. Because there are four sizes of Asteroids, the bigger ones break into n smaller Asteroids, if the masters of d6 so decide.
While testing I got rather quickly tired of my ship being destroyed while flying around, so I added a Megatron-like cheat. The game says Afterdeath and the Ship's hitpoints are replenished as if nothing had ever happened.

One chilly morning I was chatting about this project with a yet another coworker of mine (he had noticed some mumblings of mine in g+). Among many others a comment about the lack of antialiasing was brought up, he asked if I had considered using it or if I was going for a more retro look. My answer was that yes, I was going to do that whenever I got some more important and more bothersome stuff done out of the way. While we were chatting we took a look at Pygame's docs and we noticed that if I just switch all my draw.polygon-calls to draw.aalines and add a single True variable, nothing else is needed. So I tried that out the same evening and it does look much nicer, doesn't it?

Antialiased

After the collision

Because it would be rather ridiculous to have the space rocks flying inside and through each other after the initial collision, giving more and more damage, I thought it'd be handy to work on the deflect-method that would count the new speed vectors and angles to the colliding parties. If I could come up with something even remotely like billiards table physics, I'd be a happy *camper*. When that gets combined with critical hits (a small but fast Asteroid could crack an enormous one in two, for example), the result could be pretty fun. Oh, and the planets and who knows what else... I've got absolutely nothing ready so far!

"War. War never changes."

For everyone who's listened or read to my endless mumblings it's clear as day that among many other weird things Star Wars and Battletech are (and have been) big things for me. Especially BT is something I'm going to get some weapons-related influence. The main idea is that the player could choose one or few items of violence in their ships, depending on the ship's slots. Missiles/rockets, death rays (with or without pulses), automatic cannons and particle cannons that spit out cerulean bolts of lightning. Muahahahaha!
And if you can swap the weapon modules, why not the reactor as well? 

I'm just throwing ideas around, I'll find out later what on earth I want to do with this.

My coding project, part III

Wherever my nose points at

Now that I had finally fixed the rotation and found out where the hell it's pointing at, the last of the unimplemented basic functions was the movement. My first attempt was, especially in hindsight, ridiculous: if the angle was pointing to one of the cardinal directions, the full acceleration was applied on one axis - if somewhere in between, the acceleration was applied to the two closest ones. While testing it first looked nice, but in a while I noticed that "Heeeeyyy.. this thing jerks around when it's turning and accelerating. It looks pretty odd now". Even the slightest difference from a 3π/2 angle made the polygon accelerate at full speed towards the closest intermediate direction. Whoops.

A bit more realistic change of speed

After a very short but intense moment of screen-staring a lamp went off in my head: if I went and used the same damn trigonometrical functions that told me where thing was facing but using the known speed and angle to get the Δx and Δy values, I'd be done! So, the same trick but opposite direction. Luckily it didn't take me more than a couple of minutes to come up with this.

tempspeed = Vector(self.speed.x, self.speed.y)
dy = math.fabs((math.sin(self._angle))*self._acceleration)
dx = math.fabs((math.cos(self._angle))*self._acceleration)
# ...


Of course this isn't all, the method still needs to check the heading and decide if the Δx and Δy are positive or negative. With that piece of information the acceleration can be applied properly and to the right direction. The main thing is that it looks good to me right now.

Particle effects!

It gets pretty old pretty soon, moving a simple Shape. So I worked on a Star Control (or Auts or V-Wing or Wings) style acceleration effect. Without spending more than a few seconds on thinking where the engines would be located, I just marked* the bottom edges of the triangle shape as the engine points. Now whenever the acceleration is triggered, a set of tiny box Shapes are dropped at the current coordinates. These Shapes fade away slowly and die away after a few cycles. While I was playing with that I made a silly warping method, where the polygon is relocated in the middle of the game area. At the previous coordinates a set of eight particles are created with speeds set so that it looks like an explosion. It's a funny effect even if I say so myself. That was going to be used to do explosions in the game for real, not teleporting 8)

*) I was farsighted this time. The initial version just takes a set of coordinates for the engine exhaust points, as many as I want, so I can do however I want later. More or less. Perhaps this helps me avoid a couple of rounds of "refactoring because stupid".

Adding some friends on the screen

All in all, what do you do with an almost triangle shaped thingamagick on a 2d space if it's there alone? You'd get bored out of your skull pretty quickly, I tell you. So my possibly retarded idea should be clear to everyone: I'm going to dump in some asteroids! 

I was pretty excited when I got my eight-pointed semirandom shapes on the screen in four different sizes, spinning slowly around either clock- or counterclockwise and after a couple of iterations they even flew through the screen on their merry ways. That was an awesome moment.

Swoosh!

At least I was damn proud of that.

My coding project, part II

I think I said the last time that I've never tried to do anything graphic for real, unless you count those TurboC++ tests that just vomit squares and circles on the screen (no, they do not count). So my first problem  jumped out already. It was simple to get my four-pointed polygon in the middle of my surface, but moving it...

I'm going to mumble about my "aha!" moments and ponderings as I remember them and when they have some kind of point to them. I don't guarantee a good quality, just like I never do ;)

Position, rotate, relocate, draw

So my first version used a set of hardcoded coordinates, yay! I thought that it's a good starting point, but oh, how wrong I was. Maybe the issue was within my own rotation methods and it'd all been awesome if my methods had been fine, but maybe it would've sucked anyway. The initial situation was rendered prettily but a single rotation distorted the form beyond recognition.

Via the zero point

From somewhere I came up with an idea (and after talking to a yet another coworker of mine my guess was proven correct) where all the shapes should always be initialized around the (0,0) point. This way the rotation of any polygon would work the same no matter where on the 2d space they are.
So first you always set up the vertices in the same places, then shift the coordinate points to the actual positions where they'll be rendered on the screen. A really simple and I guess it's a childishly basic thing, but who would've told me?

Rotating the 2d coordinates

My mathematical studies are years old at best and I have to admit that in elementary school (even longer ago) I was one of those fucking annoying brats who declared that I would never need maths or trigonometry after the 9th grade. Oh yeah, once again we see that reality doesn't always agree :)
After a couple of weird and stupid "I'll do this myself"-kind of attempt I encountered something called affine transformation. That was a nice, handy thing and the implementation was just about 1:1 with what my dear friend Wikipedia told me. You just drop it each vertex of the polygon at a time and the desired rotation angle (obviously this is always the same for a single shape), this beast simply returns the new coordinates for the given vertex.

def rotate(self, angle):
        rotated_points = []
        for point in self._points:
            new_point = self.affine_transform(Vector(point.x, point.y), angle)
            rotated_points.append(new_point)       
        return rotated_points

def affine_transform(self, point, angle):
        temp_x = ((point.x * math.cos(angle)) + (point.y * math.sin(angle)))
        temp_y = ((-point.x * math.sin(angle)) + (point.y * math.cos(angle)))
        return Vector(temp_x, temp_y )


Hah! The next issues I encountered were the angle (I was, again, making a mess with degrees and radians, but that was because of my infinite stupidity) and the movement. The movement was a bigger issue and took quite a bit longer to fix. Pretty soon I was able to rotate my more-or-less-triangular shape around it's own z-axis but if I tried to accelerate, it started flying towards the top-right corner and beyond. If I tried to rotate and accelerate, it did the same but while corkscrewing carelessly. I was baffled.

How do I calculate where my polygon is facing? 

As my stupid mistake number 74 I forgot my hardcoded "draw this thing in the middle of the surface" -values and another mistake was that the calculate_angle always returned the exact same value for my Object. Somehow I had ended up trying to calculate the facing of my polygon by its sides (because it's basically a triangle). I guess it was otherwise a good idea but it just didn't work here at all.

After a bit of googling and more light headscratching the solution was much more simple than I had thought. Or at least it felt like it for someone as stupid as I am. Because the center point's coordinates are known, as well as the tip's coordinates, you can just take the distance between the coordinate points on  x and y axises (Δx and Δy) and feed that to arctan to get the angle in radians.

I guess that clarifies a bit... or not :p

def calculate_angle(self, center, nose):
        dx = center.x - nose.x
        dy = center.y - nose.y       
        radian_angle = math.atan2(dy, dx)
        return radian_angle

Geniously simple, I say. At this point it looks like that no one can read one word more of this crap on one go. Therefore I'll continue this topic on the next iteration of the Project Mumblings.