LordFowl

Something that'd be neat is if you actually received the soul of the vampire, as in a soul stone-like object with the vampire's shade.

What effect would this have on gloves, mangled or otherwise?

There's plenty of docking spots around arrivals that i don't see used, perhaps one of those. not really no. you're technically not killing them. their character is being removed from the round, but death is never involved at any stage of the process. As a matter of IC policy, it can be said that it's expensive to send an extra shuttle, and should only be done if security is unable to contain prisoners. But i don't agree with it needing command authorisation, warden seems fine. All docking ports are currently in use. A new one would most certainly have to be designed.

Two shuttles cannot have the same arrival spot, so a new dock would have to be created for this shuttle. Otherwise, I agree that it should be restricted to head of staff because no matter how you phrase it you are technically killing someone. Otherwise it's a very neat idea.

Roleplay ability has no bearing whatsoever concerning Developer positions. The lore team doesn't seem to interested in editing non-lore wiki pages, so if we want anything other than a lore wiki a position such as this may be necessary.

To be fair, an 8 hour brig sentences makes more sense than a 20 minute brig sentence. Its yet another thing that just makes sense when you dilate the timewaves.

It would be more accurate to say that defibrillators as a whole don't exist in Baycode whatsoever, because they don't. Also, as Delta pointed out this issue has been raised before, and it was decided against inhibiting cloning. Trying to brute-force the meta like this would only have unforeseen (but very foreseeable) and shitty consequences.

Don't forget that for clothing sprites there are two different sprites - the actual icon, how it looks when not worn, and then how it looks when worn.

No, it does not concern me as a mapper- it concerns me as a player. I don't know what you're trying to say there, but I'm going to chalk it up as a misunderstanding. You say that all the other races are well-developed, but numerous times in your other posts (Did you know there's an edit button?) you have pointed out that the other races are little more than slight twists from humanity. You refer to their mechanics, and I agree. But then I go a step further and say that their lore is derivative also. Each race is little more than a different flavor of humanity. This is in part the fault of the lore, but I hold that mechanics are more to blame, after all mechanics are just as responsible for how a race is played as lore is. In short, I say we should focus our efforts on the legacy races, instead of diluting it upon whatever new race is popular on paper, abhorred in practice.

This is not necessarily the thread for it, but any idea of 'replacing' the Vaurca is to me as reprehensible as keeping them. We should be focusing our efforts on improving the established legacy races before we idle ourselves away with flights of fancy embodied in fantastical other-races.

Number one can be answered through even the most casually of google-searches, and I'd recommend you start there before you start here. The need for a PHP developer is almost purely for web-based services, and all assets for our current codebase (including art assets) can be found on the github page; https://github.com/Aurorastation/Aurora.3 All standard one-tile sprites are 32x32 increments. Turf sprites that extend over multiple tiles will still be 32x32, but occupy distinct instances. Mob sprites that extend over multiple tiles need to be in increments of 32. (32x32, 32x64, 64x64, etc)

I can't really say what I'd like to see with the Vaurca lore, because its mostly verbose meanderings on largely inconsequential details, burdened by several things that while interesting after a fashion have little to no bearing on actual roleplay and are a bit cryptic. Ultimately, I am largely dissatisfied with how players play the Vaurca, and I think this is because Vaurca lore fails to establish a dominant mood. There are however three specific things I'd like to see changed concerning Vaurca lore, however, and in no particular order: 1): Removal of Vaurca religions and superstitious concepts. The whole "Black Queen" concept strikes me as absurd, and not every race should have a formal or even informal religion. 2): Increased importance of Vaurca queens. Vaurca queens in the current lore are pretty much like modern Earth royalty; just figureheads. They should be the de facto, ultimate leader of each hive. 3): Increased hive loyalty. Loyalty to one's hive is a given to some Vaurca, but not to all. Vaurca - bound and unbound alike - should be absolutely loyal to their hive without fault. In rare cases that an Unbound somehow breaks the indoctrination and disbands from their Hive, they should be looked down upon. That is abnormal.

how so? I'd argue janitor is only a major balance thing in gang warfare mode, which this server doesn't have. I know the janitor can clean cult runes, but so can anyone else with a spacecleaner bottle. Medical has at least five of them, engineering and security have one each too, and more can be ordered from cargo. This is for a variety of reasons, but the one that is easiest to understand is that it requires staff co-operation, because defining role amount is a coder thing. The other reason is a matter of perspective; while any amount of janitors may not have a severe impact on the entire round, an additional janitor slot will definitely have an impact on the janitor. Whether this impact is beneficial or not isn't really relevant when questioning its significance. While I can't guarantee a second janitor slot wholesale, I can tell you that its very likely that there will be extra custodial supplies somewhere on the station in the new map.

I would like to clarify that I never said there would be two janitor roles on the new map, although I am not necessarily opposed to the idea. Furthermore, if you want any mapping changes to be done to the current map, you will need to follow the guidelines presented here http://forums.aurorastation.org/viewtopic.php?f=17&t=5835. I'm not opposed to giving the janitor's closet extra supplies, however creating a second janitor slot wholesale is A) not under my authority, and B) constitute a significant change to game-balance. (Yes, janitor count is a significant change to game-balance), and would by my creed require a suggestion thread like this.

I don't like the game being filled with OoC warnings. This just breaks immersion. I don't image when my character is openning a firelock a NanoTrasen brand pop-up explodes in their brain.

http://forums.aurorastation.org/viewtopic.php?f=17&p=58151#p58151

Hello. During my tenure as Head Developer of the Aurora Mapping Team, a number of threads concerning suggestions for the current map have been appearing. The focus of the mapping team however does not lay with the current map, our only focus is developing and then supervising the new map. When the new map is rolled out we will oversee community revisions and requests for it like any other coder. Due to our primary focus being developing the new map I cannot in good faith have one of my mappers spend their time doing a revision for the current map. That said, however, I do not intend to leave the current map broken as is standard for Baycode. I intend rather to have the suggestions and complaints the community has concerning the new map to be addressed and resolved, so that we do not all need to suffer in awaiting for our Messiah, the New Map. How do I intend to do this, when I have already stated my reluctance to deploy official mappers to accomplish this task? The answer is very simple. I am instituting here now the Ghost Mapper Project. The Ghost Mapper Project is very simple, and at its most basic is a means to allowing people with specific complaints regarding the new map to fix these complaints themselves or with the help of unofficial mappers. The exact steps are a little more complicated, but nothing that a prospective ghost-mapper cannot handle: Step 1: You see an issue with the new map. Step 2: You download the codebase from https://github.com/Aurorastation/Aurora.3 and open the respective file. (exodus-1.dmm is the main station, exodus-2.dmm is central command, and exodus-5.dmm is the asteroid and its outposts.) Step 3: You make the revision yourself. You will be responsible for ensuring everything that you want done is done. I will not do anything for you unless it is the simplest of things. Step 4: You will delete EVERYTHING except the area that you modified. For example. if you modified the IAA office, you would delete every single thing except those things within the IAA office. Step 5: You will save this new revision as [YOUR NAME]_[WHAT YOU MODIFIED].dmm. For example, if I modified the IAA office when I send the file to myself it will be named LordFowl_IAAOffice.dmm. Step 6: You will send the file to me via PM or Discord. Along with the file you will tell me every single modification you made with detail. For example, if I changed the IAA office door to Captain level access only, and put a pulse rifle in the closet, it might say this: "LordFowl_IAAOffice.dmm -Door captain's access only. -Pulse rifle in closet." Step 7: I will review your changes, ensure you didn't try to sneak anything in, and make my own revisions if I see it necessary. I will then proceed as I would an official modification, and your revision will be available and live the next time the server updates. You DO NOT need to make a suggestion thread to send me revisions dealing with things like missing request consoles or disposal chutes or things of a similar nature. Anything of a higher consideration will require a suggestion thread. If you send a revision to me and I request you to make a suggestion thread, the responsibility to do so will be yours and not mine. Suggestion threads will be considered by my entire team and the community as a whole. This system is for smaller revisions, most likely limited to a single room. The bigger your revision becomes, the more likely it will have to be put into a suggestion thread, and the more likely that it may not be enacted. If this system is a success you can expect to see it continue during the new map, so that we'll have ghost-mappers posting revisions alongside official mappers, ensuring a speedy refurbishment of the map. If this system is for any reason a failure you can expect its immediate destruction, and a return to the old system. It is my sincerest hope that this system is not a failure. I will be recording every person and linking their contribution to them, for the sake of posterity and moderation. Don't try to be a sneaky cuck and fill the Primary Tool Storage with invisible pulse rifles. I'll find out, and I will be very sore. If you are unable to make a revision due to ineptness with Dream Maker, but have an excellent idea, do not contact the map team. It will be your responsibility to find an adequate mapper to enact the revision yourself. I will give credit only to the person on the filename, so if you want to share credit name accordingly.

I've already confirmed to Nikov my intents for this sort of thing in-game, but let me make it perfectly clear for everyone who happened to be absent during that particular discussion. Firstly, the new map will be having a system of parallel circuits for the main power grid. It will also have substations. There are many reasons for this, but the primary reasoning I'd like to share is as follows: When we look to what sort of features we're porting over to the new map, we compare the Aurora map to the Exodus map. The Aurora map takes precedence in our minds, so anything that the Aurora map had that the Exodus map does not have will be considered for implementation. This is why we're returning parallel circuits. Anything that the Exodus has that the Aurora did not have will also be considered for implementation. This is why we're keeping substations. During consideration, we'll take into account numerous other things, so this does not necessarily mean every feature from either map will be implemented. That said, anything that the old Aurora map had will probably be implemented, and will definitely already be taken into consideration by the time you ask for it. Community suggestions and our own intentions fit somewhere in this chain as well.

Honestly, something this simple, I could /probably/ make the change for you. I already have github setup on my end, with my own fork, and know how to use it. For formality's sake I would have to review every revision and give it the okay, so that no chucklefuck sneaks in an invisible pulse rifle. Otherwise I am also perfectly fine with community submissions.

I am perfectly willing to perform small functional alterations like this. They take 0 time, and can be packaged with the next code-update. I'll need to cooperate with Skull on using the github, however, so this one might take time.

A form for official informing people of violations of records regulations.

How is a rescue ball any different than an emergency EVA void shut, except for being strictly worse and the only closet-type structure you can't see out of?

I think Nanoko's suggestion makes the most sense logically speaking.

Consuming genomes from 'lesser' beings could have diminishing returns. The first one grants you a full genome point, the next two half a genome point, the next four a quarter of a genome point, etcetera until it eventually becomes zero.

The map team is confused as to what you want. We'd like you to think this idea through more thoroughly. You do understand that mobs spawned in the holodeck will be holomobs, and thus cannot leave the holodeck nor be dissected, and in fact will disappear when they die. They'd only serve really as shooting targets.