짧은 결론: 레드스톤과 명령 블록은 이전되지만 동작 일치는 보장하지 않는다
레드스톤 회로와 명령 블록이 있는 자바 에디션 세계를 베드락 에디션으로 변환하면 블록 자체는 대부분 옮겨지지만, 실제로 돌아가는 동작이 자바와 같다고 보장되지는 않습니다. 원인은 변환 도구가 아니라 두 에디션의 게임 메커니즘이 원래부터 다르다는 데 있습니다.
- 레드스톤 타이밍이 다르다. 자바 에디션과 베드락 에디션은 레드스톤 갱신 순서와 신호 전파 시점이 달라, 정확한 타이밍에 의존하는 회로(고속 클럭, 타이머, 비행 장치 등)는 쉽게 다른 결과가 나옵니다.
- 피스톤과 관찰자 동작에 차이가 있다. 피스톤 밀기/당기기 시점, 관찰자 발동 방식이 두 에디션에서 완전히 같지 않아, 무소음 피스톤 도어나 순간 회로 등이 더 쉽게 작동하지 않습니다.
- 명령 블록 구문이 호환되지 않는다. 자바 에디션과 베드락 에디션은 명령 구문, 선택자, 일부 명령어가 일대일로 대응되지 않아, 명령 블록 안의 로직을 다시 작성해야 베드락에서 돌아갈 수 있습니다.
그래서 TopoBlocks은 레드스톤 100% 동일을 약속하지 않습니다. 이는 메커니즘 차원의 한계이지 게을러서가 아닙니다. 두 에디션의 근본적인 차이를 먼저 이해하고 싶다면 자바 에디션과 베드락 에디션의 차이를 참고하세요.
변환이 하는 일과 하지 않는 일
변환은 레드스톤 회로, 피스톤, 관찰자, 중계기/비교기 그리고 명령 블록 자체를 최대한 이전하고, 그 위치와 연결 관계를 보존합니다. 하지만 회로 타이밍을 대신 다시 짜 주지는 않으며, 자바 명령 구문을 베드락에서 돌아가는 동등한 명령으로 자동 번역하지도 않습니다. 이렇게 할 수 없는 부분은 항목별 변경 보고서에 적어, 무엇이 변경되었고 무엇을 직접 처리해야 하는지 명확히 알려 줍니다. 몰래 버리거나 성공한 척하지 않습니다.
결제 전에 먼저 호환성 점수를 볼 수 있어, 레드스톤/명령 비중이 큰 세계라면 이를 근거로 변환할 가치가 있는지, 변환 후 얼마나 다시 손봐야 할지 가늠할 수 있습니다. 변환은 건당 결제이며 실패 시 자동 환불되고, 가격은 앱 내 기준입니다. 더 중요한 점은, 변환이 원본 파일을 절대 덮어쓰지 않는다는 것입니다. 원본 자바 세계는 해시까지 그대로 보존되어 추적 가능하며, 출력되는 것은 새로운 베드락 에디션 .mcworld이므로 레드스톤을 다시 손봐도 원본에는 영향이 없습니다. ‘무엇이 이전되고 무엇이 안 되는지’에 대한 전체 목록을 보고 싶다면 자바를 베드락으로, 무엇이 이전되고 무엇이 안 되나를 참고하세요.
변환 후 레드스톤과 명령을 어떻게 손볼까
- 항목별 보고서와 대조해 점검하기. 보고서에서 ‘변경됨’ 또는 ‘수동 처리 필요’로 표시된 레드스톤 회로와 명령 블록을 먼저 보고, 미리 파악한 뒤 게임에 들어가세요.
- 핵심 회로를 우선 실제 테스트하기. 베드락 에디션에 들어가면 타이밍에 가장 의존하는 부분(클럭, 피스톤 도어, 자동 농장)부터 테스트하세요. 이런 것들이 가장 조정이 필요할 가능성이 큽니다.
- 베드락 규칙에 맞춰 미세 조정하기. 레드스톤 타이밍 문제는 보통 중계기 지연을 다시 배치하거나 회로 구조를 바꿔야 하고, 명령 블록은 베드락 구문에 맞춰 선택자와 명령어를 다시 작성해야 합니다.
세계에 순수 레드스톤보다 데이터팩/리소스팩이 더 많다면, 그것은 또 다른 메커니즘이라 처리 방식이 다릅니다. 데이터팩/리소스팩을 베드락으로 어떻게 처리하나를 참고하세요. 자바 에디션 → 베드락 에디션 전체 과정을 체계적으로 이해하고 싶다면 심화 가이드 자바를 베드락으로를 참고하세요.