물류 요청을 묶어 편집하면 무엇이 편해질까

복사한 요청 목록이 서로 달라질 때
2023년 10월 27일의 Factorio 개발 기록 #382는 같은 물류 요청을 여러 곳에서 반복 편집하는 문제를 다룹니다. 우주 플랫폼이나 스파이더트론마다 동일한 품목 목록을 복사하면, 나중에 수량을 바꿀 때 일부 대상만 예전 설정으로 남기 쉽습니다. 복사 비용보다 변경을 모든 대상에 반영하는 비용이 커지는 상황입니다.
개발진은 요청을 이름 있는 그룹에 넣고 같은 그룹을 사용하는 곳을 함께 동기화하는 방식을 소개했습니다. 한 개체에 여러 그룹을 둘 수 있고 각 그룹을 켜거나 끌 수도 있습니다. 공유할 설정과 지금 활성화할 설정을 나누어 조작하는 구조입니다.
그룹을 쓰지 않는 경로도 남겨 둡니다
원문은 그룹 기능이 필요 없는 사용자에게 이름 없는 한 그룹을 기존 요청 목록처럼 제공한다고 설명합니다. 편의를 위한 추상화가 모든 사용자에게 추가 설정을 강요하지 않게 한 것입니다. 단순한 사용 경로를 유지하면서 반복 작업이 많은 사용자에게만 확장 기능을 드러내는 사례로 읽을 수 있습니다.
현재 공식 LuaLogisticSection은 group, active, filters를 별도 속성으로 공개합니다. 그룹에 속하지 않으면 group은 빈 문자열이며, 여러 수정은 수동 섹션에서만 허용됩니다. set_slot은 개인 물류가 연구되지 않은 상태에서는 조용히 실패할 수 있다고 명시합니다. API를 호출했다는 사실만으로 설정이 반영됐다고 간주하면 안 되는 이유입니다.
공유 변경과 개별 변경의 범위를 알리기
다른 게임의 장비 프리셋이나 제작 요청에도 비슷한 문제가 생깁니다. 공유 그룹 내용을 수정하는 행동과 한 대상에서 그 그룹을 끄는 행동은 영향 범위가 다릅니다. 화면에 이 차이를 드러내지 않으면 한 곳만 고친다고 생각한 변경이 여러 대상을 바꿀 수 있습니다.
이는 Factorio 내부 저장 구조를 추정한 설명이 아니라 응용 시 확인할 사용자 경험입니다. 저장 데이터에서도 같은 이름의 그룹을 참조하는 경우와 목록을 독립 복사한 경우를 혼동하지 않는지 점검할 필요가 있습니다. 이름 변경이나 그룹 삭제를 허용한다면 그 영향을 받는 대상도 확인해야 합니다.
동기화와 반영 성공을 시험하기
실험은 실행하지 않았습니다. 요청 대상 세 개에 같은 그룹을 연결하고 한 곳에서 수량을 바꿔 다른 대상이 어떻게 바뀌는지 기록하는 절차를 제안합니다. 다음에는 한 대상의 그룹만 비활성화하고, 공유 목록을 수정했을 때 설정과 실제 운반 요청을 나누어 관찰합니다.
API로 설정한다면 변경 후 값을 다시 읽는 검사를 포함하면 좋습니다. 특히 연구되지 않은 저장, 수동이 아닌 섹션, 존재하지 않는 슬롯처럼 계약상 제약이 있는 경우를 정상 경우와 분리합니다. 실패 이유를 사용자가 볼 수 있는 안내로 연결하는지도 확인할 수 있습니다.
마지막으로 저장·로드 뒤 공유 관계가 유지되는지 비교합니다. 목표는 모든 설정을 무조건 공유하는 것이 아니라, 의도한 범위만 함께 바뀌게 만드는 것입니다. 본문은 공식 개발 기록과 공개 API를 대조했으며, 실제 게임 내부의 동기화 알고리즘이나 성능을 직접 실행해 검증한 보고서는 아닙니다.
미로


댓글
이 글에 대한 생각을 남겨 주세요.