Some more thoughts about typing in programming languages

While looking for compiler-independent way of determining a system's endianness, I stumbled upon the idea of keeping my program language type system purely on a reflection level. This means that data and member access is only know for standard builtin types, but can be complexified using pre-compile offset generators totally independent from the underlying type system. However, this partially contradicts and partially supports the idea of specifiying structure information using the data/type storing itself. I mean if you need to specify a structure using an array with type identifiers, how would you type this array if the only known types are atomic builtin types? Right, using an address and than knowing that there's an id of type "type" stored. You can iterate based on your knowledge, write an array accessor or create pre-compile code generators to access on reflection-based level. I think that this language, at it's core, will be even more minimal and cruel than C, but extremely flexible and alterable. Depending on how good your pre-compile is, you could even write optimizers using the language itself... I still love the idea and I think it's time to gather up a minimal core and create this one languages that's able to improve itself this way. It's a bit like the philosophical part of Star Trek's future government principle: we help the language becoming a better language and the languages helps us getting better language makers. One hand helps another, recursively improving on already-archieved favors.


Video capture card

Guys, this is one of the most awesome I ever had since quite a while that didn't have to do with programming or so. I'm speaking capturing your standard video/stereo signal from console output and display it on your computer screen. I always wanted to get rid of that annoying TV, all those battery-eating remote controls and so on... Really not what I want when playing video game (what a double-meaning Wii reference). As with a similarly priced external USB sound card, I watched out for Linux compatibility and atleast a binary driver for my current Ubuntu 10.4 setup. I found out that Hauppauge Computer Works also helps developing Linux drivers for their products, which's a good thing by default. More interestingly, the software provided by them (called "WinTV"( for watching and recording was the only one that didn't look some lame Youtube clone (I like the comparison). It has a reaaallly nice subset of functions, beeing a programmable video recorder and a realtime capturing for all kinds of analogue input I can think of. So I got myself a "WinTV-T Video Edition", which is a very compact little block with LEDs and connectors on it's site. It also has a DVB-T antenna (I don't watch any kind of TV), but that's just an extra compared to ability to finally not needing an additional power-sucking TV somewhere. It replaces the kind of stuff that always annoyed me when wanting to play a non-PC video game. And yes, I'm more than satisfied the hardware and the software as well. The player has a bit of delay here and there, especially when initializing (guess this has to do with certain driver access and USB latencies), but it's a fitting piece software otherwise. It has buffer-less record/capture mode, shows up the TV program and lets you play your recordings within whatever time you want. And even more stuff I don't need atm, but keeps quite a couple possibilities open.

And digitizing old videos you'll only find in horrible quality on Youtube is also seriously awesome. If you need a quality piece of investion, go get a Hauppauge device - it's worth it!


What's NOT a grind game

I'm recently a bit pissed off cause some people round there call my beloved Titan Quest a "grind game". This is so damn wrong and fortifies even further my assumption that they don't want to say that Titan Quest sucks, that they are bad at it, can't see that grinding is totally useless in this game. Titan Quest takes leveling, unlike it's spiritual father, Diablo II, as something you can do while while solving it's quest. You actually never need to repeat an area again unless you haven't put your into boss quest and need better equipment. You can go through the entire game this way and there's never ever a need to go back. Sure, certain builds WILL require good equip, but it's really a viable idea, you just don't need special equipment. It's a bit different on hire difficulties, as drops and possible power within increase rapidly as well enemy strength. But even in such a situation, you can simply experiment with skill resets and such with needing to senselessly kill monsters for xp - if your skill selection just sucks, you won't be able survive any later gameplay, so grinding really doesn't give you anything in Titan Quest. If you're playing it like WoW, you should probably go back to there. It focusses on character development, gameplay with assembled skill sets and watching awesomely looking landscapes while clubbing heads off chests. This is Titan Quest, dudes! No grinding, no monster spawners, just what makes an action RPG fun - challenging interesting enemies and experimenting with character builds.

I can't say how annoyed I am of those idiots. Seriously, they don't even know their own slang. Especially when considering their usual activity of doing the stuff they criticize Titan Quest with. That's like political backdoor murdering.


Remember the old trash

I'm stunned how well I can remember my old ascii raytracer - I was afraid I couldn't remember it's concept, but it's surprisingly simply once you laid some simplifying tools. And geez - waht a horrible mess of bad OOP code, I really didn't knew how to design good back then. Whatever. I think I can boost a lot of performance out of it using multithreading. Raytracing in general profits extremely from parallel execution since every pixel will theoretically have it's own, completely independent rendering process. I guess I'll design a simple task scheduler based on a set amount of threads working on as many parellel tasks as possible. And I'm glad that SDL supports threads with ease. I'm also surprised how simply SDL seems compared to what I was I experienced while working on the renderer. Makes me glad that it's still absolutely usable and totally enough for my needs. It's virtually to use for any kind of custom media software: renderers, games, synthesizers, media player, visualizers and whatever not. I'm still happy that I once learned to know it better and improve my knowledge about this stuff.

A magic system for a video game

I really recommend reading Wikipedia's articel on paranormal Magic if you like amusing yourself with stupid assumptions of other peoples. I laughed quite a few times and got some inspiration for magic systems in video games (though this article provides a better general idea source). However, it's still more interesting to take other fictional magic thingies as inspiration. I'm fascinated with Eternal Darkness' rune circle use as well as with Arx Fatalis gesture-based input. Both don't provide quick casting system but require significant delay. between casting and affecting. I simply had to use them as inspiration and build a quite complex and "growable" system of combinable rune circle requiring difficult to gather and time-consuming to cast spells the use can systematically create without any spell-specific knowledge. Just google for Eternal Darkness' spell system, you'll see that it bases on primitive sentence construction like "Chattur'gha absorb self" to transfer life energy from the goddess Chattur'gha to yourself. So it's seperated into the goddess to get power from, the action to do and the action target. Three runes and an additional one to power up the effect. The bigger rune circle you can get, the power up runes you can put in and the runes you get the more different spells you can cast - simple! Using this as a base for ALL magic done in the entire game universe, I designed several circle types of fixed size which can be used improve certain spell parts (action effect, spell power and target count etc) and chain them to provide parallel effects like absorbing health from an enemy and giving it to you. To cast the spells you'll need a lot more space than a single simple circle and (depending on how big and complex the spell is) also more room. This makes it impossible to cast massive spells in small areas and forces you to prepare yourself when focussing on magic (as opposed to simply bashing them to ground with a club or so). I like the picture of mage characters waiting for their spells to charge their hands for a set amount of fireballs they'll have to watch out for. This puts magic on the same preperation level as guns/bows (ammunition and arrows) or melee weapons (durability and sharpness) and won't break up the balance for dungeons and longer adventures in dangerous areas. So, my gameplay concept finally found another important component. Yep, I think this is a good balance to base on. Only thing I worry about is how to exactly cast them. I could use premade symbols of all the runes you have you can then click-combine in a special interface while be able move around. You can access premade spell combinations which automatically run along their runes components and circle lines until it's done (providing there's enough room to cast it, breaking the spell if even a single map tile blocks the auto-drawn spell casting area. I also love the idea that larger circles have a larger you can move in and are able use the circle's inside and outside as target elements. Imagine you casting a heal circle while the end boss comes to close, making you run away and he getting heal inside the circle cause you left it out of fear. Awesome possibility! This should creep out players in certain situations I guess...


A fifo gun

Yep, you heard right. I kind of used the principles of a fifo stack for a gun model. If you remember the nearly-pinfired cartridge model still needing a gun to shoot it as thought, this is what makes it possible to have some more room for alternative feeding systems. I've always made single-shot lego guns from the beginning and was never able to fully realize a system with more than one shot without merging them into one with a single grip and multiple triggers. When I was thinking about how to design it this time, I remembered an early concept designed while I attended a manga convention. It based on the idea of directly combining a magazine tube with the chamber. Each shot would simply eject the cartridge and re-feed it from behind. This designes requires a big spring and I was never able to make good use of springs in any model. However, I got a good idea how to get rid of that damn spring! The solution is quite simple: a magazine tube with a fixed set of included cartridges that do not change in number. The first cartridge is always the one getting triggered, becoming empty and not of use anymore. To reload, the tube has two spring-powered flaps of which one will let slide cartridges in and the other out. If the whole magazine is filled, pushing new cartridges in pop out the cartridge at the other end - like a fifo stack! Well yeah, this doesn't make the most awesome and ergonomic gun (see, holding the gun makes 1 hand used, pushing a second and someone you also need to catch the empty cartriged from the other side). Anyway, it is a huge improvement over always needing to re-chamber! Using placeholders you can also accelerate the loading and so on. Even better, the circumstance that I always need to recharge cartridges after a few shots and refill chambers and storages later will profits from this because I don't to hold a shitload of them. I can simply recharge the last dropped cartridge and repeat for each cartridges without piling them up seperately from the gun itself. There are of course drawbacks. You either always need a seperate cartridge lying around to rotate the cartridge or simply use your fingers (though both are acceptable compared to the previous situation...). Also, the flaps are rather questionable in functiona because they need room to expand inwards/outward at the same time, moving all included cartriges towards the muzzle and back later. I can't guarentee that all will be re-chambered in only two moves, but those two moves are still more comftable than that damn break-action. Shouldn't harm to test it out, I can still alter the chambering as much as I want because this new triggering system requires only a compact rectangular block to work. Everything else is fantasy and design quality.

Hm. This would mark a great success in my design! I gotta start right now, so to have one ready this weekend... And I even have to take pictures of the last one! Damnit.

Calming down

I think I've overcome my yesterdayish uncertain confusion. Seperating anger about something different from the fact that commercial work using those "agile development" methods is a bit uncertain, I rather see the problems as not knowing exactly how all things should turn out and run. And well, I'm just a rookie at all and come there to help them working on their products using my study knowledge. Whatever, this makes me weird thinking about it in my head, better move all not yet researched stuff he mentioned and wait for it going to run the next weeks. However, they really seem to know what's easier for a student when "migrating" into a company's structure and I really shouldn't bother about it. I mean it's a supervised acitivity and it'll always be until I'm an actual part of the team. Nothing to worry about, just something new to me in this format.


Got a job!

Yep, I got a student job. Or atleast I'll get my contract next week with around 400€/600€ per month (depending on how many hours I want to spend, but I guess I'll try to maximize the time). It's that Embedded Linux development I explained a bunch of posts earlier and I finally got some more infos about how it's going, what they are developing and on which platform and such things. I'll have to read and test a lot. I hope when this is done and everything went out right (and they appreciated the work I'm doing), there'll be more interesting tasks like porting from code the old platform and such. But I have to say I'm a bit disappointed by how few infos I got about how they work, what their guidelines are etc, etc. Or maybe I just don't realize them. But from a business point of view I can't say that they did something wrong. I'll probably get all the infos I want/need when signing my contract, getting a desk and such things. It's simply not a good idea to pump out all "secrets" when not having you in their boat. Still, I don't think I'll do anything there I did before in this job. Well, it's not assurable cause it'll for the first times be more about those time-consuming things like testing, benchmarking and migrating from one tool chain to another. But well, I don't think this will take so much time... It's so completely different from my custom goals before, I shouldn't take this too much like how I tackled projects before, or atleast see it task-oriented. They use Scrum - I once used with a three-man student project and ended up witH doing most of the tasks alone and nobody else writing anything. So I believe I'll get to see how a "real" Scrum team works and be a part of it. It's all a lot of different and kinda new stuff and I have to chew on this a few days I think. But the cool thing is that this a job I get money for and only the time I really work on it. And I also won't be able to work on it at home due to the lack of hardware - which's important to me because I very often had to work at home on stuff other people had to do but failed at it. So the task itself - getting development on the new platform running - is good for not forcing to read through documentations all day long. This can only be a good thing I guess, so I can still have my uni assignments as well as personal projects if there's time for them.

Hm, this is totally new to me. I have to get used to it but not thinking about it too much. I mean I won't get paid for doing this at home or university, I get paid for beeing there for a set amount of time and pushing stuff forward during this. I had so bad experiences with my vocational training, I uncertain about what will happen and such. It's weird cause it was all so informal and practice-oriented. They talked a lot, I've listened to them and well - I didn't have to say anything because it was all rather clear and simple. Like I'm developing my programs - analysing the target platform, getting libraries and necessary tools, step-by-step developing with over-time improvement and that's it. It's not a fixed pattern all have to follow, not a strict plan but a lot of "yeah, we're currently it like that at the moment and we'd like to know how we can continue it here".

I don't know. I could talk all day long about how strange I find this, but that wouldn't result in any content. And I also don't think that this brings any good because I should rather learn seperating work and private projects instead. That's actually not easy on my side! Especially cause I'm so damn unexperienced with all this stuff. Well, actually I'm not, but I feel like that. Must be the whole frame around it, that "commercial flair" as well as the team aspect apart from the technical side, which's definitely what they want me to can and I provide. Geez, why am I so nervous about it. It's just a job, nothing that should cause me to alarm all my drama senses... Guess I'm making elephants out of gnats. I wouldn't have gotten this job out of nowhere if I wouldn't be able to bear it. He still almost "hired" me, so I shouldn't think too much about it...


Number systems

I always found it fascinating to see other cultures number systems or, on a more larger scale, how they've done their calculations on general. Digit grouping is also a part of this, as it sometimes shows how the culture used numbers in earlier times when they developed it. I have, like probably all other western people, learned to use the decimal system and later binary, hexadecimal and actual, too. But those are all based on the positional notation, which' essentially only one number system. I'm looking a bit forward to also implementing the same set of functions for addition-based systems (sign-value notation) to round up the completeness of the system. Though there are some special rules depending on the notation (for example subtraction in case of roman numbers), I shouldn't be a problem to integrate it somehow. However, I'll rewrite my current string function naming convention to resemble this newly acquired knowledge of mine. I low implementing interesting number things! Guess I'm just a disguised numerical mathematician deep down in my hear...
It's an exceptionally awesome feeling if you can define number systems based on random sequential character values. Now I can successfully decode and write string number formats for any base with all characters I want! Though I had to drop thousands seperators due to necessary format complexity (I preffered the small, waitable code over a plethora of special case ifs), it's very comftable. You can trigger sign fraction and integer on/off and optional, set a minimum/maximum digit count, etc, etc... The resulting format is a struct for storing the integer part, fraction, whether it's negative or not as well as the fraction part's divider value based on the given base when parsing (also made up of sub structs). It surely requires more memory, but the benefit of converting to any possible in/out format is unbeatable. Really lovely, now I only have to write additional functions for converting to standard types, rounding and guessing the length necessary to convert back to string. I'm quite proud of this I have to say... I love when things work fine and for all possible cases - something I've definitely reached here. But hm, guessing the resulting print length will be a bit more tricky this time. Especially because I'd need to number format iself to temporarily store it, which's digit count depends very much on the chosen base, hm... Or I cut out the digit count and measure this by the resulting pointer delta... Maybe I should also write an additional function for reading digit grouping like using zthe thousands operator. Step by step, function by function.


Fucking piece of shit

GOD, is there ANY well-designed driver/firmware combination on the NXT that does NOT suck balls?


Strip that OSEK

I took some time to once again working a bit with nxtOSEK and think it somehow adds annoying layers I'd currently not want to have. Sure, multithreading blabla and so on, but since I like to invent my own mechanics for that (which's actually quite simple for certain realtime tasks), I'd like to get rid of the whole OSEK wrap-around, you know. I know there's ecrobot and as I believe it's surely completely independent from it. Guess leJOS isn't base on OSEK, so studying it's source is probably the best idea to find out how they're compiling it. I want to find it out. In theory, I'd only need to create some objects files and create executable the modified firmware can read. I remember reading something about a while ago... on the page where they're offering the modified firmware I think. Should be my next stop, eh?



Ignoring to the pun of breaking my current Minecraft addition with another craft, I decided to read atleast one book by H. P. Lovecraft. I got infected with this a while ago when I was reading more about the Cthulhu Mythos on Wikipedia, having seen an Eternal Darkness speedrun before. And it happened again in another speedrun, this time Castlevania 64, that they used one of Lovecraft fictional objects, the Necronimicon, in the game's intro sequence. Both times go well together with today, where I finally informed myself about Lovecraft in detail. I'm especially pleased with a site enabling more me to read some of his writings. He has clear and pleasing style with a syntax I coming close to what I'd like when dwelling into such areas. However, I prefer to hold and feel writings in my hand rather then wasting energy with a running computer. Additionally, I love reading fantastic creep during train travels, so this rounds up parts of my student's day-to-day routine.

Seem from out of my person dust bubble, it's surprising but also a logic consequence that I want to read atleast a part of his work. I'm always creeped by the sound and graphics of horror movies and horror game's interfaction, additionally. Though I have a few creepy games and movies I actually enjoy while they are a total horror to all the others watching those moving rotating my intestines. I have a few theories why it is like that, but one thing always finding it's way in is the question of format. You see, a typical horror movie is presented with a strong focus on horrifying visuals and ways to let you be hopelessly isolated with the movie's ongoing plot. There's no objective description, no observation about what's going on while leaving audiovisual celebration aside. That said, I like descriptive creep staying neutral. No silly attempts to drama attention or whatever else ugliness. Just a good, reader-weighted neutral text you can think and dream about. Nothing else. From what I've read so far, Lovecraft is a lovely candidate. I like his writing style and also the idea of letting come the fear remotely, sometimes way back in history. And for sure am I interested in reading more about what roles play Cthulu and the Necronomicon in his stories. It's simply the stuff that let me discover him, so I'm excited to finally find a copy I deem aquisition-worthy.

So I hope my feets start moving toward the next book store with non-translated Englisch books. I don't want a wasted German translation.

Why Minecraft multiplayer sucks

I didn't try to hard to have fun with multiplayer in Minecraft, but even if I would, there wouldn't be much joy to get. I played Minecraft online before the monsters appeared and it was quite a "simple" experience: walking around, building stuff and sometimes watching other people's doodads. Yesterday I decided to give a new try again, choosing a griefer-less server with some kind of smaller community or active number of members. It was quite a cool concept: observe the global map online, make your own residence nobody except you could alter, etc, etc. Too bad they had monster on. Morning came slowly and I've chosen a nice, remote spot for my tower to build. However, I wasn't able to gather any ressource for a long while - no more trees, no coal, no clay, no iron, no anything! Someone totally raided all ressources deep down and on the surface. Absolutely annoying if you ask me. But I tried and tried and wanted atleast to create such residences that prevent griefing. Yeah, too bad you need "money" for that and that no new player got any money but a stupidly small amount of it. The map is SO FUCKING BIG and they don't let me create blocks for safely build? What a bunch of dicks, seriously. Admins and long-lasting player do of couse have a shitload of money to make they giant buildings and whatever. However, they have also a shop system you can use to sell and buy stuff. Let's just say they just sell, which is of course a serious problem in any economy.

Personally, this reflects a problem we have everywhere in the world and that doesn't change at all. This made me think today I and designed a small, balancing economy that's based on how many players are on the server and how big the gap between poor and rich was chosen by the founder. Very simple and should work, mostly like a ideal communist economy. Too bad nobody will probably implement it and you'll still not be able to gather any stuff on your own because nothing exists under the earth anymore. Or they make they stupid modifications and still call it communism, which's the point where some typical problems in such politics come from. I like how it's done in Startrek, where they just don't have any money but work on making themselfs better humans by default. Good idea, but still future music.


Sometimes I think that having only lofi hardware in younger years makes you more of a lofi dude later. Well, I'm glad I HAD consoles and a gameboy before, otherwise I'd probably be quite a sucker at I'm currently right now. I'd probably do something else then, too, so I shouldn't think too hard about it...

Do not stream

I'll drop this stream concept and a provide a conventional function syntax instead. That doesn't mean that I can't use it for streaming from memory, but I once again I started seeing that immense complexity in interface and access... Just not worth doing it. Simple code, simple functions. It's not a good design to add additional layers making code and execution more troublesome. This is also what's bugging me about my allocator model because it's just no the type code I like to see. I have so many ideas that suit awesome in OOP environments, but are complete garbage in usage and extremely simple in implementation. Also, I have some different plans for what kind of allocation is the best for my needs. There's a single design I can rely on and everything else can be done by the OS. I mean there are reasons for why they are made and why you can use their provided functions as much as you wish. However, the NXT still has no directly controllable dynamic memory. Atleast I couldn't find any detailed descriptions about how it is implemented. But I can only guess, so I'll make my concept true and design a block-based memory allocator as I described in a earlier blog entry. I can think of some nice things using that including a completely program reboot while it's running to clean up all the mess it started and get some new test runs without always needing to reboot the brick.

Anyway, I'm glad I dropped this idea and went over to simpler things in terms of layering. I'm also close to removing my serialization/deserialization system. I mean it has it's quite nice advantages, yes, but I don't think I'd like to maintain it or even implement a single function using it... What an irony. Me the one who dislikes OOP creates concepts that only really work in OOP. Too bad that OOP sucks balls (hm, balls...).


Once I had demo CD of a game called "Tzar" which was a dark age strategy game, like Age of Empires and other during that time. I didn't have as much features and control options or even units as Age of Empires, but you could summon creatures, collect items to pimp special units, level up, conquer hell portals and summon unearthen creatures to roll over your enemies. It was really nice game with a strange aspect ratio but good music themes and graphics. I got the full version at christmas, played it very, very long and some borrowed it to someone else. That's also the last I can remember and I think this dick didn't give it back. However, long time I was looking for but never found it again as CD or even cracked download version. Out of interest if I can find it now, I stumbled upon a site called tzarlive.com whichs offer a download link to registered members. So yeah, right now I'm sitting here waiting for the download to finish... It's a really a lovely game. It's not necessarily a big strategy game, but had all elements I needed to have fun with strategy games. The enemy AI is rather poor and predictable, but it simply makes fun bashing them with your dragons or skeletons. Reminds me of how fascinated I am with Paraworld, which's also a rather unknown game, only loved by a few person though it has the best overview-keeping features ever seen in the strategy games I've played.

Too bad that those two games never reached the star state they deserve. I don't like many other strategy games out there.


Streaming and iterating

During my usual thoughts about the current modules I'm working on, I've come to a kind of stunning conclusion. First of all, I generalized number parsing into a single function using a settings structure, so that some additional ones can craft a binary value of it. I wondered whether it'd be useful to only accept null-terminated strings as input and couldn't decide whether to do this or made it to some kind of streaming function, returning the first non-number position in the string. And well, this made me realize that it'd be much better to provide a set of in/out streaming string functions instead of lame, limited one. Sure, this takes a lot more infrastructure, but is extremely compact in footprint and provides a very simple interface. So I took it further and made a concept of a streaming system that provides an interface-based access to whatever logic is behind the streaming. And that is where the conclusion kicked in: What would happen, if I extend the stream to also provide positioning? How can one decide what address model it takes for the stuff behind? Can't I also realize fifo and lifo stacks as well as arrays and other types with it? So my conclusion is that streaming itself is only a slightly different logic compared to iterators, only that they provide a specialized interface for it. Sure, I had was the possibility to add this, too. But I still believe it's not a good idea to use iterators for a generalization of lists, arrays and the like. So I sticked with a more limited concept of having a memory streamer, a file streamer and lisstreamer, building an abstract stream out of multiple ones. I can't think of any other idea right now, but I guess I don't need something else for this. A stream is not a list or hash array or whatever. It's thought as binary flow, having whatever data in which's is formed to elements when it's read. Totally different to iterator-supported storages which are made of distinct elements of size irrelevant for the iterator user. But it's still creepy how connected all those generalized data storage interfaces are. I'm sure one day someone will start to merge them all. The day when certain things don't matter anymore.

Number conversion

I always think of string-to-num and num-to-string conversion as sophisticated pieces of code that's not always easy to solve. Strings to integers is simple, as you only need to add and multiplicate. Integers becomes a more math intensive, but it's still very easy to do. But how to do this using floats? That always wondered me. I took a look at an dtoa implementation and geez, this is really creepy lowlevel stuff. Creepy in a way, that there must some simpler and less code-heavy solution. And well, the solution is really simple and I wonder why I didn't notice it before today: split int and fraction part, concatenate with a decimal point - that's all. Equally simple is it to read floats by simply taking two ints and making fraction parts out of them. Very simple I have to say, indeed! So no bitpushing is necessary to archieve it. Did I say I like small code? I like small code.


Fractal Image Compression

I stumbled a simple but interesting of compresssing images: detecting fractal shapes. That's for sure not the cleverest idea due to possibly highly unique image content. But I think the concept bears a really great amount of potential, especially when it doesn't only try to compress pixel blocks, but also gradients and color flow, effectively as lossy compression by ignoring a few of the original details. I might give this a try and experiment using my new toolkit. Array and vector operations are quite easy to do with my macro set, so this shouldn't a problem.


After playing a few old games and reprogramming some of ITK's existing functions, I found it more interesting to design on a new LEGO gun model and was surprisingly successful in terms of design. The current bullet design is still quiet efficient and also resilient towards non-penetrative trigger attempts. This means that you'll have to overcome in a certain treshold of force, resetting the pin position automatically when reduce the pressure. A really useful property I didn't notice before. And it's that property enabling me to use a trigger mechanism without a rubber-powered hammer or striker. My previous model (which I still haven't posted here, but really need to) has two firing pins you could cock together or seperately, powering the projeticle triggering. However, the design is bulky and requires a greater deal of force and rubber band degrading (especially in terms of elasticity). Furthermore, I have to switch parts of bullets regularly because of it's quickly deformed projectile lock (you know, those little grey/blue connectors with one beam width and a small flat ring on top - I need the ring for locking). So it's really not an optimal solution for all terms. My new variant works be trapsorting trigger force from 0° to 90° using racks with a direction inversion in the middle. This way I can pull the trigger (which is buffered by some random Lego spring for durability reasons) and unlock the projectile holder in the same motion. You only need to overcome the required force, which's not much compared to other bullets. The opposite of such a trigger having a force to overcome is called "Stecher" in German, I couldn't find the correct English for this word. Anyway, this designs enables to make the whole gun smaller and more compact in design. I'll also avoid re-using the break-action design since LEGO parts don't fit together so strongly if the barrels are a bit longer. So, my current bullet set it is QUITE long, which means that I would have to create a more powerful and version of the current break-action lock I'm using now. The lock is good but heavy and doesn't allow stuff on top of the barrel like scopes or rails and so on. Instead, I've designed a pull-back action, sliding a combined half chamber out of the barrel and enabling one to reload with breaking the action or taking eyes from sight. This goes well together with the necessary bullet triggering from the side (the bullet is a bit like a pin fire design, just more compact and not raising from the bullet body) and I only need a gap under the slide chamber to trigger it. It'll again be a double-barrel design, making the slide more easy to stabilize. And this time I've also found a good solution for triggers one after another, not in a row like in the previous model. I always disliked that they were side-by-side but never found a way around the construction due to overall bulkyness. So the new model can solve this problem, atleast without troubling design simplicty. Will, internally, probably resemble a crossbow with some nicer gun-like extensions. Hm, what do have then... two triggers, two barrels, a sliding chamber, much room for additional stuff... Yeah, I think this could be a definite improvement. All in all I believe the triggering will feel very godd, similar to my old muzzle-loading pumpgun, essential the second design I made. Hm, seems I have quite some history in those things! I should assemble it all to a timeline or so, showing the hurdles, improvements and drawbacks I archieved. Would make an interesting thing to look at for those reading my blog (and that's probably everyone except me when prove-reading).

Hey, this means there's still for a scope or so. Also, this means I need more LEGOs to buy if I don't want to disassemble my current model... Hm, I should atleast make some photo and a covering description of it. Besides the fact that I alreay have a better cartridge design, it has many good mechanics I could use for the new model. Especially when it comes to aiming, I still have to do a lot, making a resuable sight and so on. Yeah, the new model will hopefully bring the room for more options. I tried to archieve this in the last one, but neither worked it out due to the massive break lock nor made it sense to add an additional rail, aiming over the effective range. For the next sight, there should be a generic rail system for mounting sight parts and other stuff. I believe a set of simple beams will be sufficient for my needs. Yep, seems it's all sorted out then... Oh and the stock. I need to do something about the stocks. I used a really big one in last model which occupied almost all of my red beams... Though there's a storage for up to four cartridges, it's just too big and also required a appropriate mechanics for locking the storage. I don't deem this effective anymore, it'd be easier to clip them on the side of a stock. Yeah, what about combining the stock/grip with the rail system? I believe this could turn out totally cool, enabling to build a grip/stock once and then just adding it on demand... Let's see what's possible.