CoRe Technology Initiative

Bringing together so many diverse populations of the multiverse causes some very strange dilemmas. Little can be assumed as ‘normal’ between race or even culture, militaristic or fighting dependencies among those topics. As a result, there is a shortage in some fields as to what is a Marshalship ‘standard’ to solve any giving dilemma in gearing.

Fairly recently was an occurrence that pointed out one such lack. The current standard H.E.V. (Hazardous Environment Suit) was designed around the concept of exploration and scientific study. Unfortunately, when placed into combat, it doesn’t live up to expectations. The mask is too strongly fitted, shattering under any real pressure, and the bulk of the suit itself restrains any real sense of mobility.

The CCAM (Complete Coverage and Monitoring) Rethreader Unit was designed as a compromise to this, and was later given further functionality. The unit itself is a belt, the buckle chamber being the storage space for the nano-threaders that do a bulk of the work, as well as the Lycra mixture which serves as the main material.

When activated, either via datapad or switch along the belt’s backing, the unit will enter one of a few customizable modes, threading an entire body glove out of the storage unit over the user regardless of prior clothing. The main purpose of the created suit is biological protection. The material threaded will protect against skin contact drugs or gases, radiation, and most things of that sort. Likewise, one of its modes may be threaded with a hood capable of fitting to the standard Marshalship re-breather unit, should full closure be deemed necessary. It does lose some functionality when compared to a standard H.E.V. unit, the two biggest concerns being that is does not have the necessary complexity to regulate temperature inside, nor does it have the hardware capable for emergency oxygen storage.

Its perks, however, are enough to justify its use. First off, it is extremely unrestricted, hindering combat mobility by almost nothing. Second, the very nature of how the suit creates itself also allows it to also repair itself. When a breach in the suit’s lining is detected, the same threaders that constructed it will re-weave the wounded area. This means suits will only have a narrow window of potential contamination, should attackers try to cause some trap around chemical exposure. Related to this is the perk of customizability.

****The image below shows three adaptations: the volunteer in their casual attire , one of a robe woven by the rethreader unit over her clothing, and one of a body glove fitted beneath, hardly visible except on exposed areas****

Customization allows the unit to remain ‘hidden’ against potential attackers. It can remain in a passive mode, unwoven, or programmed to weave as the users usual clothing, or remain as an active body glove beneath said clothing constantly. All up to the individual owner. Likewise, should the unit ever be compromised? It has a defensive measure. Unless the remote trigger is disabled, it can enter emergency mode via owner’s datapad, threading to entangle any would-be-thieves.

A final functionality was added to the unit after further discussion. The Marshalship currently has no passive monitoring system for combatants on the field. Teams rely on their own communication and any medic’s perceptions to have their injuries spotted and treated with the necessary expediency. A realization occurs with that thought, that this suit already encompasses an individual, and likewise is able to detect fractures or damage to its structure. Therefore, a medic with the capability to monitor suits is very close to monitoring every individual.

As a result of this thinking, a transmission unit has been fitted to the belt’s hardware, and I’ve created a datapad UI to go along with it. The medic with the software will receive a verbal warning (prioritized by severity of damage point, if multiple come in at once) of whose suit has been breached, and if they have the moment to do so mid-combat, also have the ability to then check visual specifics with a read out on their screen.

Everyone will be encouraged to carry one of these belts. As mentioned, every precaution necessary has been taken to try and ensure that every individual’s style or comfort has been accounted for, even visually, and not only will it offer you protection from some often unseen threats, but it will also make your medic’s job easier, ensuring they can treat you and others with better efficiency and awareness.

After recent interception of a Void fleet by the Marshalship, a boarding team was able to commandeer The Eye of Multiplicity. This vessel, the ship of Damon Decantes, has given us plenty of insight into the workings of his creations and technology. Given his ability not only to multiply, but for each multiple to make full use of an individual’s productivity, it’s likely that focusing on deciphering such technology will extremely productive in turn, simply from frequency of exposure.

That thought in mind, I’ve been working to create an interpreter for the primary language used on his ship. From what I’ve been able to deduce, it’s design is meant to be implemented as a simple but efficient functional language, and have been able to create an interpreter within one of our own in turn.

Basic Values thus far have been defined by the following.

i, j, k ∈ INT ::= ...|-2|-1|0|1|2|...

b       ∈ BOOL::= True|False

V, W    ∈ VAL ::= ()| [] | i | b | V : W | (V1, ..., Vn) | \ (x1, ..., xn) -> M

And Expression syntax has been given below.

x, y, z ∈ VAR ::= ...| x | y | z | ... | temp | ...
M, N, P ∈ EXP ::= V | x
                | not M | M&&N | M || N
                | M==N | M+N | M*N |
                | nil? M | head M | tail M | M : N
                | MN | (M1, ..., Mn)
                | if M then N else P
                | let (x1, ..., xn) = M in N

Given this expression syntax, there must also be some semblance of constraint rules, otherwise we can come up with garbage expressions (a head or tail operator on something other than a list type, for example).  Said constraints are upheld within the interpreter with an error wrapper. I’ll be looking to further this until I’ve encompassed the full language. Here is the working application thus far.

Interpreter Source

Copy of a Void intelligence-protection protocol analysis, which wipes information from their systems upon activation. This will be followed by the study of our own counter-measures to prevent it in the future.

Subject: SnB222 ‘Slash and Burn’
Purpose: Forced system information wipe.
Author: Damon Decantes

On our prior assignment at an Earth Analogue, the Blaze of Glory was exposed to both figureheads of the Void operations there. One, Damon Decantes, was revealed as the author of the SnB222 data wipe algorithm we’ve encountered twice on our most recent mission on the world of Pokemon. It would be important to analyze the figure to take an adequate guess as to how to decipher current versions and consider future iterations.

Damon was anything but subtle in our encounter with him. In our final confrontation on the earth analogue, we made an attempt to contact the Renraku Vice President who supposedly controlled the life of our hostages, but instead found Damon on the other end. He didn’t even bother hiding the fact that the had offed the VP, and cut right to the chase – an exchange of prisoners on the promise of a show down. He was eager for a challenge. Given his unique ability to create clones of himself, his tactics and mindset were purely on overwhelming and overpowering. This theme continues in SnD222.

The protocol starts with a mapping of local file structure, sorting to create a minimum spanning tree of referenced memory-addresses, prioritizing full wipe on spaces with /actual/ information on the storage space. This is accomplished by means of a reverse-delete algorithm such that:

This is preferred for the case of SnB222 because it returns the edges in decreasing order of weight, allowing instant access to the next smallest node within memory address. A node may become corrupt by matter of deleting a referencing node, therefor, it becomes more efficient to delete smaller nodes first with the possibility that a larger will follow with it than vice-verse. Now, the kicker to the protocol is two features. First, the wipe is a strong balance of both coverage and thoroughness. Several instances of the wipe are opened simultaneously, running in parallel threading on alternating nodes, eventually re-wiping the same space as their partner instances, but in a different formatting. While something like a clean slate of logical 0’s is a quick wipe, it doesn’t ensure irreversibility of the deletion from analysis. Only with several passes is the ensured effect accomplished. Between the two separate times we’ve run into this protocol patterns seem to have matched different subsets of the following standard cases. In the case of ‘user defined’, his defined wipe sequence has remained ‘222’.

The second kicker is the real trouble – the protocol, once substantiated, becomes malicious. That is to say, it is not ceased from standard system control. In a way, when activated, the Void are choosing to run something closer to a virus than a tool on their systems. There is no direct method cease it once it has begun. In future strains, we can expect to see this control method altered to prevent exact-counter matching, and likewise, different wipe sequences further randomized.

The question becomes, now, how to create a follow-up that is fairly reliable, such that it can react to differences between different strains and lock down the protocol during infiltration missions. The baseline thoughts should be broken into several pieces:

1) One of SnB222’s biggest strengths is also its biggest weakness. Given its malicious state, while independent from system run time, this also means it has no forcible interaction with a system’s operating system. Thus, it is unable to reach and priority queue for CPU time, and as done in the past, it is possible to simply ‘bog’ a system down such that SnB222 is unable to find any available system resources for its computations. First step for counter-designs will be to create a reliable, reusable application if garbage injection that seeks to take specified resources SnB tends to take hold over when left unhindered, allowing further time for data recovery before it extends.

2) The means of ceasing SnB222 in the prior two encounters has been the following. Start in a random place on file structure, and begin removing references to other nodes, storing local copy of these references unreachable by the protocol. Continue to do so until system shows no further activity, proving you’ve ‘cut off’ the protocol from any reachable nodes, making it believe that is had finished its deletion process. From there, re-compile references on local copy and retrieve your pieces of information. Working this process by hand, while effective, can be vastly improved by an automated process that does this work for us. The issues there become several fold in turn.
-Creating a stable method for recognizing that your random node of information has not already been wiped, and therefor, is already within the bounds of the contaminated structure.
-Choosing a proper graph-traversal algorithm for the memory space using the proper heuristics. That is, on SnB’s side of the equation, it is converting smaller nodes first. Likewise, we would rather favor an algorithm that maps the memory space as quickly as possible, regardless of shortest-path.
-Optimization could come in the form of: Creating a counter-conversion system such that, rather than cutting a node off from the memory space from SnB, we instead turn it into an active reactive-agent such that any tampering of its data responds by attacking that particular thread of SnB, cutting its active sweepers, slowly the process even further (and eventually eliminating it). Conversion system would have to be prepared to handle changing strains of SnB222.

-Crono Arinborn, discussion to be furthered as project process continues.

Submission Process Override: Rank B*, immediate consideration to Marshalship directive.

Design and Prototype and all rights: Cadet Shaila Swiftblade, Blaze of Glory

Development of mechanical combatants or supplements is always a weighted scale of cost against efficiency, on every level. By virtue of design, even cheap droids or mechs are surprisingly resilient to standard tactics, but come at the cost of unique flaws to exploit. Specifically, exposed and improperly insulated systems can be abused by mechanisms of short circuiting or overcharging them. Is there a good example of this? Several, actually, here below is certainly the most common.

The T-800 series in production by the Void is a terrifying creation capable of vicious results, yet its primary weakness in defense is obvious. Because of units like these, the Blaze of Glory’s crafty gunsmith has created the solution: the Electro Blaster.

The goal of the Electro Blaster is to fire a chain of electricity upon the target, overloading it or shocking it appropriately. Its levels are adjustable, leaving it a versatile weapon in every nature. To explain, it is specialized against mechanical units, but one can adjust the output such that it becomes a simple stun gun, or upped to shock humanoid foes with lethal force. The gun can fire a constant stream, though it will have limitations of overheating in overuse under such conditions, but this is still inherently a feature as it leaves discretion of emergency up to the user. To ensure control of the stream itself, the electricity dispersed flows down a laser projection that contains the flow completely and safely. On top of this, a feature of the firing mechanism allows this laser projection to exit prior to releasing the electricity, such that one can use it as an aiming mechanism as well. Often the overall effect would be fairly limited, but this device has been tweaked and tampered with such precision that it becomes a very reliable medium-ranged weapon choice.

Further details can be accessed within attached design specifications. With those in mind, it should be fairly obvious why this schematic should become an added issue to the Marshalship standard. All review and consideration is appreciated. Further comments can be forwarded to designer and crafter, Cadet Shaila Swiftblade.

Despite advancements in domestication, there is only so much one can do (or would even want to do) in terms of balancing convenience with proper care for live stock. Ideally, in a setting full of animals, you’d like to give them as much freedom as possible, but practicality dictates just how much freedom you can give them. The more room you give them, the harder it becomes to round them up. A specific example was brought to my attention when trying to handle poultry, specifically, chickens, and trying to gather them individually. The result? This device.

Before I begin, I would like to give proper credit where credit is due, as the basis of this technology came from the Blaze of Glory’s Research and Development specialist Doctor Gordon Freeman. The details of his Gravity Gun are discussed here in his research.

Now, to clarify, this device is in fact a small gravity gun of similar creation. The beam shown above simply marks the aiming pathway, taking little part in the function itself. Once the target is apparent, the user can activate the gravity pull. However, this pull will only recognize and function on a very specific material. As the device is unable to draw on organic material, it instead targets this.

Given the bone-to-structure ratio of a chicken, the process of lifting and pulling one by its bone structure is a safe and uninvasive process. Given balance modifications, apart from visual, the chicken is unlikely to even notice this interference. Slowly, the chicken will be surely and safely within your grasp unharmed. This allows far less restrictions in terms of chicken coup size and placement.

As technology has continued to develop across the multiverse, we’ve seen an interesting flow of problems that arise in our way during development. Specifically, scaling projects to a micro scale, and eventually nano-scale, has presented a few problems to us. Its amazing to believe computational devices that used to fill entire rooms have been reduced and even out-performed by devices that fit in the palm of our hands. The concept of precision was the first struggle to overcome. In many cases of scaling down projects, the issue was no harder than a literal conversion of metrics to the smaller size, but how is the construction process then influenced by limited workspace? Luckily that is near a moot point given mass-production. If you can set up an automated system to create something once, such a replicator schema, then you can forever more repeat that process with little trouble beyond the initial difficulty.

But the true concern comes out when we try to increase the potential of the device or setup in question. If something becomes smaller, how then do we ensure it stays consistent or even increases performance over its larger, older counterpart? Simple – we improve the system of efficiency – but what does that mean?

On a computational level, that problem is solved through smart use of resources. Proper use of scheduling and processor time, avoiding things like idle locks and loops in computation, limiting background threading to necessity, and assuring smart placement of hardware vicinity is key. But on a resource level, this problem becomes a little more vague. What about physical performance issues? If, say, battery A is just smaller than battery B, is it possible to get something more from battery A? The honest answer is, of course, no. But that doesn’t stop us from trying to be creative. Rather than trying to do the impossible piece by piece, lets implement a better physical management of resources for the problems we’re trying to solve.

This sort of philosophy brought about the thought for the development of a kinetic-resource solution, the electromagnetic insulation sheen. The basic sense of the idea is as follows. The observation is made that auxiliary movement through any means – power armor, mechs, any such machine, has a fair amount of electrical current passing through it at any point in time. There also exists a means of creating force from this current without diminishing the bulk of its flow – that is, electromagnets. So if we have some kinetic motions that we want to spend conservatively on, why don’t we take advantage of this particular upside of our current?

The resulting creation is the electromagnetic sheen – the idea of withdrawing and routing the central current flow in a mechanical unit such that it can be directed to course through key points of the overlaying body body. This can be done through a means of insulated mesh between the computing and armor portions of the setup, or drawn into a more detailed and specific setup depending on your needs so long as you can separate the force resultant from the magnetic pulse such that you don’t do any internal damage to your unit as a result. By directing this to a central balance processor, you can replicate a thrust-like effect capable of compensating in lack of other resources.

Example of electromagnet placement within a human-shape overlay. Reversing pull between sides causes opposite shift for slowing and transitional kinetics.

So far I have a few different models for how this setup is created and used, so please forward any queries on more unique implementation to my attention and I can assist in coming up with a solution. Given time, my hope is to abstract this into a wider array of units that can be placed and even adapted onto current systems quickly and efficiently. In the long term, while recyclable resources are difficult in theory, I’d like to come up with further examples of this line of conservation on a hardware level.

While it is a bit of a delayed response, our last encounter with the Agamemnon brought  some interesting insight to my eyes. With the pair of the Blaze and Agamemnon being such comparable vessels, the point was stressed that a large part of the victory would lie in overall effeciency of resource usage, as shown by our swapping race to charge an assault and divert properly to shielding in response. Brute force of  technology has often compensated in the past in place of effeciency, but when we really need to start cautioning ourselves, the desire for a better system sparks.

With the assistance of a designated sensors operator in the flow of combat, several heuristics can be added to an encounter that will enable our shielding generators to predict and react to incoming fire. Basic operations breakdown revolves around the following.

public class ShieldingField{

    public ArrayList sensorarray;
    public Hash generator;
    public Hash pressurepoints;
    public ArrayList trajectories;
    public int assaultcount;
    public boolean combatstatus;
    public static final int RESETDELAY = 2;

    //Constructor method for field apparatus.
    public ShieldingField(){
        generator = System.import(BoG.System.genlist);
        sensorarray = System.import(BoG.System.sensor);
        assaultcount = 0;
        combatstatus = false;
        trajectories = ArrayList.new()
        pressurepoints = Hash.new()
    }

    //Finalize preparation and apply busy waiting.
    public static void main(String args[]){
        for (Iterator sense = sensorarray.iterator(); sense.hasNext();){
            assaultcount += sense.current.hostiles();
            trajectories.put(sense.current.coords());
        }
        //Ready status automatically when sensor verifies 1 or more hostiles.
        if (assaultcount > 0){
            combatstatus = true;
        }
        while (combatstatus = true){
            FieldShift();
            if assaultcount <= 0{
                combatstatus = false;
            }
        }
    }

    //FieldShift algorithm, allows for input of user-driven heuristics via
    //personal monitoring.
    public static void fieldShift(){
        Timer delay = Timer.new(); //Timer to track current point
        delay.start();
        for (PointListener listen = System.import(sensors.impact.coords(); listen.active()){
            pressurepoints.put(listen, coordinates);
        }
        for (point p in pressurepoints){
            if (p.impact() > threshold){
                p.orient();
                //Resource orientation function centered around point, dependant upon surrounding points.
            }
        }
        delay.end();
        //If point have been inactive for given delay period, release its resources.
        if (delay.time > RESETDELAY){
            p.releaseorient();
        }
    }

}

Loading this apparatus causes the shielding systems to fall into an infinite adjustment loop weighed against incoming impact points from hostile fire. An orientation function is applied wherein our combat database actively tries to match incoming sensor feed to storage past occurrences within. If this is unsuccessful, it falls back upon assumed trajectory of incoming fire, and if that proves a false assumption, it then finalizes its fallback on a reaction-based shifting placement of shielding strength. As a pressure point is struck with increasing impact, its individual priority field rises in turn and tries to verify a few key features about repeating strikes.

• Outside trajectory influence (change in aim or focus).
• Radius of fire per each source.
• Rate of fire per each source.

If a shielding function can verify these three features, it can adapt accordingly to future assaults before they even impact. Consider, for example, a pulsing photon cannon that fires once ever 2 seconds and strikes the shields two feet to the left from the original strike, then four, then six. How likely does it become, then, that the next shot will be eight feet from the original, two seconds later, with equal force as the last four? The answer is, very likely. Likely enough in fact that on average is becomes far more beneficial to lower shielding in all prior points, conserve energy for a 1.90 second downtime, and boost accordingly in the predicted location coming.

At first, allocating resources on shielding in a way that lowers others more on average than some might seem risky. Keep in mind, however, that if gain from correctly predicted assaults is high enough that it conserves a fair store of energy, the ‘low points’ are free to average themselves upwards in response, at times becoming even more stable than if the overall system was evenly distributed. If predictions for an incoming source do prove unreliable, a boolean marks the assumptions as unreliable and will default to even distribution. On top of that, when rate of fire vanishes for a specific period, trajectory assumptions will be reset to prepare for a new, unbiased location of assault.

Each verified source is tracked individually and when enough heuristics are proven reliable after the course of the conflict, they can be hashed and stored back to the combat database for use in a future encounter.

This process is, of course, not without its limitations or even its vulnerabilities. Its purpose is to mainly serve as an automated response to predictable fire. Erratic sources of fire such as mechs with humanoid capable variance  in their aim can abuse the system if they recognize the effect (though unlikely from a pilot’s perspective, an observed afterthought in analysis) more so than something like a flight-fighter stuck on line-passing manuevers. While no process is perfect, however, a system like this is likely to improve overall gain. In cover of the system’s weakness, as mentioned before, a sensor specialist giving a hand-sweep of all incoming inputs can filter and remove targets and sources that should be ignored, as well as offering usual hand-controlled division of resources during the flow.

I’ll be spending a chunk of our downtime running simulations of different vessels running this system against a wide assortment of scenarios before devoting any funds to implimenting the potential, but I’ll be demonstrating results as I go in the meantime.

Dimensional Case-Study: 574-DZ

Location Focus: Planet 0072

Status: Dimensional distortion present

Dimension 574-DZ was brought to the attention of the C.T.I. under Marshalship request for study of strange fluctuation feedback after routine stability scan in the area. After automated scouting vessels revealed little in terms of answers. the C.T.I. was asked to do a hand sweep of the planet in question. The following report is my humble assessment of the source of fluctuation as well as the issues surrounding it.

Upon arrival, 0072 showed immediate signs of prior habitation. The landing zone in question was a city near a coastline in terrible condition. From first glance, the area itself looked like it had been a battle field. This notion was quickly dismissed however upon further investigation. Signs of destruction were not consistent with strategic bombings, their only pattern was none at all. Pieces of the terrain itself in all locations across the globe seemed simply ripped up, shaved out, or generally displaced. Its obvious the trouble there had been caused by some kind of spacial anomaly, not something as simple as forceful explosions or weaponry. Here is a shot of the landing zone.

The first few hours were spent setting up spacial sensors within a few miles radius of the initial drop zone for proper triangulation readings. Despite the tools available, however, it was obvious more information would be needed. A scouring of the ruined location would be necessary to infer more of what issues had battered this world. Luckily as triangulation readings filtered in, most of the feedback presented was centered around one area in particular – the city of the drop zone. Scouting the city revealed three areas of particular interest:

• A toppled down Corporation Headquarters by the name of ‘ABT’ showed signs of more recent habitation. Whomever survived the events on the planet were gone though, leaving no verbal explanation. It was still a stroke of luck they chose this location, however, as further investigation of hardware systems within revealed mention of the launch of  a space vessel testing the planet’s first ever warp drive on the date September 12th, 2007 in translation of MST. Intriguing as the idea of a survivor was, the only prudent fact that came from this location was that mentioned date, as further evidence was found.
• A location pinpointed by what appears to be the source of tunneling waves of the distortion. Every ‘chunk’ of reality that was ripped away pointed to originating from this spot. Further inspection of the location revealed it was in fact a crash site, of the very vessel mentioned in the ABT logs. On board logging systems that survived revealed a vocal recording of the crash, which had been just after launch. Upon the peak of the launch, the warp systems had failed due to some form of interference, which in turn caused it to come crashing back down into the city. What was strange, however, was that the warp enginge in question sounded as though something were forcing it to react back to life just prior to the impact itself. A reconstruction of the ship is given below.

• The final spot was a very interesting anomaly, completely untouched by the effects that ravaged the planet. It itself was centered around a hospital, though it was proven with further study that the structure itself had nothing to do with the reason it was spared.

To decipher this mystery, a partner in my research managed to bring to my attention the following. The location of the crash site of the warp vessel was, in fact, the closest thing one can get to a ‘borderline’ to the nearby dimension 573-XX. The leylines in question were structurally sound, which is the disturbing fact, as dimensional energies from either dimension of such close proximity were thus far more capable of interfering with one another. A reading of an undocumented source of feedback was recorded around the same time as the warp-vessels supposed launch date. With this information lining up, the following theory has been tested in a simulation environment and proven rather sound.

1. ABT Warp Vessel is launched, taking roughly three minutes to reach and break atmosphere. Time: 00 min.
2. ABT Warp Vessel shutdowns primary engine systems, diverting power to charging warp fluctuation. Time: 03 min.
3. Dimensional interference from 573-XX begins its emanations. Time: 03 min.
4. Warp fluctuation hole sparks dimensional trigger reaction, warp engine in turn becoming overwhelmed and locked by feeding off the dimensional energy. Vessel begins plummet back to planet side with its systems unresponsive. Time: 05 min.
5. Dimensional energy within warp drive builds, forcing an uncontrolled jump-start of the drive, just prior to impact on the planet’s surface. Dimensional jump energy is thus released, streaking over the planet with little bias in its targets. Time: 08 min.
6. Energy in turn seeks easiest dispersion point, looping back over the planet completely, finding the original warp trigger caused by the initial rev of the drive upon the native vessel’s break of atmosphere. This is why the hospital location was spared, the energies diverging upwards into space above it before sifting off. Time: 10 min.

(1: Launch point, 2: Warp Trigger and escape point, 3: Crash site, image not to scale).

And there you have it. The Dimensional Jump within a nearby dimension, in the wrong place at the wrong time, ended this entire civilization after a series of unfortunate lineups. Certainly this is an extreme case, but from it one quickly notes the similarities between this event and reported displacements all across the multiverse. How many cases of singular displacement have been caused by an unexplained malfunction of a teleport, a warp, or from some pocket space the creator otherwise feels completely comfortable with? Where do you think this malfunction comes from? It would be naive to say that leylines across the multiverse have simply worn themselves down. While true that many dimensional displacements are a natural phenomenon, they also comes from the naive belief that controlled dimensional jumping has no negative side effects. Even something as simple as the displacement of space upon arrival and exiting vacuum upon dimensional exit are issues we shouldn’t be so ready to dismiss.

Therefore, with this study as my proof, as well as my continuing studies hereafter, I beg a wider share of resources be devoted to further research on improving the technologies we already have. We should focus on asking questions we otherwise divert our gaze from, so that we never do unintentional harm in the multiverse we strike so hard to protect. I understand and appreciate the CoRe and Marshalship efforts both thus far, often porting from controlled and stable space under a strong set of heuristics, yet still naive assumptions of our understanding and abilities can only cause harm.

I’m sure the bulk of the crew is already aware of situation on hand after our second encounter with the unit known as Metal Sonic. Upon his defeat, he released a transmission to a place he verbalized as “central”. It is a likely assumption to make that our encounters with him as such have not yet come to end. From this realization we draw two priorities. First, we must better prepare ourselves to fight again, for the obvious reasons. Second, we must track his efforts as quickly as possible. The longer he is left to his own antics, the more time he has to further develop and leech resources in the dark.

There are a couple important observations of initial note:

• Nothing remotely similar as this unit has been encountered within Void forces, nor encountered anywhere on Marshalship ventures. It is a safe assumption to make that he is not linked to the Void in anyway.
• After Dr. Gyldenstierne’s efforts, we’ve found that the unit upon its displacement in our observatory was already damaged and has had most of its memory banks corrupted in some form. Its likely that its actions strive mostly out of self-preservation and confusion, though it does seem to exhibit harsh functions as a result (lightly put, hostility).

With these notes there are some important thoughts that could be inferred. First, without any affiliation to the Marshalship or Void, its extremely unlikely it has any capabilities of dimensional jump. Due to this fact, its easy to assume wherever its ‘central’ is, its on this dimension. Because of that fact, its also extremely likely that this is its first venture in this dimension after being brought by our dimensional attractor. Therefore, ‘central’ must also be fairly close, relatively speaking, something that it created within the confines of the travel from the time of our first encounter to our second. This brings into perspective some important heuristics to mind to our continued scanning efforts.

We should limit our scanning time to cover only areas that overlap as many of these confines as possible:

• Maximum range of Metal Sonic’s transmissitors. Despite our inability to trace the signal after the encounter, we still got a solid reading on what it was, and have a general idea on how far this type of signal could travel in a radius before it would ‘fizzle out’.
• The approximate location of where Metal Sonic first ported to escape from us when he was aboard the Blaze, confined by the radius of his travel speed plotted against the time between our first and second encounter. While he may seem ‘fast’ from an infantry perspective, he is no space-going vessel in terms of warp mechanics.
• Focus sweeps on areas not within the vicinity of Marshalship platforms. It would be an oddity for him to be within the area of such a platform and not have already taken its resources, before or after our second encounter.

With that said, lets get into details surrounding Metal Sonic himself. As requested, I’ve spent the time since the encounter developing a functioning simulation of Metal Sonic in every form we’ve encountered him in thus far, his super-self inclusive in this mix. While perhaps avoidable now that we’ve stolen yet another Chaos Emerald, its a safer assumption to make that we’ll have to deal with this again. This simulation will be readily accessible upon the Captain’s request.

As we’ve seen after two repeated encounters now, Metal sonic has several impressive features that lead to two modes of engagement, his normal and overloaded (‘Super’) form when he taps into a suitable source of power. Lets break down what we’ve seen of this normal form thus far.

• The way his armor has been reinforced has left him strengthened against most standard rounds of ammunition as well as being resilient against an average melee strike.
• Even with proper force in a melee strike, Metal Sonic seems built around the idea of close range combat. As noticeable from the diagram, his joint breaks are at uneven, rather irregular areas that give him a subtle and effective force behind his swings that are complimented by his overwhelming thruster-core. He does not need a variety of approaches or fancy techniques when he can rely on this speed.
• To compensate for his small size, and to compliment his heavy power usage, Metal Sonic is capable of absorbing a wide variety of energies and using them to his own advantage. We’ve seen him drain straight from generators and storage systems as well as directly from weaponry. This in turn cuts down on what options are available for truly penetrating his armor, as the cheap alternative to AP rounds would be stronger beam rifle variants. This also makes using any vehicles against him a liability as well.
• Lastly, Metal Sonic has a basic implementation of spell reflection. This ability centers on a device within his palms, acting as a mirror against sources that directly target his person. He is still susceptible to area effects. However, it should also be noted that physical manifestations of magical origin (a magically created lightning bolt, for example), is still likely to be absorbed through his standard means.

Three primary methods of destruction present themselves as such. Armor Penetrating and Thermite rounds strike well, area manifest magical attacks, and a good old fashioned wallop (given the appropriately backing force or shredding capability to be worthy of the effort) are these three. As seen by our last encounter, we did quite well on his initial approach, tearing him apart from range through overwhelming numbers when there was simply too much fire too avoid on his close in. The other two options in turn are riskier. Area manifestations, if they do not complete the task so to speak, are likely to give him a chance to close the gap between us and him via a confusion element (dust kicked up from a fireball, etc). And lastly, toe-to-toe melee is just plain risky (if not fatal) given the force he can put behind his swings. Given the fact that we already had a working strategy that doesn’t need to incorporate unnecessary risk, I’d present a plan like the following in case of a prolonged exposure.

1. Fire at will: I believe that speaks for itself. I would like to stress that, given the usual composition of our group work (especially against a foe like this), there should be little desire to close any distance between him and us as melee combatant. Melee will bide their time and allow the suppressive fire to commence without getting in the way.
2. Defend and retreat: When Metal Sonic does finally make his approach, melee will immediately intercept to draw attention while the ranged circle to a new position of an open line. Don’t mistake the intention here melee – your goal is to fend off risk at all costs in your efforts. If his attention is to you, I suspect you’ll be doing little more than defending yourself while the rest make their retreat until he tries to turn from you, in which case you make him pay for it and redraw the aggression.
3. Cover melee escape: With his focus and limbs tied to direct combat, it should be safe to begin a spell cast to cover a melee retreat by this point without it being reflected. Something to freeze him in place, temporarily blind his sensors, root him down – anything. It doesn’t have to be flashy or lengthy, it just needs to get the job done.
4. Rinse and repeat: With the melee having swung to rejoin the rest, the effective means of damage output can continue their barrage without risk.

An encounter roughly outlined by this plan plays to the strengths of each member of the team, hopefully preventing the necessity for injuries like those sustained last time due to improper formation. In truth, this also covers a couple possible changes. Should Metal Sonic see fit to attack in trickier fashion, such as that spin-up maneuver we’ve seen a couple times now, only those capable of dealing with this (or even preventing this) will be in close, and any magical barriers can be spread amongst the formation of the ranged combatants to ensure some line of defense and also ensures them of being at maximum distance for their own evasive maneuvers. This same theory holds true should Metal Sonic decide to alter his specification in any means to include projectile weaponry that we have not yet seen.

But even that doesn’t solve our main problem, does it? The truth of Metal Sonic’s danger is revealed when he activates his Super form. It isn’t an understatement to say that, while in this state, he could truly tear someone to shreds before one might be able to utter a hint of protest.

When he chooses to do so (with an appropriate source available), Metal Sonic will temporarily increase the output of his engine core by an extreme fold by force-feeding an energy source to it until that source is used dry. In turn, all of his systems’ output increases just the same.  One can observe what implications this holds by watching the retrieved security footage – his speed, strength, and even armor capacity reach frighteningly deadly levels. Its almost safer to assume hes ‘invincible’ while devouring energy in such a way, though to claim that would be naive and incorrect. If anything, despite his boosted defenses, its far likelier a means of stripping energy from him at a time of increased engine usage would be brutally effective. Trouble is, as said, that’s easier said than done.

The base thought there is to, of course, ‘play it safe’. We only have to outlast his energy supply to reach victory, just as we have each time prior and taking victory over his normal form. Trouble with that is that while in this form, he is extremely deadly to each and every one of us. I’ll be readily accepting discussion of how to deal with this while writing out some of my initial thoughts, so please feel free to contact me.

Recently a crew member came to me with an interesting request to provide them with a set of boots capable of allowing one to walk on walls, which immediately led me into an afternoon of theory on what the best possible means of what such an item would do in order to achieve this effect. There’s a number of ways to administer adhesion between two surfaces. If one wanted to make the assumption that the surface is metallic, a pair of magnetic boots could be a decent way of solving the problem. Alternatively a pair of boots with a sticky surface of sorts could be another route to look into. A simple test of either of these options, however, quickly leaves one with a sour realization. Adhesion, in fact, is not the effect that should be used for this project. If one is trying to mimic the effect of walking, do your feet stick to the floor? Its already straining enough to imagine trying to walk ‘up’, the muscles involved not particularly  familiar gravity pulling down on your body in such a fashion. To throw in further resistance would be diverging away from a useful solution.

In turn, why not look to nature for solutions? Are there not creatures that already have the capability to wall-walk? And if they do, how do they do it? Of course, there are such creatures. I found a recent study on the common gecko’s ability to climb flat surfaces, explaining in detail how it works. Upon the gecko’s feet are millions upon millions of tiny hairs called setae, and like split ends, each seta branches into billion of nanoscale spatulae. The result is a heavily frictional surface without the downsides of ‘stickyness’, capable of forming a bond that is a thousand times greater than the force the gecko needs to hang onto a wall.

From this concept comes the design of the following.

The surfaces of these items are covered in a synthetic array of polypropylene fibers. The fibers, packed 45 million per square centimeter, each measure at a tiny 18 microns long and 0.5 microns in diameter (or about 100 times thinner than a human hair). One micron is one-thousandth of a millimeter. With something like rubber, you control friction and adhesive properties by changing its chemical formulations. For the micro-fiber array, I can simply alter its geometry and mechanical properties. Thicker and fatter fibers, for example, reduce the amount of friction created. Thanks to this property, I’m also able to control when this geometry falls into play. By causing the fibers to gravitate at an angle from a surface (IE: when the boot’s bottoms are parallel to a wall, causing the fibers to tilt downwards), one is able to imitate an almost adhesive like property by means of wedging yourself against it without the downsides of a truly sticky bond. To get a better feel of the surface in question, here are a couple micro level snapshots.

I’ve made these available for assembly via the ship’s replicator systems, so feel free to mess around with them. Keep my forewarning in mind though, please. The addition of the gloves was to address the fact that one will find it difficult is not completely impossible to move upwards against gravitation using normal walking muscles, which have been developed to support the body’s upright weight, not a body parallel to the ground. Even with the gloves, I recommend trying to climb by releasing only one appendage (foot or hand) from the surface at a time, as the support involved is still quite different from getting a hand-hold on a jagged surface and pulling yourself up by relying on your wrist (rather than your palm and fingertips, in this case). Apart from that, however, I feel these will be quite useful in small-scale acrobatics amidst strange scenarios when one can briefly cling to a surface they might not have otherwise been able to.