Jump to content

Arrow768

Head Admins / Devs
  • Posts

    1,684
  • Joined

  • Last visited

Everything posted by Arrow768

  1. There will be some info regarding the outcome of the poll / this discussion soonish.
  2. Seconding the vote for dismissal by garn. I fail to see the problem. Command Players have already demonstrated the capability to read lore and understand it (in their application) If someone is inactive it is a relatively small investment to read up on the lore. (Compared to that reapplying for the whitelist is a very large effort)
  3. No response has been posted until now, therefore I am closing and archiving this complaint. As you were unable to demonstrate that the circumstances of your characters death were fundamentally out of your control or that the death could not be reasonably expected, the previous ruling about not granting a retcon is being upheld.
  4. Sure. I´ll close it saturday evening (UTC) if you dont reply until then.
  5. @greenjoe Unless there are any points which have not been addressed / You have additional questions I will close this in ~ 44h.
  6. You used a VPN to connect to the server. According to our rules: "Use of proxy-servers can result in a ban or may not be supported. Due to the amount of griefers that use proxy servers in an attempt to bypass punishment, connecting via a dedicated proxy server, VPNs, or routing your connection through a dedicated server host, can result in an immediate permanent ban" I have lifted the ban this time. Dont use a VPN in the future.
  7. The contributing guidelines require that a feature pr is up for two days and has two approving reviews. That has been met, hence there was no “speed merge”. A speed merge is when a PR is merged without those requirements being met. (Which can also happen for a number of reasons) Test merging requires that you have something that is generally “resistant” to merge conflicts. (I.e. it’s not likely to create merge conflicts if something else is merged). With code that is generally not a concern, but mapping changes (especially larger ones) are very bad in that regard.
  8. As stated above, retcons are granted if the player died due to circumstances out of their control (and they could not reasonably expect to encounter those circumstances). The following points have influenced me to uphold the previous decision and not grant a retcon: It is relatively well established that Adhomai is not exactly "safe". This is further reinforced by the fact that you were handed weapons and that an archeologist went missing in the area. Given that there were quite a few ha'rron in the cave, I believe it likely that you came across dead ha'rron killed by another group at some point during your exploration. I was unable to establish how you prepared yourself/your party to explore an area where a person went missing. (I have attempted to contact you via discord, but you have not replied) The outcome suggests that the preparation (in terms of group size/makeup and equipment) was insufficient. In a video I acquired of another group (around 5 characters), that group was easily able to dispatch a number of Ha'rron they ran into (without using ranged weapons). After the first attack your character said: "She needs some medical trrreatment." and "That Ha';arrrrrron bit her a bit." You decided to proceed further into the cave after these statements and encountered the second Ha'rron ~2min after these statements. The presence of lag during rounds with high player count is well established and to be expected. From what I could see in the video, there was a lag spike around 30s before the second ha'rron attack. But I do not believe lag is an overriding factor in this case, as even with lag, a reasonably prepared group is able to easily defeat a Ha'rron.
  9. Sorry for the delay. I am still checking a few things and should have something in the next days.
  10. Just to make sure I got the details right: Char Name: "Rrhuyala Rrhakaslav'Karimi" Game ID: cms-cpQV Canon character deaths are usually only retconned if the character died due to circumstances out of the player's control. (i.e. was not aware of the danger and could not reasonably avoid it.) To my knowledge it has been relatively well established that Adhomai isn't too safe in the wilderness. The way it looks to me is that you ran into a hostile mob, got injured and decided to head further towards danger (into the caves; instead of returning to safety). Imho that does not qualify for "circumstances out of player control". With that said, I still have to check the logs / some other details.
  11. I´ll handle that w/e you completed your post. As you are still in the process of writing your complaint, I am primarily interest in the chain of events that lead to the death of your character.
  12. This topic has been discussed by @Alberyk, @Garnascus and me. We believe that it can be useful to allow players to view most of their notes. This will be part of a larger rework of the notes/warnings system, so there is no timetable on when this will be implemented. Quite a few details of this system still have to be decided, but there are a few key points already: Notes that have been created until the "new" system is merged will not be visible. This would require us to go through all the notes and classify them as "restricted" or not restricted. Which is not doable with a reasonable effort. The ability to make a staff complaint about notes will be restricted in some way. It will most likely be restricted to only make a staff complaint about notes that are factually incorrect. Details will be released once we are closer to a merge of the new implementation. There will most likely be the capability to add other notes aswell. i.e. Lore Specific notes to formalize the lore note/warning process.
  13. I figure this should have been archived a while ago. But lets do it now: Trial passed.
  14. During the "Thunder in the Orchard"-event of the "Dreary Futures II"-story a number of characters have died and in accordance with the rule regarding canon events (quoted below) some players have requested to retcon the death of their characters. First of all, I would like to point out that it is our established policy to not retcon deaths in canon events where the player of the character had a large influence in the death of the character. ("Play stupid games, win stupid prices") With that said, I would like to point out the following facts which influenced our decision in that matter: The players were asked to volunteer in a boarding mission against pirates/terrorists. The players had the capability to check if command has made precautions in case the boarding went sideways (Medical on the shuttle, ...) and back out if needed. A event volunteer has acted against the intentions of the lore writer of the event due to insufficient information provided to them. We have discussed each request for a retcon at length and came to the following conclusion: Out of four players who have petitioned for a retcon of their characters death one retcon has been granted. The death of the character in question was directly caused by the actions of the event volunteer. As such we believe that a retcon is warranted as their death happened to a large extend due to circumstances out of their control.
  15. While I appreciate the application, I unfortunately can not accept the application due to a lack of demonstrated capability and commitment. Generally the expectation to join the development team is: A demonstrated capability to create somewhat complex PRs A certain level of activity (on github). We have made the experience that promises of future activity often do not result in actual activity. If you are looking for projects/ideas I recommend to talk to one of the maintainers.
  16. Moved to policy suggestions as thats not something (primarily) code related
  17. This has been polled from 2022-11-01 to 2022-11-14. As the option to merge the two jobs did not gain a sufficient majority and the maintainers did not believe it would be beneficial to merge it regardless, the PR will be closed and the topic archived in the coming days (33 - I dont care; 95 - Merge; 108 Dont Merge)
  18. It is now possible to use reactions on the forums. Currently there are only a few available. That might be expanded in the future.
  19. The question if borgs should be removed has been polled from 2022-11-01 00:00:00 to 2022-11-14 00:00:00 and discussed by the maintainers. As the option to remove the borgs did not gain a sufficient majority the PR will be closed. (25 abstain, 82 for removal, 136 against) Given the nature of this thread, I expect that there will be follow-up PRs that will attempt to severely limit/partially remove the borgs. It is very likely that such PRs will be closed without much deliberation. I encourage the people who posted in this topic to participate to this discussion. If it is possible to reach a consensus on how the borgs can be improved, then it is likely that a PR implementing these changes will be merged.
  20. People said what needed to be said. This will be locked until the poll is over and the maintainers discussed it.
  21. Seconding the vote for dismissal. We already have issues with backseat command in the form of off-duty crew. Adding the role would just formalise that.
  22. I will close this within 48 hours unless there are any further concerns that have not been addressed or questions about the resolution.
  23. Alright, to bring this to a resolution. The lore masters have been required to establish a procedure for warnings so it is clear in the future what is and is not a warning. This has already happened. (Currently in the form of a internal topic; The lore procedure page on the wiki will be updated soonish) The whitelist strip is being maintained. I concur with the synth team and caelphon that the skirt-incident has portrayed behaviour that we do not want. You may use the relay to resolve events that have been interrupted by the whitelist strip. This has to happen in a timely manner. The established server rules on the relay have to be respected. The re-application period of 2 months is being removed. The lore team procedures currently only require a wait time for whitelist applications that have been denied (and not removals). Given that Lancer did not specify a wait time in the whitelist strip, I do not see the need to apply one now. This means that you could reapply instantly. The synth team will have to make a reasonable effort to work with you and establish requirements that you should fulfill before re-applying. You should contact lancer regarding this after this complaint has been resolved.
×
×
  • Create New...