[이브 온라인] Upwell 2.0 FAQ: 1월 20일자

https://forums.eveonline.com/t/dev-blog-upwell-2-0-structures-changes-coming-on-february-13th/51885/2

지금까지 블로그와 답글을 읽어 주셔서 감사합니다!

지금까지 스레드의 몇 가지 질문에 대한 회신했지만, 세 가지 문제가 스레드에 반복적으로 제기되어 우리의 특별한 관심을 받고 있습니다:

Standup GTFO

지금까지 이 모듈에 대한 의견을 보내 주신 모든 분들께 큰 감사를드립니다. 우리는 당신이 크고 분명한 소식을 듣고 있으며, 커뮤니티가 제기한 우려 사항에 대해 팀 내부 및 CSM을 통해 의논하는 시간을 가졌습니다. 지금 당장 제가 확실하게 말씀드릴 수 있는 것은, 우리는 여러분의 피드백을 바탕으로 계획 중에서 이 부분에 대해 매우 큰 변경을 하게 될 것입니다. 우리는 계획에서 Standup GTFO를 완전히 제거하거나 하이섹으로만 highec(전투가 조금 더 작은 규모로 벌어지며 AoE 무기 옵션이 구조 소유자에게 훨씬 제한되는 경향이 있는)으로 제한하는 등 몇 가지 옵션을 진지하게 고려하고 있습니다. 귀하의 피드백을 계속 주시면, 다음 주에 개발 될 예정에 따라 계획대로 업데이트 할 것입니다.

피팅 기간 5 분

이 시기에 스트럭처를 너무 쉽게 배치할 수 있다는 우려가 커지고 있습니다. 우리는 이러한 우려가 타당한 것임을 분명히 생각합니다. 이 모드는 계획에 후하게 추가되었는데 왜냐하면 피드백과 통계 모두에서 볼 때 스트럭처 앵커링에서 "전부 아니면 전혀" 요소가 너무 많고 스트럭처의 온라인 취약시간 동안의 생존률이 너무나 낮았으며 그 과정을 거친 스트럭처의 생존률은 너무나 높았기 때문입니다. 여기서 목표는 취약성과 전투 변경을 통해 스트럭처 수명을 전반적으로 줄이면서 초기 수리 타이머의 생존 가능성을 높이는 방법으로 이 구분을 덜 심각하게 만드는 것입니다. 테스트 서버에서 전투 변경 사항이 어떻게 적용되는지 관찰하고, 실제 패치 몇 주 전에 해당 피드백을 바탕으로 평가하도록 하겠습니다.

TiDi 및 수리 타이머

우리는 최근의 Cloud Ring 싸움 이후 수리 타이머 확장에 대한 요청을 많이 보아 왔습니다. 타이탄의 산개 덕분에 Keepstar가 수리될 수 있었습니다. 우리는 수리 타이머와 TiDi 사이의 관계를 언젠가 변경하는 것을 배제하지 않을 것이지만, 분명히 본질의 변화는 중요하지 않다고 말할 수 있습니다.

수리 타이머는 원래 "sim-clock" 시간이 아닌 "wall-clock"시간을 사용하도록 설정되어 있었습니다. 왜냐하면 대부분의 sim-clock 기능과 비교하여 상대적으로 긴 지속 시간과 현재 시스템에서는 둘 이상의 서버 노드가 추적해야하기 때문입니다. 구조 상태 변경 및 sim-clock 타이머는 항상 단일 서버 노드로 제한됩니다. 우리는 코드를 검토하여 변경이 얼마나 합리적인지를 확인하고 신속하거나 간단한 변경과는 거리가 멀다는 결론에 도달했습니다.

완전히 정직하기 말한다면 우리는 타이머를 확장시키는 것이 실제적으로 불만을 더 많이 야기한다는 사실에 약간의 염려를하고 있습니다. 매우 큰 싸움에서 서버 성능과 관련된 대부분의 결정처럼 이것은 쉬운 / 좋은 답변이 없는 절충안과 어려운 선택 사항입니다.

모두에게 피드백을 주셔서 다시 한 번 감사드립니다! 또한 Test Server 포럼 스레드에서 SISI의 모듈 및 구조에 대한 통계가 최종적으로 멀리 떨어져 있지 않은지 (특히 새 항목) 미리 알림을 반복하고 싶습니다. 초기 테스트 서버 빌드에는 많은 버그가 있다는 것을 기억하십시오. 테스트 서버를 체크 아웃하고 버그 리포트를 제출하는 모든 분들께 진심으로 감사드립니다.

좋은 밤 되세요 o/