Skull132

Bans are lifted. If you have trouble logging in, please reply to this thread. I'll leave it sitting for a day or two.

Let this sit while the head memes look this over. They did and have nothing to add. Soo this is gonna get closed and archived.

For reference. Both of you were banned. You're just catching the brother's ban first. Both of you were identified as violating the rules, and subsequently banned. Also note that the ban isn't from a year ago, it's from 3 months ago v.v For reference, your two notes: (from your account, not your brother's) mattatlas on 2017-12-24 16:17:29 Warning added by mattatlas, for: For using netspeak ICly and ignoring staff PMs. When you return, please read our rules and do not ignore staff when they PM you. You are not allowed to use netspeak IC and you are expected to keep in character at all times. skull132 on 2017-12-25 18:14:10 skull132 has permabanned btelchi. - Reason: Metacomming with Reneh. Shared IP, wordless interaction to the benefit of the other, etcetera. - This is a permanent ban. But anyways, I'm partial to an unban since there are no other notes. But note: we cannot necessarily lift the IP bans. The moment your brother connects via the same IP, he nabs you along with him. So please do make sure that you both are on the up and up as far as the rules go. Also awaiting [mention]Datamatt[/mention]'s opinion.

Further more. If Burger were somehow malicious, he probably dedicated his time to put up this pull request, as an attempt to remedy his last one. I'm not saying it would be accepted, nor am I saying that it's good (because honestly I've not yet read it); but what I am saying that despite him not playing as chef anymore, he's still trying to take care of his changes and modify them to better fit purpose. If he was malicious, he would have just not done this, specially considering that I have put up a PR implementing my version of the rework, which has been up for the better half of a week. (Again, more reason for him to just drop all of this.)

And right here we've illustrated just why I ignore intent as much as I am able to. My personal view on this is as follows, for the sake of clarity: Burger was playing chef and recognized, that players do not regularly visit the chef. Instead they go for the quick grab of food. The interpolation from this is that the chef doesn't get much action due to the fact that it is easier to just get shit from the vending machines. This is, in fact, a very old realization. Having just played chef, he chose to do something about this. As a developer, generally, with issues like this, you have to ways to alter gameplay: with negative feedback, or positive feedback. Negative feedback is usually preferred, as it reduces the chance of power creep. Now, believe it or not, probably every single developer has acted like this one time or another. The act of coding a change, motivated by anecdotal experiences, is nothing really new nor something to be afraid of. In my opinion. Further, his changes were not malicious. They did not damage the game, the server, nor its population. All they did was implement a set of changes which included a heavy-handed negative feedback. And I do not believe it was done out of malicious intent (intent to harm the playerbase, the game experience, etcetera).

As I alluded to in #server_moderators, the general answer to this complaint will be a "No". But let's get into actual detail, shall we. First, understand that any contributor is free to open PRs. The responsibility for actually accepting these PRs lies with the development team, and more specifically the Maintainers (Arrow atm) and myself. If anything, it was our fault that the PR was allowed to be accepted. Consider it a mistake. One which will be fixed in the next update coming a week from now. (The relatively short time frame for the update is also why I've not fully reverted the changes in question yet.) The two things I can offer with regards to this are promising that we will do better to scan for these PRs in the future, and that we are actively looking into ways of improving the community-to-developer communication on the subject of certain gameplay changes. Granted, the latter will take time. Next, allow me to state that I do not care, nor do I think we should care, as to the reasons why someone makes a PR. This is a mentality that I have always pursued, in both administration and in development. I do not necessarily care why someone requests to implement certain changes: I only care about the effect these changes have on gameplay. Similarly to how the administration doesn't care about why someone submits a complaint about a rule's violation: if there's a rules violation reported, you are obligated to report it. Granted, there is the case of malicious nitpicking, but those kinds of things are usually handled as culminative things. And will most likely be handled similarly on Github: if someone keeps submitting shit PRs regularly, they may face penalization. But we are not at that point yet. Third. All of the outcomes you listed, as a whole, are impractical and extreme. The amount of work required to implement and manage C is dumb, it will sap motivation from all of to devs to work on anything and we will see our dev team quit. Similarly, administration does not have to make a thread about every warning or ban issued. Much like instances of rule enforcement, all development changes are logged and are available for scrutiny if needed. If an error is detected, said change is reverted or amended. There is no need to change how this works. D1 will see our development slow down again. And there is no practical difference to Burger being a dev or not on this count, due to what I outlined in the first paragraph: all contributor changes need to have the blessing of the development staff and maintainers. B will require a lot of work for minimal outcome. For one, this error should have been seen before the green merge button was pressed. It was not, myself and Arrow made a mistake. Adding another high work-load component to the equation will not see errors like this stop happening. Further more, a QC team would not help detect issues with some of the more nuanced changes implemented, which have caused outcry in the past, as their effect in full, actual, day-to-day gameplay was revealed. Synthetic testing cannot uncover these ones. A is in the category of cruel and unusual punishments, specially when you take into consideration what I stipulated in the first paragraph. Now, ultimately, what outcome do I see coming from here? Well, first, myself and the Dev team will fix our fuck-up in allowing this PR to get passed and will put better thought into what's being merged and what's not. Second, the code in question will be reverted in the April update, which is in one week's time from now. Third, as already posted, we are actively working on ways to improve community feedback on contentious PRs. idno. This is pretty much all I can offer beyond repeating, "I'm sorry, we fucked up, it'll be reverted and we'll make sure that a similar situation doesn't arise in the future."

Could also consider implementing a feature whereby landing on flooring has a 1 - 5% chance of cracking the tile and breaking wiring/piping that's underneath it.

No, because the icons are sent only once into your cache. Anyways, newer versions of BYOND fix the issue. (Until Lummox breaks it fucking again.) To be quite frank. No amount of individuals observing the github will stop cases like the junkfood PR popping up and getting merged. Even if junkfoods was a bit more overtly stupid, there have been a dozen and more PRs which appear quite innocuous, but have a profound and negative effect on gameplay. And spotting and calling out all of those is an impossibility. Which is why there must be, and is, a feedback system in place. If a feature that gets merged is detrimental to gameplay, post a suggestion to improve or revert. As long as we, the developers and contributors, take that feedback and roll with it, all will be fine.

Regarding this proposition. As I told you and later Nursie, this is the pinnacle of pedantry. And forced pedantry at that: an attempt to condense a large quantity of information into something that a 15 year old should be able to digest and navigate for no better reason than to hope that this will, in some way, raise adherence to a set of rules that have been in place for ages. This limits players all to heck for no real reward: I do not foresee this helping administrators nab onto players who're being stupid with their character skills. This page would perhaps be helpful in a manner where it simply describes the various options a character has in terms of choosing their educational route. Their requirements, the time it takes, what it would allow you to do, etcetera. With the goal of informing players and staff alike on the compounds of designing a character's educational route. Now, regarding skills. While Jackboot was slaving away at this, I did start toying with the idea of having skills influence job selection a little bit. First off, lemme just say that a full on skills system, one with ingame effects, is not in the plans at present. Such a task would be an absoloutely immense undertaking, due to the amount of interactions you have available ingame. But there are ways to make skills matter a bit more. Something I thought of was making skills influence the RNG which assigns people to their jobs. For example, a character that's followed a shallow-but-wide specialization route would be prioritized lower for certain jobs (like scientist) when compared to a character whose skills are set up specifically for science. Stuff like that. Obviously there'd be a clear indication of how the weights would pan out for the player as well, so they could make an informed choice. The only issue that would bring with it is potential powergaming of the skills. But as we look towards more guiding systems, making it impossible to game them is, well, impossible in and of itself.

Not gonna happen in the way described, sorry. I played Goon for a few good years, and was able to see what kind of an effect the ling blood boil test had on gameplay. At best it was irrelevant. At worst it was used as a tool to powergame. So basically, the mechanic either added nothing, or it detracted a good bit from the gameplay.

Hooookay. Before replying, please read the ENTIRETY of this post. There are multiple things I wish to address with my post and they're all sort of related. I will also be using links to specific places to illustrate some of the points I raise. So you can evaluate some of the material with your own eyes, instead of just taking my word for, "We do stuff, trust me." The intent of this post is to shed light and to address sources of frustration that I've heard from the playerbase, and from the development team. To outline some actions we plan to take to alleviate this frustration. To request that certain actions be taken by the playerbase to alleviate this frustration. And to shed some light onto some processes which may otherwise remain abstract. First, let's have a talk about the community interactions with developers. There are two notes that I want to concern myself with here, the first of them being the reporting of bugs via Discord/OOC/whatever mode of communication other than Github you may prefer. Please do not do this. Understand: there are 500 or so players that visit this server regularly. That is a lot of people to listen to. And if you're all poking the small team of 5 individuals with gripes which they choose to be important, then, well. The devs get burned out to hell and back. Github should be used to report bugs, and we, the developers, will run regular patches chipping away at the every growing issue count. Now, there have been high key bugs which persist and which people have probably grown disgruntled over. A short list: Space wind AI crashing Server crashing Anesthesia not working reliably Since these four are high profile and have gone unfixed 5ever, I will be illustrating various difficulties with fixing them. But I assure you, every high priority bug that is reported to us gets evaluated within a few days. This involves security breaches (tickets recently; being able to crash the server with the ore summoner or character creation window from the past), and items which have a high impact on gameplay. But there is a list of things we cannot fix. AI crashes and server crashes are clearly in that category: we have investigated both. I've filed a bug report to Lummox regarding the AI crashing, and backed up MSO's report on the server crashes. Unfortunately, Lummox has yet to resolve the issues. It did look like AI crashing was remedied in a patch to BYOND, but later patches caused it to grow worse. Also, specifically regarding the AI crashing: people have called me and my team out on our updates increasing the frequency of crashes [1] [2] [3] [4]. Yes, this is possible. However. At present it looks like the crashes are caused by images being loaded by the client. The AI system relies heavily on images to create the static which stops them from wallhacking. Due to the size of our map, there's a lot of those images. So the frequency of crashing is quite high. There is also a theory of certain objects causing it under specific conditions, however, dicerning this is a practical impossibility as well. Figuring out what causes the crash, if it is a visible object, would involve days of brute force testing to potentially come to the conclusion that the object in question is no different from anything else, which plants us back to square one. Ultimately: the key principle of BYOND is that the client and server should never EVER crash. We lack the proper tools to humanely handle them. We have done all we can, the rest is up to Lummox. Regarding the other two, those are within our power to fix. And effort has been expended into fixing both. For space wind, the easy fix was known to us forever, effectively. And a form if it was eventually implemented by Lohikar in the PR I linked above. However. This fix is not ideal. The present state of Aurora code, specifically the speed and reliability at work, was achieved through a long list of really specific optimizations and fixes. It was and is meticulous work. The fix, as implemented, goes completely against it, implementing a very costly procedure into an already costly subsystem. And the unfortunate matter with code is, once something is implemented, it'll probably remain as is until it outright breaks. Which is why there was initial push back against implementing this fix, and the hopes of a better alternative being figured out. As for anesthesia, I already told Xander about this, but I personally put half a working day into figuring out this issue. And wasn't able to reproduce it on a local server. I was then called in a few times on the live server when it was happening, and was unable to notice anything out of the ordinary on the mobs and setup that would reveal the issue. This is all to say, I personally cannot fathom what the issue and it is by no means trivial to spot. Which is why that specific report is sitting with little motion. To summarize the discussion around bugs. I assure you, we are not ignoring the community. I assure you, we pay attention and actively handle them as we can and are able. We are also aware of the annoyance and pure frustration it causes to players; some of them also cause a great deal of annoyance and headache to us as well. But please keep reporting them on Github explicitly, unless they're a major security risk, at which point PM me over Discord. And please have patience, because after all of the major ones are done, the rest, to us, are all equal in severity and it's literally a random draw what we fix and when. (Though bugs centered around newer features are usually prioritized higher, specially right after an update.) Now, moving on to another source of frustration that I've heard from the playerbase. This would be some recent gameplay changes alongside some controversial PRs that have gone up. First, allow me to address some of the recent gameplay changes, map changes, etcetera. This includes things like junk food and firing pins. First, much like with bugs, please do not moan at the developers directly for implementing these changes. While I don't wish this entire thread to read as, "The devs are made of glass please hold them dearly," I do wish to bring to light the fact that this kind of conduct is absoloutely draining and makes the developers not really interested in paying attention to you and your wishes. Or just makes them want to leave. Communication is a two-way road. Now, first, where to moan? Suggestions forums, those two threads are a good example. We do heed feedback and have adjusted multiple features to accommodate feedback post-launch. Mice buffs, K'ois, devouring, Alb's overdose changes (which were killed) etcetera. The list is long, extremely long, and the PRs are unfortunately kinda hard to find on this. But if you've played enough, you should be aware. However, note that said balancing is done with some consideration given and we rarely revert things. We'd prefer to adjust new features to fit feedback and see if they can be salvaged. This is why reverting something sour might take up to two months: one month to save it, another to kill it if required. On top of this. Lately there's been an uptick in merging controversial changes. This is not really surprising, considering there's been outside contributors to the code. Their gameplay views do not necessarily match one-to-one with what's been done before, but aren't necessarily out of line either. So essentially these could be classed as growing pains. Once water's been tested, and we know the result, we know to follow that line in the future. It should also be noted that it isn't necessarily possible to evaluate the performance of a PR ingame without actually putting it out there. For example, the discomfort caused by junk food might look fine on paper, but ayy, turns out, it's horrible in practice. This is most notable for any PR that involves probability or continuous processes. Probability is really easy to get wrong, and evaluating the discomfort caused by continuous processes and their evolution is also really easy to get wrong. But as long as there's a suggestion thread up regarding feedback on a feature that's implemented, we will do our best to re-evaluate and balance. (And yes, re: Janitor, I apologize for missing out on that one. It was actually posted in #developers whenever the last update was being finalized, but I was too ill to actually pay attention to it. We'll making a decision on that this coming update.) A related matter is feedback given about pull requests by the playerbase. First, there's been violent reaction to PRs which propose more outlandish changes and then violent reaction to those PRs not being immediately being denied/changed/whatever. Allow me to clarify the entire process of a pull request: A coder drafts up initial code and puts up a pull request. That code will then, at some point, be reviewed by Aurora developers. If it's funky, it gets tagged as "Feedback required" and I usually drop it to admins or head admins for opinions. Alongside discussing it with the development team at large. Sometimes also a suggestion topic is created. Once feedback is consolidated and provided, it is then up to the developer to consider his actions. NOTE! Changing PRs TAKES TIME. At some point, an absurd amount of time. Do not expect immediate, visible actions to make amendments to a PR, this is unrealistic. Pestering a developer continuously about it may also end badly. Your best bets are to either post on the PR itself, to have a civil discussion with the developer and hope he takes your views into consideration, or to leave a note on the related suggestions thread. But note that once a developer or a maintainer has left a notice on a PR requiring some sort of changes. The PR will not be merged without those changes being implemented. PR gets updated and reviewed again. This cycle repeats until we're happy with the end result. PR gets merged. The third point cannot be overemphasized enough. PRs are usually not closed if the specifics of implementation are deemed bad. Official word from staff may take time to get to a PR, so again, no changes on a PR which has no official review from a developer is also not something to get frustrated at. The gathering of information, or even getting around to reviewing PRs, takes time. But the process I outlined above is completed at one point or another. I assure you this. And there are plans to help with feedback aggregation, but those are for later note. Now. That was a lot of discussion around how to interact with developers. Again, I cannot over emphasize the reason why I wrote all of that. It is ultimately not to force or to even ask of all of you to hug the developers close as if they were some glass cannons. No, we get as annoyed and as frustrated as you all do at times; we fire back and meme back. But in order to maximize the effectiveness of having your wishes go through, you should be doing the things I noted above. We usually forget bug reports given verbally after 30 minutes, none of us are going to up and fix them immediately as you say. The specifics of verbal feedback are hard to remember after a day, when it comes to new features. And when it comes down to it, we can just ignore you on Discord, as it's a scrolling medium and no one's going to take you seriously if you say, "Well I told you on a fast-moving channel on Discord!" So please, use the forums, use the Github. And don't spam the devs with things that belong in either of those two places. Talk code and features when we're up for it and actively talking them ourselves. I hope that makes sense. And note that similar principles are in place for all other staff already: the devs really shouldn't be any different. Somewhere down in those paragraphs I also mentioned that communication is a two way road. Well, that's true, and the developer-to-community communication hasn't been the best. Specifically, aggregating feedback for PRs and features has been a mixed bag. Both in terms of where and how you folks get to provide it, and in how we can gauge it. So, we have a few ideas to improve that process in the works. Specifically, introducing feedback provided from within the game around issues marked as requiring it and via a direct link to Github. Ideally, it'd involve with you either filling out a short questionnaire about the feature, or providing written feedback and whatever; and eventually, it'd get aggregated for the coders to view on the WI and a link to said panel posted on the relevant PR. It'd allow the coders to remain Github centric in their actions, while the players get to provide feedback from the comfort of their most favourite 2d farting simulator. Hopefully this'll bring the two settings closer and allow for better synergy. Another thing we took a look at was incentivising bug fixes and suggestion implementations. Specifically with perhaps something similar to gud koder points. Hopefully this will allow us to get a more balanced diet of bug fixes, random features, suggested features, and major reworks. But, due to the fact that this would have to be more thoroughly planned out and discussed with both developers and community coders alike, the only thing I can say about this at the moment is that, "We're considering it a bit more than we were in the past." SO. Hopefully. In these 2 330+ words, I was able to answer a few concerns. Bring some light onto development related issues. Explain some things. And provide reasonable solutions and discussion to some of them. If you have any questions or concerns or whatever the dicks relating to development, feel free to leave a reply.

I kinda wanted to avoid easy-to-use and understand gimmicks for identification whenever I designed and wrote vampire. The problem is, well, as Garnaboo said, meta. And not even outright meta. If you're given an easy to use method for identifying a certain type of antagonist, then you will probably start using it/noticing that identifier subconciously and suddenly the round changes a little in nature. I'm open to more methods for identifying and interacting with vampire, in fact I want to implement some more cult synergy with them, but I'd rather it not be tied to a simple action. Kinda like how you can realize there's a vamp around from having people with inexplicable oxyloss coming it. It's a bit harder to grasp than just shift-clicking them and seeing a message, "They have bite marks on their neck! Le gasp!"

Believe it or not. This is harder than one would expect. Specifically because I was never too interested in rooting around forum software and phpBB lacks a proper plugin to automate resizing. yay. We are slowly looking into new forum software, but until such a time, this probably won't be implemented. Purely because learning a new piece of software is not something I have time for until the summer.

:thinking: We shall see, mon ami.

These suggestions run on biyearly schedules, I swear. Here is the ultimate crux: someone somewhere will be pissed with whatever voting system we implement. As such, is there really any point in putting extraneous amounts of effort into trying to fuck with it, if someone, three to six months down the line, will get just as sour as some folks are at the moment and we get to repeat this adventure all over again? Though I will concede that there's one interesting point here. Secret is voted 90% of the time and perhaps it might be time to make a decision based on that majority outcome.

I might have come up with a more tolerable way to implement a similar idea. IMO bringing in things like getting fat or whatever else you might have would be a bit too much. It would befall the same trap as this PR already has: being a bit too severe. Depth is not the issue here, severity is. Perhaps a better way to do this would be to have another variable for hunger: attrition rate. By default, attrition rate would be 1, which would basically be the status quo. Your hunger would diminish at a regular rate. As your hunger diminishes, your attrition rate would rise. The rate is effectively a multiplier applied to the rate at which your nutrition level lowers, so higher attrition rate == you go hungry faster. Now, how we'd use it would be pretty simple. Have junk food not reset the attrition rate to 1. The effect would be the junk food "lasting" a shorter amount of time than normal food. This would make you consume it more regularly and basically mildly annoy you to shit. And then let's have regular food reset it to 1, so you go back to normal hunger fall-off. The key benefits to this would be that it's not outright harmful. It's mildly annoying and inconveniencing, but doesn't outright kill or harm you. This discomfort can also be calculated with mathematics relatively easily and adjusted in the future, as need be.

This wouldn't solve the issue presented. Not being a research station would help us bring more outside elements into gameplay. Such as visitors, refugees, covert hostile forces. Whatever, really. It'd allow us to introduce new identities and, through them, new roleplay and gameplay opportunities.

Straw poll won't be an acceptable metric. The only real acceptable metric would be a forum poll with a long ass duration and constant campaigning by admins to notice it. Otherwise you'll only get a tiny fraction of the playerbase covered. MORE STATS! Extended was voted for roughly 207 times last year. It was played 491 times. So a good 3/5ths of extended is played via secret extended.

Interesting point. We actually have test data to predict what might happen if this goes through. At the moment, extended is played about 15% of the time. Alongside autotraitor with a similar percentage. These two round types form the majority of any specific round type played, everything else is below 10%. Now, when this percentage started creeping back a bit during our Mixed Secret testing shenanigans, we had a lot of folks complaining. And this complaining lasted for a good long while -- it wasn't just a knee jerk reaction. The main conclusion I can draw from this is, autotraitor and extended form the basis for every other round type. They are essentially the relaxing, "vanilla" experience on our server, and everything else is sprinkled in on top of this. If we remove extended from secret, it will most likely be played less regularly, thus we start chipping away at the basis of our gameplay experience once more. And it may end in the same vain as our tests with mixed secret.

Well. I read the thread. And I'm of mixed opinions. First, let's address the actual concept of the race. I find conflicting claims about their essence. This is claimed somewhere down the line: And yet. I guess they're not literally moles, but they are, quite literally, mole people. It's a whole lot more than their ethos. Which is irksome to me. Because they're effectively mole people mixed with an ancient Roman aesthetic. All of which is a bit too blatant to be referred to as, "Skillfully executed." They're not really creative, nor are they even too interesting if you manage to unpack those two truths. Their design, in my opinion, also goes counter to their purpose. Playing this race too close to humans, which they are, will make them not alien enough. The crew species are fine being friendly and warm looking, they're effectively regular Joe's you go to work with. So it makes sense, from a gameplay perspective, to have them as something familiar. But if you want to introduce a new conflict vector and make that also look human, then I don't really see that decision being a good one, unless one very specific angle is played up. So, in my opinion, they would benefit from being actually alien. It would make them this strange new thing, that you can't just hand weapons and armour to; that you can't just talk or communicate with. That you need to figure out how to work around, even from a very surface-based look. They would benefit immensely from being both visually and mechanically incompatible with the crew/human-like species. Another note for discussion is their role in the setting and round structure. And that's definitely something I'd be interested in giving a shot. It might introduce a persistent unknown factor into gameplay that'll liven up old formulas. But again, I think this decision would be better framed by the species being actually different.

[mention]Benl8561[/mention] You appear to be generating a new computerID every time you connect? Unless you're swapping PCs every time you connect, this is usually a tell-tale sign of using unwanted software in an attempt to obfuscate your connection details. So uh, what's up with that? You also shared an IP with the owner of the ban, hast5250. Which is how you ended up here in the first place.

Trivial changes are wherein the rub lies. Just as a memo.

I can't really tell if this is the result of my nudge or whether you actually think that. But this seems relatively ignorant of the larger picture and the reasons behind the policies I mentioned earlier (and the feedback others have given). What's been said has been entirely fair, and it is misguided judgement to claim otherwise. You've not played nor actively participated in this community for about 2 or so years. You certainly have not been an active member for three months following your return. A week here or there will not change this fact. I might be twisting words a wee bit in saying this, but do not expect a position of responsibility to motivate you to keep your ass in check. It does not work like this. At all. Never will. Volunteer work is still work. Work is stressful. Stress makes you drop your guard and act out on core personality traits. Saying that you need this dynamic to keep you in check is oxymoronic. If there were one motivational thing about this whole affair, then it could be the prospect of eventually, after you've actually proven yourself to be a stable and well conducted community member to the point where we need no longer question it, being considered for a staff post.

Also, since this thread exists and apparently the original concept was not implemented into the wiki (a lot of ECF shit is just copy-paste of the same thing), I'll just use this real quick to echo the original view of the military. If this should be its own, standalone application, then please point me that-a-way. In the beginning, the military was split into two: the Eridani Federal Navy, and the Eridani Federal Army. The Navy would primarily handle power projection and protection of trade-routes and the general space that the ECF controlled. They were the offensive portion of the Eridani Federal Military (FedMil), with a Ground Combat Command to enable them to drop onto hostile worlds and conduct ground operations on foreign soil, should that be necessary. This is to say: the Navy could operate completely independently from the Army in all offensive operations, and as such, was the only offensive force the ECF required. Though their primary tasks revolved around providing security within the ECF controlled space by destroying pirates and so forth. The Eridani Federal Army was tasked with terrain-to-orbital defence (cannons and missiles), and with providing ground defence should any hostile faction ever attack a colony or the main planet. As an aside, they also began acting as the arm of the Federal government when it came to enforcing the law. The Federal Army had a large emphasis on acting as gendarmeria, with it playing an active role in counter-terrorism and in the handling of large scale organized crime. This role also provided the ruling corporations with a tool to bypass local hivecity governments, and their own law enforcement, whenever necessary. Large scale raids by the Army would not be an uncommon occurance, specially in the high-traffic shipping and industrial sectors of cities. The local law enforcement, as originally envisioned, would be primarily ran by the local city government. And the goals of a large hivecity would often be different from those of the ruling megacorporations, with the former having way more municipal concerns. This would create potential for situations where the Army acts without the knowledge of the local police, or in outright contradiction to them.

Excuse me while I butt in here as the original creator of the ECF. In the original concept, and as far as has been currently written, there is an overarching centralized system to the Eridani militaries. Which, IMO, should be retained to a degree. The original concept was that under the two major banners of Eridani Federal Army and Eridani Federal Navy, you'd have multiple corporations as subcontractors providing manpower, equipment, training. However, their training, equipment, and the rest is still very much standardized. And, on initial inspection, it would be hard to dicern individual subcontractors. Imagine something along the lines of each regiment being its own contractor. This system, which puts less emphasis on individual and large players in the military, allows for the armed forces to be smaller than the ruling corporations. And one of the dynamics of the faction, originally, was that the military was very much in the hands of the large corporations ruling the state, be those corporations medical, research based, or whatever else. Which is only really possible if the military contractors are effectively centralized and, again, smaller than the ruling industrial corporations. So ye. It would give more flavour to have some of these listed out. But the military should still retain some semblance of centralization (which Abo probably thinks of as professionalism).