Queried mutex

I made an awesome little concept for thread synchronization along with a generalization of the thread communication model I described before. In general, it's a set of threads executing functions in a list and, depending on a per-task setting, will remove or keep them forever or until a specific return value. Since I prefer using no malloc except for heavily program-specific parts that actually require dynamic memory, it only needs a small amount of stack memory. However, the real thing of interest is that it used a "queried mutex" which's locking mechanic overcomes the typical racing conditions by creating a chain of n mutexes (is that even the correct word for more than one mutex?).


Arx Fatalis

After a good couple of hours coding something that's really useful to you, there's not unlikely a moment where you want to play an excellent game for a change. Since Skyrim still needs some day to be officially released, I bought something I always wanted to play before - Arx Fatalis. I heard about this game when Dark Messiah was released but didn't take try actually buy it cause getting older games to run is always a bit more difficult without having all available patches applied. A few months ago or so (while I wasn't able to use Steam) I saw a Let's Play of it and was so surprised how amazing this is, beeing played by someone who really knows about this game. When saw the Let's Play again this morning (only partially), I decided to play it by myself. And - well - I'm playing it since... I don't exactly know, maybe 10 hours or so? It totally sucked my dry and I still can't stop playing it. This rarely happens to be and I'm glad I bought it. It's only 5€, so you get a complete gem for NOTHING. I was about 12 years or so when it came out. At this age I played Diablo II and console games - my PC wasn't able to handle such a game like Arx Fatalis. I mean I got my first 3D card two years later or so... and that one wasn't even update enough to play Arx Fatalis. Whatever, this game would've been to bloody and creepy for my I guess. Not that it is creepy enough to stop me from playing it (like Metro 2033 at a certain point), but you have respect for the enemies and their strengths as well as the fact that there are damn sounds everywhere you go. What you do, is permanent. So every wasted healing potion or broken weapon has a weight you won't forget easily. Additionally, I simply collected all easy-to-get plants, made those potions out of them and now I'm facing certain realizations about how bad wasteful behaviour is in this game. Sure, there's possibly always a way around. But it's not a nice one, I can assure you... Oh man, this game brings some tension to your veines. It's the same thing like with Dark Messiah, only that this game is much more fair and leaves me the freedom to do something else aside from getting my butt kicked. I'll probably try to find some more secrets and go to bed then... Dungeon level 4 is just not yet the right level for me this night!


Finally some about multithreading

Yeah, I reached a point of thinkage where I found a more or less complex solution for my multithreading system I want to use for my game. It strongly benefits from multithreading since I'm towards a totally streamed system loading and releasing stuff on demand as you go. This requires a seperate loading thread a "lazy" ressource loading to not randomly stutter during the streaming process (like when seeing an enemy that a set of potential sounds but it's not guaranteed that they will be played). At first I wanted to create a scheduler or so, but then I designed a task/job-based thread system on the same event stack base of the physics and graphics thread communication. I noticed how similar they are and that they can merged into one regular system. However, this system will also required an guaranteed-access-time-order query like a more flexible realtime operating system with defined thread switching order. This will be the occupation for my next hours of programming, so properly busy during gaming session. Oh and not to mention that Skyrim will be out soon! I'll have a great time of playing and creating this time.


It's 2:00 am and I've had a good time working with SDL again. It's so nice to build some simple little display systems. I decided to try reducing functions calls in my render thread (or rather ANY of the critical processing threads) to minimize exporting registers to stack, having a hopefully maximal performance at all. The problem with is that I somehow have to bring the initially unknown numbers of sprites to screen. I decided to use a linked list to fill this later for later occuring hardware-based rendering, but that also means that I'll have to call atleast malloc for each added symbol. That's of course not much and I won't have any possibility to avoid except when using a preallocated stack of list items, only expanding if necessary. While this is a really good idea for later, I'm also wondering about the performance of those threads that have to access and wait on event list mutex' to be unlocked, effectively calling an SDL function, you know. That means that I'll once again have to use another stack for dumping events temporarily and posting them later. I'm a bit afraid that this is too heavy-headed for the thread of concern, the physics thread. This thread does actually not require much stuff at once as I believe, so it is probably no problem to use functions calls in there. This doesn't have to do with ill-seeded optimization fanatism but rather the knowledge that certain processes require so many local variables storable in register than functions calls may be critical. Good thing to know that the "higher" areas of execution do not require too high performance at all. Graphics programming still persists as the most realtime-demanding system I know of. And it's only good to be able to pump some more light effects.


Just fuck it

Yeah, just fuck it. I'll simply convert to float every time I need to and that's it. Will perhaps try some other variant later, but I don't want to sacrifice all the comfort of floating point operations (not so mention the mess I'd need to do for physics calculation). Sure, this is expensive, but used seldomly and at only the necessary positions, it bears more flexibility for everything else. There are more alghorithmic performance holes fixable compared to the base speed required for iteration.

The little mistake

Ahh, yes. I see where fixpoint formats may be unsuitable for my case. See, it's awesomely fast when using usigned numbers and does actually work very well with it. But the problem is that, if there's no negative range, I can't check whether a translation went out of range and won't be able to clip it properly. I could use Wikipedia implementation suggestion of the Q number format, but that's rather a bad idea because it suffers from distinct precision loss and unwanted rounding behaviour. What I'd want to have is a fixpoint format having a signed pre-comma part and an unsigned post-comma part. But due to the fact that it's not unsigned and that a decision is required to somehow involve the sign, it won't work as expected.

So this is it, fixpoint calculation with no sign value I guess. Also, over and underflow is rather impossible to check using it (didn't dig too much into it). The benefit is awesome, but I need to compensate the sign problem with them. Guess I'll have to seperate pre and post parts every time I do a calculation. And I guess that those few operations are still faster than a float addition plus conversion.

Binary fixpoint

I've made some analysis of how many float-to-int conversion appear in my code and it's creepy that every tile a ray passed takes a float-to-int conversion. That's a real fucking lot and made me think about how to reduce this effectively. Most of the time, I only add a step vector and need to float's integer part. Therefore, I could also store the integer part seperately and add another "detail" value representing the post-comma part. But two variables with always occuring overflow around the lower values will result in a lot of conditions to check and equally much calculation to be done. Maybe even slower, it is not the optimal solution - even you get the integer part for free. So I thought about using fixpoint numbers where I can get the int by a single bitshift and use number iteration as I'd normally. Sure, it takes more than one operation to do the initial division each ray requires when shot, but the iteration itself and the completely eliminated float-to-int conversion pays off. I'm not afraid of using floats for EVERYTHING, but they are not made to be converted into integers so quickly and often as I want. So I'm tackling again a different path that's hopefully the way to go for positioning. If it doesn't work as expected, it'll be abandoned as soon as you can say "Cowabunga!".
I'm bouncing between Lego, study stress and recoding, so I right sitting infront of my old code - trying to decipher and simplify it. One thing I always wondered was how to mix those block-covering colors on map tiles with their texture if I want to use hardware-accelerated alpha blending for display. I've used a simple method to determine whether there are volumes of the same transparency and color to keep the alghorithm from gradually reducing the light coming through transparent glass walls for example. This works fine for the light, but it seems that I didn't include in any other of the ray tracings as well as the character rendering. Means that most of my old was so damn spaghetti that I wasn't able to include it everywhere properly. I mean I only used it for player position-related filtering but not on actual light calculation. However, I'm repeatedly using what walls of the tile are visible, coming via exactly the mentioned calculation. That's interesting because I didn't wrote it down in the comments so that it is clear to see. The code is full of weird triggers and alike - I wonder how clean it becomes after I decyphered everything. I mean I DO know what to include and what not, so it should become cleary clean, shouldn't it? Well, yeah... it somehow seems that I knew where everything was and in what order. But I also know that it was hard for me to do any changes. I think I should just start and code like a madman. A few macros cause the raytracing behaviour is in abstract the same, in instance different, and then just stick them together. Or something like that. Geez, am I nervous about it.


But still, there are those guns

Yep, I couldn't convince myself to just program but do something relaxing, like building Lego gun prototypes. I tried to model the two-part cartridge idea but somehow realize that I, so far, always used half-stud beams for forcing the accelerating bullet in place. This works good if all beams are fixed and present, but how if have to create a bullet with just a half stud of rubber band fixation you can only reliably createwith two studs? See, that's a real problem for me. I have ideas for a 3x4 cartridge targeting this problem with an additional rail on top used to fixate and lock the part when beeing (un)charged. It would screw up everything and eventually lead to a once-again required re-engineering of all the stuff I was so far able to come up with. Nope, that's not a good idea. I should rather work a better muzzle loader with all those nifty ideas I had, like it was planned.

Reviving ancient instructions

Sooooo, after a little refresing weekend with some good friends of mine and a gret new Lego tank prototype to play around with, I'm full of energy and concentration to bring my old ASCII raytracer to life and make a game engine out of it. I must say I had some clever ideas and observations to make it look like a simplified model of our reallife light model due to some assumptions of "perfect physical properties and 100% purity of used material. It's a bit custom but once one got the idea behind it and the angle in which it is to view, it works flawless and can theoretically create a lot of awesome shadows and light scenes. With my new set of macros, it'll be a piece o' cake to recode it. This time I've got plenty additional ideas to overcome it's slow framerate (or rather let it stick to the framerate and not the rest, too). So, beware, old piece of shit! I'll burn your rope as soon as I get to you.


Buildin' a tank

Yay, I build a tank! Atleast sort of. It has two continuous tracks and battery in the middle. For prototype's sake I've chosen a control that maps a different when attached to the Power Functions remote control modules, but it works compact and flexible nontheless. It's amazing how awesome this technology is! I mean you driver forward, backward, rotate directly on spot and on each track's middle if desired. It's more flexible to control than a normal wheel-powered vehicle but less easy to make. The power can only reliably applied on those wheel with much of it's radius exposed to the continuous track's surface. Everything else will fail in most circumstances. However, within these limitations, it's capable of more complex maneuvers than a wheeled vehicle. Also, it bears a better surface usage it seems. Not as awesome as a completely omniwheeled robot but still extremely awesome. I had my doubts about it's efficiency on flat and slick surfaces, but it seems to function well enough with some short beams attached to the tracks. Yeah, it seems just the perfect stuff for a remote-controlled vehicle! I'm currently thinking about how to extend, what to also add and so on. I want additional lamps getting activated depending on which track is used and so on. Together with some remote-controlled features, I could create a real little tank with gun and such! I like this idea, but the gun would be rather useless cause you wouldn't be able to aim with it. So I'm thinking about some else... Maybe multiple tracks with different directions in case it falls down somewhere? Hm, it'll probably just smash in most cases... However, I guess I'll work more on the general compactness of this design and make it a bit larger to a) be able to climb small stairs and obstacles, b) have some kind of shock absorbers to get higher ground flexibility and c) add something to interact with. Not a sensor stuff from NXT but something that's remote-controlled, too. Like a retractable claw at it's front so I can pull stuff and move from one point to another... It's more fun to realize ideas with this than NXT as you can create ANYTHING without beeing limited by only a few motors. Get as much as you want with as many motors and batteries as you want! The only limitations is the remote control's channel of 4 channels with 2 controllable currentd each (thus, 8 controllable currents in total. Yeah, I think I can work forward to this. A compact, tank-alike base contruct with a retractable claw to pick up or atleast pull objects... Sounds totally doable I think. Whatever. I can only work on this with enough time and I have to some other things as well. Anyway, I should try to hard making stuff to complex and such. In the end I have to buy quite some Lego equipment for it in case that there will be extensions beyond driving and blinking. Hm. Gonna write this on my wishlist for Christmas!


New stuff

I bought some new Lego sets and am now the proud owner of some more pneumatic parts, gap fillers in general and an interesting set of some of Lego's specialized car parts. It's weird how much Lego Technic flows into cars. I always liked tank-alike movement more, but that's just a personal preference. However, I've got some new parts right now and think about redoing the stock/grip so that it consists completely of covering parts (though not those big car cover parts) with an interesting variant I got today. Gonna test this some day, but sounds promising for making a better stock of it. The base can be made black, everything else can be grey or so. May make a retractable stock in grey below the pistol grip, so that I don't need to use that much parts for it. Hm, this could actually work... and look way better than those hole-ridden angled beam constructs I'm currently using. Don't know how to combine it nicely with the gun's lasting "stability spots", but somehow it should work I guess... I'm thinking about how to form the gun model for the new cartridge idea I got... Making the cartridge should'nt be a problem, loading and unloading it may be one. When shot, there are two parts I have to eject and the cycle would be rather complex, if not annoying to operate. Those two parts would require some kind of "thrower" to get out since both should, at best, be ejected at once. After the bullet lock got opened there is no but loose contact between both parts, making it difficult to make a typical extractor claw that pulls them with leaving one behind or flipping around randomly. That could be solved be integrating some special mechanical "flow control" elements at ejectiong port or cartridge for eleminating many vectors in which they could get propelled by the extractor motion. However, there'll also be rather custom chambering when using a magazine... I mean in normal state they loosly hold together in any angle you rotate them. I could further test out, in theory, what already existing cycling mechanics would be realizable. As plain and simple as possible. One idea I got right now is similar to the FIFO gun I designed a while ago: having track with cartridge seperators, you can insert one from below and all other already loaded bullet wander up. the last bullet with exposed to the top of the track and can be removed by hand or by tilting the gun body. This could work for vertical horizontal arrangement, though vertical is probably preferred because it makes it easier to chamber it with a bolt... Using a ratchet I could also make it cycling automatically by pulling the bolt...

Many things to think about. I should program during and between lectures and do some Lego stuff at home. I'm also considering to experiment with my NXT a bit more since I'll most probably use my own Lego robot for one of my seminars. Good thing is that I can use anything I want as long as it is not too over-the-top (like multiplexing power functions using NXT motors).


Quick idea

I got a quick idea for an alternative Lego cartridge/gun model (yes I know, I have too much freetime and I'm obsessed, blabla, braindead argumentation etc). Instead of always pre-charging the rubber bands, I could simply leave them uncharged and get charged when getting chambered. Imagine this: The bullet is locked inside a construct similar to what's already in the current cartridge and it's rubber band is hooked loosely but stable enough to not fall out (maybe with a rubber band-powered locking mechanic, too). The other end would be stretchable/expandable, yet fixed in normal state. The when the gun get's operated, one of both ends would get be moved away and locked. So when the striker or firing pin hits the cartridges, it'll either release the bullet at the fixed cartridge end to accelerate towards the muzzle (where the stretched rubber band's goal is) or it'll somehow release the other cartridged end accelerating towards th cartridge''s nose. Either way, the rubber band charging will only occur when the action cycles and the cartridges only need to be as long as the can become with an uncharged, yet fixed rubber band. Moreover, the power and range wouldn't be determined only by the cartridged anymore, but also by how far the gun can stretch the cartridge's rubber band. I have to make some notes and thoughts about that... Sounds very promising! I hope I won't get too distracted with this to still be able to keep my brain programming. Whatever, this a great discovery. And even if it won't work, I'm still aroused by the ingenuity of this idea. And yeah, I'm totalling convinced about my experience with this very special niche topic right now. This would combine very well with some sort of pump-action because you'd either need to charge by pulling back or forth. In case of adopting a normal gun's breechloading setup, I'd charge the rubber band with a forward action this way. A back-charging action would require the magazine to be directly under the muzzle (not really what I want).

So I finally found a way to make them smaller in theory. I feel good right now. I believed there was no real future and no further improvements to be made. Like when physics discovered that they need the mathematicians to define real numbers instead of only natural ones. Hm, such a gun concept could work well with a magazine because there is no need for chambering at all if it's designed carefully with an ejector and so on. Though... when beeing fire, there'll be parts left in the gun: the lock and the rubber band. So you have to bring them back together using the back-pulling action. It's again nothing you can use like in a normal lever-action of pump-action shotgun because all cartridge switching needs to be done after pulling completely back or completely forth due to this "fragmentation" of the cartridged itself. Hm, yes. This is kind of non-nice to say. I can reme,ber of a multi-stage pushing mechanics I once designed... Could be utilize to a) bring both cartridge parts together, b) eject them in the second back-pulling stage, c) chamber a new cartridge in the first pushing state and then d) charging the rubber band in the second pushing state. Rather complicated to create I guess, but it's probably worth it I think.

I will probably have to work on my game during my lectures and travel times and work on this concept at home... And somehow get the study inbetween. I really am obsessed with this stuff. I feel a bit like the dude the Pi movie. Well, I didn't see the movie but what I could read on Wikipedia, I'm sometimes totally at the same degree of obsession with certain things. I don't whether this is could to not have this one programming anymore but on Lego stuff, but I guess I won't have the motivation to due this as obsessive as I did with coding in the past. It'll simply pass by and leave me some day. I see how all my life is driven by creation and problem solution, I fear that'll some day end up as a total lunatic chasing illogical ideas where I go. On the other side... I'm too afraid of becoming so - can something happen if it's prevent by the stuff that's always happening? Will humanity ever find out why in hell Douglas Adams didn't chose 39 instead of 42? Is it worth using peanut instead of marmelade?

Questions over questions. And no one will solve it! I have to watch some nice movies with friends the next day. And I'm glad that tomorrow will be my last official study day this week. There's a Manga Convention on saturday I'll visit with my friends. After that we'll probably go stuff our stomachs with ramen (except me cause soy is evil) or sushi and watch a good movie or two. And sunday will probably the same except with all the stuff from saturday, so... nothing. Sunday will be nothing. Just relaxing - something I didn't do that often the last time... And I feel how really, really sleepy I am right now. Strange that this always happens on those days when I drank too moch cola, ran around like a madtime and did some housekeeping as well as general internet chitchat. Seems that this is "thrilling" enough to make me sleep like a stone afterwards... Shouldn't get that coffeine into my pristine body (ahaha... what a joke... pristine!).

totally forgot about that

Oh and I'm working on a small remote-controlled vehicle using Lego motor parts. Since my gun is done and my room will be ready for some photo shooting tomorrow, I want to make a non-programmed vehicle first. That means that I'm currently working on this Lego NXT study project with some fellow students and I don't want to tingle around all day at home with programming stuff because I rather prefer using them for the game engine. That fact that we have to use Lab View is horrible. But atleast it's makes appreciate normal programming at home a bit more.

manage your living!

I've made a final game engine draft for the ASCII raytracer I've started so long ago and merged with my scripting language. I didn't post it, did I? I've made a realistic draft about how it's bytecode and it's syntax would work as well as some API design more making common things and so on. It uses only fifo and lifo stacks available as arrays and linked lists. The bytecode is also extremely minimalistic with so far only three commands, mostly making everything into "parameter-less" function call of interpreter-executed and external functions as well as pushing constant binary data to the stack. I've added some really stack-structuring functions that should come in handy for all later stuff. I'll use it as my scripting language due it's minimal and theoretically high execution speed as it simply doesn't require and any complex bytecode unpacking except and more lengthy binding mechanic. It plays nicely with my current game engine draft and I never felt my whole goal in programming more clearly. The engine has a fixed feature set and everything else is controlled via the scripting engine. All interactions are event-triggered and the engine itself does only provide physics simulation (triggering such events) for gravity, bouncing, map deformation, water, electricity etc (yes, this be a part of the combat system - think about lighting spells on armored knights!) and map streaming as well using a map graph. Every interaction, camera movement, HUD control and so on will be made available to the scripting engine. Even if the performance is too critical for certain parts like path finding or so, I can still utilize a wrapper to an external C function working with exactly the game engine's structures. One thing that is not a strength of this scripting language is that there are no structure at all. There is a loose typing system used to process batches of different input parameters, but no real type system behind. I don't want to waste any time with trying to integrate structure concepts because the language should emphasize the use of batch processing and random input values to get away from too declaration-heavy programming that doesn't provide any code but interfaces (take this, Java - ha!). I don't call this optimal, but concept is concept. I like pure concepts. They motivate myself to focus on problem solution in a restricted environment. In case I'll program something personal the next days, I'll program on this game engine. A demo with a test level should be enough to demonstrate that I actually can be a game programmer and not just a metatechnical weirdo.



Besides playing Oblivion once again (for Skyrim's sake, ya know), I'm thinking about how realize all those things I've begun between lectures and during the first term break half. Most of it works more efficient when using macros and I begin to find it annoying to create more complex stuff out of them. The point is that I badly need more advanced "code pasting" build within the language to actually make writing them motiviating enough for me. I simply don't want to objectify it on this level, so I have no real choice but do so. However, once I've finished n-dimensional loop macros and regexp replacement for nested and binary structures, I won't have to stick to macros that much or rather finally use macros and make convenience functions for image drawing and so on. My original goal - making custom stuff way easier and quicker to write while having an equal if not better performance. Using those macros isn't as nice as one might know from overloaded C++ operators. I'll probably create some template inline wrappers for C++-only use. Sometimes you have to seperate your codes in seperate technical levels and layers. Currently, I'd actually appreciate a C/asm base and a C++ wrapper above, simply to have operator loading reading. I know I won't need them later that much, but I also do not want to end up giving nothing out to a world that might get an advantage from it. I also know there's simply no real library out there for Linux like DirectX for Windows. I probably won't change that, but I can atleast oriented myself using it. Every time I start working on my toolkit, it's goal changes a bit and I'll eventually end up with wanting atleast a videogame toolkit. So there it be, get it finished, bro! Atleast enough to use it nicely for videogame programming, so that you can show what you did so far. There's still an internship I want to have in the games industry, so it's always good to give something they can analyse inside-out and see that I CAN create videogames somehow. I'm not too fond of luring companies without candy.


drop me some Lego

I now deciding to put all Lego back into it's cabinet and be happy with what I archieved so far. I'm starting to worry about me and my code progress! I started tackling some pathfinding for this reason and think that I found a suitable sensory simulation for making video game enemies to dynamically adapt random surroundings and locate entities of interest by following sound and graphical input. To bastard-quote Patricia Tannis from Borderlands: "I already know that this game will be the death of me". I only need a good, possibly iterative skeletonization alghorithm that has the same effect as repeated erosion without doing those erosions. There's probably a nifty solution to this problem. My idea is completely "rebuild" the way we as human orient, by seeing where we can go to and from where localization hints come. So that in the end the NPC is able to use those hints and rely on memorization and analysation of the surroundings in case of "signal loss" (everything like not seeing or hearing or feeling the player anymore). Using a simple piece of if-then-else code, I think it is possible to make a very nice AI system. If the skeletonization also works for n dimensions, I can make flying and 3D-orienting enemies, too! I hope my ideas turn out well and so on. Sometimes I doubt that. Not happening unoften.

better ghost sight

I'm kind of curious how add a sight to my current gun that has as many ghost rings as possible but doesn't obscure loading process. See, my original idea was to create a large series of Lego axels and a rotation point for them so that I could adjust them freely. But such a construct would require a sight covering the loading ports when the slide is open. So my measurings showed how impractible any other solution with more than two ghost rings would be. But I could use half studs instead... Need to test this.

Oh and in case I hold to need a bullet holder, I added a pair of two pins along the loading port which can be used to stack bullets on them. So it's a very short way between chamber and bullet holder. However, it's fiddly to work with. I'll probably only use seperate bullets instead.

False alarm

I simply tested whether a longer bullet could stabilize the flight and it really did stabilize it, though there were some flips here and there from time to time. Bad about was that it didn't fly as far as with less length and less weight. So I shortened the long one back to 1x1x3 (still longer than 1x1x2) and voila, it is a mix of both. It doesn't ricochet on short test ranges and it hit exactly where I was pointing at. I'm using a metal cap from a Lego knight thingy I once bought a while ago for some strange reason. It makes a powerful "PLANG" in case of hit, so I do EXACTLY know when it got a pinpoint. I have whether it shoots as good on longer ranges. Will probably not fly as long as when using the feather-weight bullet, but I rather prefer accuracy.


Ok, it's a milestone

As one might guess from the title, I'm not so convinced about this model's "output". I did some shooting to have an "ultimate" test for how accurate it really is now. And, in it's restrictions, it does everything right of course. My gun creation really works as it should. Subtract this from the high amount of ricochets I got right now and the result is not a gun problem - it's a bullet problem! More specifically, the idea of puttin in a cartridge that made as minimal as possible and only provides a long bullet flight, not pin-point accuracy. Why didn't I made the sight before I added everything else? Disappointing. I'm really disappointed by me and my blindness. However, this provides me the ability to underpin certain theory I expressed here before. The first is that there are still tolerances between cartridge and chamber in the gun model. Though this can't be a reason for accuracy failure due to the very, very small tolerances and the extreme ricochets. Second is that the cartridge rubber band position when charged alters the bullet trajectory. I've overcome this problem a bit by selecting a different bullet shape that forces the rubber bands to fit in place. And now the third I was able to prove by the second one: a charged rubber band alters the rotation of any somehow movable element it is pushing forward due to surface contraction. I was able to eliminate point one and two, but point three requires a different cartridged format which I already tested without actual improvement. So the last is point four: the bullet shape itself will alter it's angle and rotation during exit and flight as well. This is the point I see really problematic because I'm using rather non-aerodynamic Lego Technic parts having a big hole at their end that's definitely useful for locking it but not for letting it fly. So my observations showed that this is the main problem as most bullets went out nicely but didn't keep a straight flight. What a shitty problem! There's no way I can change this in such a small 1x1 bullet and a 3x3 cartridge. Really, that's just too small for it. So I AM forced to make a bigger caliber for hopefully more predictable and flat trajectories! Oh man, I can't expressed how disappointed I am about this. Such a cool Lego gun and now this unchangable problem. I can't even change just the bullet, I have to create an entirely new Lego gun with an integrated system to suppress all those problems. Shit, I finally believed to have banned them all at once!

I'm such a fool. Now there's no realy reason to it at all. I'm sick of it right now. Can't believe how disappointed I am about myself right now. Hope this actually DOES change tomorrow! It's more than annoying to see all those 3x3 cartridges fail completely. Why can't it just work? Stupid physics.

Pulling myself together

I'm all about managing my lectures right now, but if everything turns out right, I have atleast one free day in each week, which's currently today (friday) if everything will turn out correctly. This does mean that I'll have a half lecture of compiler construction (goes along with personal interest) and some more abstract constraint-related stuff using Prolog - something I never did before and of which I already lost a week. Sometimes I doubt my study place' sanity in terms of cross-lecture time management.

However, I used my free Friday to improve my gun model! I was so frustrated about everything, about E.Y.E.: Divine Cybermancy to be inunderstandable, Fable III for having a disappointing ending beeing made for shitloading DLCs for maximum business success and grandmother birthday I totally not enjoy anymore (and will probably stay home instead). Therefore, I started working on my Lego gun again and I did quite some progress on it! Sure, it was functionally finished but lacked stuff I consider "nice" and making it more usable. So I replaced and simplified the ghost sight (also, it is green now) and added a stock! Yes, a real stock for my gun. I took me not just a few hours to mess around with it, but in the end it is really stable makes aiming more stable, especially while triggering! It looks a spider net, but who in hell cares... I also created an actual lever for the barrel/chamber opener you can use with your fingers or by pushing it with your palm's side when holding the fore end. So yeah, it comes closer to something I'd like to use from time to time. I'm trying to create a proper "loading bench" for charging bullets correctly. I'm also trying to create some attachable bullet holders to the case' side one can use to store bullets and having a short hand way when loading. It'll probably look like the bullet holder from my very first muzzleloader models, with some kind of flap to keep them locked.


Annoying semester

Damn, this semester is really annoying. Besides some rather interesting practical work with an NXT robot (which gets immediately perverted by the fact that we HAVE to use LabView...) and the usual multimedia theory, I don't have much choice but take a Prolog constraint logic optimization (wtf are these fuckers thinking) or some stupid electronics. Seriously, I'm so damn pissed of by this... It's the last semester with actual content and they are delivering bullshit all the line. I don't know what they are thinking, but I'm not convinced and I doubt I'll fun with all that this time. I hope the semester turns out quick and I can start making a bachelor project, which I'm not entirely sure what it will be. I'm desperate! I need cookies.


Final 1

It really took me a day to make proper sights for my gun. There were a couple attempts for normal iron sights, but non of them were satisfying or even worked. Actually, I don't really know if they worked or not because I found out that once again my cartridges are the accuracy problem. Using 2x2 bullets there wasn't a problem at all, but 1x1 bullets do not forgive any false cartridge loading. It's said but workarounds exists. One is careful manual charging (not what I'm looking forward to) or using a loading bench-alike construct. In the end I was trying a double ghost ring sight and succeeded so as all 3 shots (carefully charged) hit the metal plate I was shooting at. Didn't test how exactly accurate the gun was, but from the aiming tests without size, my ghost sight perfectly targets the bullet's exit point. Because of the gun's design and open firing mechanics, I wasn't able to install a more interesting sight with adjustable rear and front height. For the next gun I'll either use of those or directly a selfmade telescopic sight (not of high quality, but still with magnification). All in all I'm pleased with the gun so far and will probably not need any later adjustments. So I archieved my goal, didn't I? Stock is not needed, aims perfectly without. But I noticed why it would be beneficial to have one. Simply easier to get a stable eye position. I want to finish this project as quickly and simple as possible. Technically the gun is done and works fine. Now I need a help to load the cartridges more reliable. Can remember that a cartridge charger worked fine before, can't harm to quickly build one. I'm not yet convinced with the sight's look. Needs some serious optical improvements! Too bad I can't make them any longer without destroying accuracy. I'd love to have an internally chessboard-colored tube with black and white rings for easier aiming. Hm, another feature to build into the next gun.

Oh and I've thought about going beyond single projectiles. I know that 2x2 bullets provide more room for loose Composition of parts making having the size of a normal 2x2 bullet. Thus, it'd be interesting to get some kind of buckshot projectile. A two or more part bullet that scatters on impact is easy to make, but multiple shots at once are a challenge. I was able to fill my first gun with half-stud rings and Lego gold coins as shot. I hope I'm getting a better bullet-packed idea for the next project.

Continue 6

Damnit, I really don't know what to do with this stock. So far, the optimal length seems to be atleast 25 studs from the gun end. that's enough to put something in as I'm always saying, but I found a collapsable stuck rather useless this morning and experimented with storing cartridges inside the stock. Then again, it's stupid to thinkg about this repeatedly. You know what? Drop it. Just drop it. It's not worth working on something that stupid to realize. No, I'll make a proper sight instead and to some test shooting! Really, nobody needs the pope to be that fat. A big gun and some bullets - what do I need else? I should think about stocks anymore. I mean I'm making Lego guns which do not have any recoil...

So I'm finishing this and will make some pics one day or another. I'm not anymore to work it's additional features anymore. I mean it's working, right?

Mindstorms balls

I wonder whether those Mindstorms balls would make good ammunition for a Lego gun. I'd normally only use 2x2 bullets in my muzzleloader Lego gun I'm making next, but those balls are probably better at accuracy. They are also very lightweight as there's only air in them. Gonna have to try that one time. Could make a very nice ammo as I have 12 of them.

physical origanisation

I bought a functional and simple looking cabinet for storing my Lego parts, made of metal and some rolls to move it around. Combined with my metal tool case which I used before, I have a nice little storage for with I only need some addition seperators to distinguish inside the drawers. In addition, I've bought 200 rubber bands I can use for guns! 100 made of rather simple caoutchouc and another 100 made out of the same but with a smoother quality. They have exactly the same propety as other rubber bands; way better than those 8 years old Lego rubber bands I used before...

And I began to work on a stock in the same colors as the gun itself. Now that I can organize my Lego pieces better, my desk is cleaner and I don't loose interest so quick because of workspace pollution. A cabinet was really necessary. One day I'll buy a bigger one for the normal Legos, too. I still have more normal Lego than Lego technic and I feel bad for letting it rot away on the weathered attic. And who says that I have to only use Lego technic the rest of my life? There's plenty of potential for classic Lego creations, of couse! Especially those that are reusable. I can remeber posting about a plan of making Lego scene "modules" to quickly build stuff on a square base for instant scene creation (like video game tiles or Oblivion's dungeon system). Hmmm, I'd feel much better then... Anyway, such a cabinet won't be affordable as easy as my metal cabinet. It's a really cheap one but quality for storing Legos or.


Continue 5

I tried to add a stock to my Lego gun but I was not able to convince myself that the stock-independent grip is good enough for simply attaching a stock. There was simply no place where it made sense to add something stable. So what I did today except designs and concepts was to completely redo the grip and it's thumbhole. Trust me, it was hard to find a final shape. I'm glad I was, at last, able to remember the way thumbhole stocks look like and what fine details are necessary. I underestimated how important it is to provide a 1 stud wide area beside the other 3 studs wide ones. I'd get blister from it otherwise! Whatever. I also added dark grey parts to make the grip look and feel more like a single piece of Lego (which didn't really work due to several reasons). I also made a nice litte charger grip that works very well for charging individually and both at the same time.

Well... Only thing left is the chamber opener. That one may take some time. Oh and the stock of course. I'm still hesitating because I don't think that a stock is really necessary. Independent from that fact, my "Faulenzerkralle" mechanic is simply useless as it seems. I simply don't know what sense it makes to create it because the way of locking it to position is as better on it's own to be a stock. I'll make a straight rectangular block expandable by up to 40 percent or so. Should be enough since a normal grip is already present.


Continue 4

I made a quick butt stock build this morning. Though I didn't have the time to properly rethink it, I believe that using a more skeleton-like base all over the stock does not work as good as complete assembly using cover or other stuff. But well, I only have red and some yellow covers, so it's not really an option for anything except small and lightweight Lego guns. To compensate this problem, I made some very quick and rough sketches of stocks that can be compressed/folded/collapsed. It doesn't replace a fully-blown stock but makes it way more easy to save space for storing the gun. Anyway, there are a lot of different ways to "store" a stock. Due to the fact that there's already a stable and comftable grip + thumbhole, I only need to store the butt stock. A part for laying the cheek is barely useful because I can't align the barrels with making a completely different model. Therefore, I have to aim for each barrel individually - a situation where I'm moving my head, not only the eyes. Anyway, no cheek piece means "just" a butt stock. One solution would be to use a piston capable of making the stock around 25% longer (sure, up to less than 50% percent is possible, but makes it rather unstable). However, pistons are not as easy to create and may take quite an amount of parts I can't come up with so easily. The second option a foldable stock made up differently sized elements to fit in each other. A really cheap but very stable construct under certain circumstances. It's not adjustable like a piston - may be annoying in case a long stock is needed but will be larger than the skeleton grip. This can be overcome by using more than two or three foldable elements. So my next idea was a combination of both by using a mechanic I know a "Faulenzerkralle" in German, but was unable to find any english equivalent except maybe "grab hand" or something like that. The original is usually a pair of hands or claws that can be stretched and closed at the same using one or two levers and multi-joint beams (can be found in child magazines as gimmicks or in toy stores). However, using a construct like this as piston and some beams for stabilization will make it possible to give the stock a +50% expandable butt end! Depending on how long the collapsed block length is, it's also possible to add an area for laying the cheek somehow. such a construct could interesting for all kinds of later Lego rifle, so I'm definitely giving it a try. Guess the only way to realize this one is use grey pieces combined with another color (I simply do not have enough differently colored parts). Hm, I could use coverparts for the butt end... Oh, and I could possibly use the same locking mechanic as used in the case! Geez, didn't know how inspiring such stuff could be.

So yeah, you see there's a huge potential for this one. I'm happy I didn't stick with the skeleton stock in concept...

around 90%

Yep, I'm around 90% completition right now. Rework the case for consistent color choices, got some black beams by replacing the striker and charger parts with grey ones and made a stock skeleton without shoulder, having only the alsmost-pistol-grip-alike section and it's thumbhole. The stock skeleton is currently dark grey. At first I wanted to used cover parts to mimic a more full, wooden look. Tested it with some red cover parts, but they simply didn't make any good material. So I simply used those angled beams like I used them before for everything stock-related. A few small bendings here and there to a lot to bringing stability as well as using many, many connectors. Currently, it's only 3 studs wide and gives a rather lightweight feel when holding it. A fitting contrast to the heavy barrel and lock mechanism. I'm also pleased with the color choice: a blend from a thick stripe of light grey to a small bit normal grey (also covering most of the top) turning almost immediately into black. Beeing consistent all over the gun's parts except it's grey butt stock, pistol-alike grip and triggers. I still haven't found a good charger grip I have to say. But I want to keep it dark grey, too. Combined with a dark grey lever for opening the action, this marks all mechanics the user can operate with dark grey. Interestingly, my fore-ends are often differently colored without any similarity to the butt end (as well as it applies to it's shape) But since the stock/grip is now an element one can pull, too, I guess it is okay to color it dark grey. It also seperate the parts one might not touch operation from the ones that are made for using...

So what's left is the rest of the stock, the charger grips and the action opener. I haven't yet done anything about the sights and I'll probably make them detachable in some way. Or let's say that I don't have any choice because the case is made to only have a few empty holes on top for such occasions. Maybe their simply won't be any sights on it for a while. I can live with that. I don't really need sights if I design the stock well-fitted. However, it doesn't remove necessity with non-aligned barrels. All in all, most cosmetic details were also removed, so I'm close to finishing this model. Took me not so long to realize (two week I'd say?), but long to come up with. Now that it's closer to beeing of a degree of polish I wanted in the beginning, it makes me proud that I've spend my time on engineering it. It's really more like some kind of engineering or even gunsmithing right now.


archieving the last 20%

I find it rather difficult to decide how the stock should look like. Well, I know how it could look like and that there isn't much to add, but I want a stable and thus possible tech-loaded stock. There is so much space wasted by only building an empty shell one can push against it shoulders. And there comes the option to create a an adjustable stock. Since it seems that I need to create a detachable iron sight with possibly adjustable height/angle, an adjustable stock for all those possible sizes is a good idea. Plus that it frees me from creating a too fixed stock shape and so on. But still, fixed stocks always look so nice... Much nicer than those adjustable ones. I don't know. I really don't know. Gonna look up some more references...

not less than 80% finished

Yep, that's right. I had a rather long night until I was done with most of the Lego gun's functional part. At around 5 am I decided to leave it as it is and get some sleep... However, as I wrote just before the last sentence, I've done a lot of stuff. First of all I lengthened the case, the gun itself and added a striker charger totally seperated from the trigger mechanism. That means you have two chargers you can pull at any time and it will cock the gun but never uncock it on accident without triggering by user. Second, I've reworked the case' upper cover and made them way stronger than before, so that you can essential let the action slam-open wihtout any stability decrease or even stuckage. And third, I've overdone the action itself and made it so that you can now seperated case and gun body by simply holding the action opener a bit longer until the whole body slides out. This wasn't as easy as I had do redo a ridiculous old work of mine on it, but it works nevertheless. It's really heavy now, 43 cm long and probably a few kilogram heavy (haven't yet weighed it). I though about how to reduce it's in later models, but I didn't find any way that wouldn't sacrifice stability or functionality. Another good thing is that you simply can't interrupt the trigger process via case squeezing or so. I was able to do that in the last model and I'm glad it isn't the case with the current one.

Yeah, I'm finally almost done with it. The only stuff I have to do for pure completition is a stock and a proper grip for the chargers as well a pair of rubber bands to automatically move back the chargers after locking the striker. I rather want to finish the charger grips before adding rubber bands. It's simply a better idea when incorporating important ergonomic choices. Another thing that needs to be done is a rework of the action opener to operate more lever-like, so that it's operation is less a twiddling of small Lego parts one might never find out about. If those four things are done, the gun would be ready for deeper operation tests and attaching extras (iron sights/scope, maybe cartridge holders at the stock side). But this is not an quick or even easy step. I'll finally have to make a decision about the stock and I'm struggling with just building a random one. I don't want to have any randomness in it. Everything has to be exact and well-thought. This gun is already so stable and well-working, there's no reason that I'll not do everything to have it perfect in the end. Or somethings that's close to beeing perfect with such limitation. Whatever. So now I have quite an amount of work to do! Also, I noticed that it's rather easy to detach all gun parts and maybe make some set of instructions for them. I wouldn't want them to be published in any way, but rather for personal use. In case I want to make a second one some time. Oh and I due to this detachable nature, I might change some colors internally to have a functions shown in distinctive schemes. Whatever.

I'm more than short on black Lego beams right now. Almost all went into the non-case parts and it kind of hurts to see this. Especially because I don't want to desintegrate this gun and maybe build another one... However, the next model can be grey and red/yellow or something like that. But I'd tend to yellow cause it'll be the described muzzle loader. I believed I used Lego parts worth several hundret euros. This doesn't include design work as this is the most complicated part. If I'm ever going to be damn famous, they will probably be auctioning off these guns in case I die or so. Woohoo, I might get famous from those guns all alone! Atleast from how I feel when looking at it right now (yeah, I might have too much Lego and too many guns the last days).

So I'm glad I actually did sit all night and continued to work. As exhausting this often is, as rewarding it can be. So let's work on it for the few hours I have left til I have to go my first lecture this semester...


Stuff I always wanted to do

I'm amazed about how fast my internet connection is now. I was able to download around 15 gigabytes of data in just a few hours and am now able to play my games again. Currently, I'm running around in Fable III, doing the very first missions and shooting some rampant wolfs on my way from snow mountains to thick, grassy towns. It's very much like a highly polished, stylized and more developed version of the original Fable style I memorized more than in any other game. There are already some design decisions I dislike like the replaced menus (now beginning a walkable room of sorts) as well as it's Windows Live integration with a totally useless and money-grabbing ingame shop system. I can't much about right now, but whatever I might say in the future: it probably is an improvement of the original game with many decisions improving design purity and graphical presentation.

Also: loading games with 1,7 megabytes per second really is something you must have felt before you day (or faster, whatever you may be able to get). I used Steam and Youtube parallely and also downloaded a speedrun in the backrun. Absolutely flawless! It's stunning how I am finally be able to enjoy all the internet's features I have experienced before in this way. No pre-loading of videos, no days-long waiting for video game downloads... I can focus more on other things and let the connection do their business. Also, this makes it possible to finally record and uploads videos from the stuff running on my computer screen. I'm tinkering with the idea of making commented playthroughs/let's plays/whatever because I finally can. Internet I'm coming right now!



YAY! Finally. FINALLY!!!!!1111oneoneone. Yes, it's highspeed internet. Pure highspeed internet! Lovely. Simply lovely I've to say. I can finally do all the stuff I want without any restrictions. And in 15 minutes I've downloaded game content that'd require 2 days otherwise.

I'm in heaven. Put me in a nightie and my halo will glow all over the internet.

Continue 3

Yep, I found a solution for my charger problem. It's not a new solution, just the overly long one I had in mind when started rebuilding the non-case parts. It makes the gun very large: 43,5 cm of which only 1/3 is the actual chamber (stock not included!). 2/5 will be shared by stock and the triggers, making it look like a Tompson without stock. *sigh* Seems that a proper proper with long and hard to trigger cartridges doesn't make a small Lego gun as it seems. However, this one will be very, very reliable to operate. When it's finished, I'll need to modify the bullets for higher accuracy. Or atleast create a loading bench so that there's no stupid bullet misdirection when charging.

Continue 2

I'm a bit confused about what to do next on my Lego gun model. The point is that I could simply created a stock, integrating a seperator to me from firing any bullet when slam-closing the action and so on. But the more I think about it, the I dislike the idea of continuing without further thoughts and tests about how to a properly chargable set of strikers. I've given up the idea of charging them without only the trigger hand, simply needs a too long slide way. So I have a couple of possible paths to take:
  • add a stock and seperated chargers later
  • create chargers first, having a properly seperated stock/charger setup
  • drop it and wait for the telecommunications dude to install my highspeed internet connection and play Fable III all day long

As compelling as the last point sounds, I'm not interested in waiting but doing something. I guess when he's coming, there won't be any Lego gun stuff in my head because I can then finally do all the stuff I wasn't able to do in MONTHS. Will probably all night up watching Youtube videos and parallely downloading Steam games as well as all other things I will be able to come up with. So the first two points look much more realistic to me. And I tend towards the second one. But still... maybe I just need to lengthen everything and don't listen to my stupid self. I mean in the end it probably doesn't even matter how long the actual gun is because I can connect gun body AND stock and provide a thumbhole or whatever. I know this may not be the nicest solution, but it'll ensure that there's enough room for reliable triggering and possible safety features, too! In a slightly sextual content, it amuses me that a longer gun can in theory house more tech is it. Size DOES matter after all...

Big Pandora Rant

I'm somehow in a bad mood today because I checked the status of not-yet-delivered Open Pandoras of which I ordered one ages ago. It has been some years since then and I'm close to forgetting it. So many countless times I've waited for them to reach my home, so much was told that they were busy doing so and so on. In the end I'm kind of frustrated and am almost at a point where I'd simply grab my money back in case they're offering me to get it back. And then they even makes stuff like premium orders which will seemingly be send after assembly, no matter who was the first and who not. So not just a few lost Pandoras that could go out to people waiting years to their hardware. The newest stuff they introduced was paying 1€ monthly as well as getting a "special status" on the Forums. Of course, there was a lot of shit with Circuit Co. that made them loose a lot of money, financial crysis as well as hardware problems in general. But all this doesn't really calm my mind now and 300€ is not a sum you'd like to loose that long for getting nothing back except random production news.

I hope they finally get rid of that stupid Circuit Co. mess and continue producing Pandoras for the people that made their projects financially possible in the beginning. What's the point of giving money away for a long time but only seeing other people benefitting more from it than you will? I don't when they will finally ship my Pandora, but I strongly believe it will again take a fucking long while. And maybe I won't be the last one getting his damn Pandora in two lifetimes!

Almost done

Not totally almost, but I'm very, very close to it. As I said, a lot was redone and I found the best trigger system I was able to come up with. For some strange reasons I utilized three original springs in the whole model - that's a personal record cause I never really used them in way. Two were used for the trigger component (which I'm now really proud on!) and one for the slide-action lock. Then chambered, you need to push a spring at the fore-end to start sliding/opening. Closing can be done by a skilled moved or by hand without any spring push. This way I can ensure that it'll never open while shooting and do still have some loading comfort. It's all running very, very well now. So it pays off knowing that there must a simple solution to everything. Tomorrow I'll need to build a stock and think about how to double-charge the striker. Oh, I forgot to mention it, did I? I noticed that my initial concept of two seperate parts was simply not well-thought enough for a double-barreled slide-action and would work better in a single-barreled Lego gun or in an over-under arrangement because one would simply have more room for such experiments. Instead I choose the old variant with the striker chargers directly attached to the strikers. As first I was afraid they would simply make it too heavy, but the action runs solid inside it's case and I haven't noticed any flaws so far. There could be certain improvements, but there was simply no place to put them. I didn't have much room and I still don't have. I made this Lego gun as compact as possible with a set feature list in mind. That's why I didn't want to make something ugly and patchwork, but especially improve what was wrong in the old model. I guess I succeeded today. No wobbly action, cartridges do fire properly, no way to "umchamber" on accident, no unreliable hammering due to speed-sensitive triggering and no exposed mechanics disturbable from the outside. Nothing of this so far, it's like the black muzzle-loaded pistol I did as an improvement of the very first one.

However, there's still a lot to do! No stock, no sight, no safety, no dual-charger charging both strikers, no proper grip for opening the action and finished gun end in general. I'll also need to prevent my hands from stopping the charger grips. This has happened to me with the previous model and it's definite no-go cause it make the striker unable to trigger the cartridge. I'm even thinking about making some very special and unique grips for those chargers to reduce overall size and make them more suitable for a generally thin and very custom stock. I'd like to keep stock black, too, but I believe there is just not enough in my "smooth cover parts" box to do this. Gotta buy some Legos, I guess... I even had to use some differently colored cover parts for the fore-end to let it work. They will be replaced as soon as I get more of those parts. All in All it'll be waaayy shorter stock than before, that I'm sure about. Rifle stocks take so much less parts when not having a pistol grip in it. I won't add any cartridge holders to the stock as before. It makes it even more heavy. The previous model had it's more heavy spot right where the stock was, so simply not optimal for balance. Since the new model is already heavy enough, I better keep it lightweight and simple. No sophisticated tech, only a simply stock and maybe some rings or other flexible elements for adding cartridge holders sidewards. However, that's all not part of the original feature list. So I'll concentrate on making a realiable gun, not an accessorazored beast.


Plenty of beams

Back from backlogged Lego gun models to my current one, I'm glad I created the case in the very first moments I started creating it. This way I was able to instantly rebuild the whole inner part, which I had to because of my trigger redesign. It is sursprising that I didn't have any trouble to do so - call it good luck that I do now only have to create the trigger mechanisms and the grips to charge the strikers as well as the stock part. This isn't an entirely easy task as it requires to a) really think about the overall arrangement without knowing what's the most comftable b) somehow make the striker charge grips accessible via trigger hand and c) modify the case so that it'll be a bit shorter and doesn't house the striker chargers. I thought about adding some of it's segments to the gun's fixed body itself for reasons I don't exactly know. But thinking about it... I guess it's a better idea to lengthen it instead. There's surely a bit of slide space required and I better do to sacrifies stability. Still... I have concerns related to the position of trigger and striker charger grips. I mean the longer it gets, the more the chargers move away from the trigger and the less it will look nice and be comftable to cock without one hand. I guess this is something I should not try to think about too hard. First make the mechanics, then add ergonomics.



So I found a promising way for locking the striker that's not unlike the bullet/cartridge lock mechanism. It will use a single pin and a technic hole to properly lock as well as force vector that differ by 90°. That'd be the perfect case for proper locking - isn't that what I everyone wants for an unlockable lock? However, this method wouldn't be that great if there weren't these small claw-alike parts I discovered yesterday. I believe they can fill exactly the gap for small lock mechanism I'm always looking for so badly. Discovering the english word "sear" for the first time in English (also: in a firearm context), I think I've finally found the perfect to describe my mechanics a tad better. Sears, locks and springs - that's what most gun tech is all about and also the only stuff that always interested me in mechanics beside gears and all similarly related stuff.

Anyway... this lock "implementation" is certainly the most spiring lock ever since I started making Lego guns. I've used it before in my earliest models and didn't realize how to make it smaller. Now that I know it better, It'll be awesome I assure you! And here comes the output of this inspiration: I said I wanted to have a muzzleloading, very long Lego gun after the current double-barrelled variant. And well, it has to be some kind of musket with scope and other stuff that's not possible with my cartridge designs due to their sheer size. The problem with all muzzleloaders I did was that their bullets would fall off when tilted below a horizontal base line. I believe that I finally found a solution how ot overcome this problem by using a pressure-sentive bolt at the barrel breech which release a lock otherwise holding back a sear locking the bullet release mechanism. So after using the ramrod, a the bullet-backholding sear will snap right into a hollow in the ramrod end and will lock from this point on. Because the pressure-sensitive bolt was pushed, the trigger is now ready to release the bullet. After the shot release, the trigger will snap to it's pulled position until the barrel breech's bolt will be pressed again. So it'll always be cocked when loading and you only need to ramrod the bullet all it's down. Unfortunately I didn't noticed that the same effect can be done with the lock I'll use for my double-barreled cartridged rifle, too. That means that however awesome this concept may be, it's more complicated and even more error-prone than the most simple of all available solution. So it's more of a no-brainer to make this musket one, I guess. However, depending on the barrel length and rubber band used, you can get quite a massive range and power for a Lego I. Sure, it has heavier bullets and will probably need to be veeeery long, but that's definitely worth testing it.

PS: Check out this site about swing locks. It's an action/lock used for percussion cap muzzle loaders only that gives a really awesomely reliable design. The idea is amazingly simple, just check it out and give it a go. I really love the compactness of this design.



Well, I've spend half the day thinking about how to save the thing I've created for the last post. I was somehow optimistic, but it turned out that I'll either have to drop the rack and create some other mechanic for trigger release or adding a spring of rubber somewhere to keep the striker lock where it belongs to. This does NOT come in handy and sometimes I really want to drop all that striker/hammer stuff due to this. Maybe I should simply to something entirely unrelated, I don't know... Also, some research made showed that no double-barreled gun with multiple triggers arranged along the gun body does future a pistol-style grip but instead a flat stock or a slightly bend grip suitable for using both triggers in the same way. Oh, did I mention the exact reason why I have to rework it? It simply can't hold back the hammer. Sad but true, kinda annoying. Tomorrow I'll try another variant by going back to a rotation-based striker release where the rotation axis is placed on the same level as the striker. I'll also used this concept on the bullet in general and guess that this could work nicely enough in theory. Since I DO have enough room for all kinds of stuff in this gun, this should be much of a problem. Will simply test it out, who knows...

Holy hogs, making a reusable mechanic really pushs you back a couple of times. I shouldn't complain, but AARRRRRRRGGGHHHHH. Sometimes I simply have to type exactly this. So I don't need to compensate ethereal enragement.

Triggers in a row

Right now I'm at a point where I'm designing the sequence of triggers for firing both barrels. At last I did it and do now have a system that connets two triggers to their their lock counterparts. Pulling feels nice, maybe a bit too heavy I think. Not sure about that. The problem I do see there is that in the current arrangement both triggers have a reeeaally big gap between them and I don't know how a firearem does handle this. I guess you can't cover both triggers with your fingers and then firing the first one without tucking the finger behind. Also, There seems no real possibility to add a pistol grip this way. Not sure whether I want to have that or not... Don't know. Have to think about it. Anyway, I wasn't so easy to squeeze all into 5 studs and 3 studs height. Guess it pays later, right? Gonna do some reasearch on common grips for double-barrel shotguns with two triggers to solve it.
It's annoying how long you have to pull out the hammer to ensure that no extremely slow trigger release will prevent the cartridge from triggering. It's a serious problem and can't be solved differently due to Lego's fixed part size etc. Dunno whether this is different in firearms and how they would solve it, but because normal hammer rotate but don't slide, the way to travel is longer and will thus still develope enough power for striking. The more I realized this problem, the more all those shared properties of hammers and cartridges melted together. In the end it's a series of connected cartridges with different strike powe and part selection...