심화편 뒤에 1 쓰긴했는데 솔직히 LTN 굴리는건 기본편으로 충분하다.


그래서 아마 추가적인 것들 적을때 심화편이란 이름으로 계속 쓰지 않을까 싶다. 앞으로 쓰는건 솔직히 말해서 게임에서 대부분 쓸 일 없는게 많을거임.

1. 기차 형태에 구애받지 않는 대기역

간단하게 Depot 2개 만들고 4량 열차, 3량 열차 2개를 놔줌. 이번 주제에서의 환경임.


형태에 구애받지 않으니까 지금은 저 2개만 했는데 화물차-기관차-기관차-화물차 같은것도 놓을 수 있으니 기차가 올 수 있는 모든 칸에 대해 연료 공급이 가능해야함으로 상자를 모든 칸에 다 놔줌. 근데 이러면 그냥 화물차에 템이 연료가 들어가버리는 문제가 발생할 수 있다.


그래서 위의 역의 LTN Output을 자세히 보면 기관차, 화물차의 위치에 대한 LTN 신호가 출력 됨. 이전까지 LTN 글 볼때도 이걸 다루는 글은 본적이 딱히 없는 듯 해서 쓰게 됐다.


이 열차 정보에 대한 신호 방식은 Encode된 신호임. 1번째 칸에 해당하는 신호에 1, 2번째칸에 해당하는 신호에 2 ... n번째 칸에 해당하는 신호에 2^(n-1) 한 신호값들이 전부 한번에 출력 되는 셈. 그래서 기관차가 9 신호인건 1+8이라 1번째 칸, 4번째 칸에 기관차가 있단걸 알 수 있음.


근데 우리가 이걸 안다고 문제가 해결되는 건 아님. 이 정보로 어떻게 회로를 걸어서 투입기를 제어할지가 우리의 목표지


일단 간단하게 &연산하면 Encode된 값의 특정 값을 확인할 수 있음.


그렇게 해서 Encoding 된 값에서 기관차 신호가 감지 된다면 기관차 신호가 0이상일거니 그 조건을 투입기에 걸어주면 투입기 불이 기관차 칸에만 들어오는걸 볼 수 있음.


근데 이렇게 하면 20칸짜리 기차 대기역이 있다고 할때 2^19 같은걸 언제 일일히 입력하고 있냐


이렇게 해주면 알아서 역에서 가까운 순으로 1,2,4,8,16,... 입력 됨. 출력 꼬리 물기라 연산 틱 느린거 아니냐 할수도 있는데 어차피 아래 신호는 설치 이후에 값이 안바뀐다. 기차 들어오면 걸리는 연산 시간은 어차피 1틱으로 일정하고 그마저도 신호값>0이 투입기 작동 조건이라 1틱동안 신호가 없어도 투입기 오작동 할 일은 없음.


왜 곱하기 안쓰고 쉬프트 씀? 하면 쉬프트연산이 비트 직접 조작하는 연산이라 더 빠른걸로 아는데 아님 말고..


선 연결 잘 안보일수도 있으니 함 찍어줌.


그대로 아래 3량 기차 대기하는곳에 붙여넣어도 투입기 불이 잘 들어오는 것을 확인 가능 하다.


근데 이게 만약 핵연료 같은 1스택 연료를 안쓰거나 투입기 스택이 1이 아니면, 기차 연료칸에 공간이 없어서 투입기가 기찻길을 계속 쑤시고 있을 수도 있음. 애초에 이런일 없게 스택을 1로 하거나 핵연료를 쓰거나 하는게 좋은데 이걸 굳이 방지하고자 한다면 아래처럼 하면 됨.


반대로 빼는 투입기에 기관차=0 신호(혹은 화물차>0 신호)를 걸어서 뺀 물건을 다시 모아주면 된다.... 근데 이런 구조를 만들바에 투입기를 1스택으로 바꾸거나 애초에 열차 형태를 통일하는게 낫다고 봄.. 아니면 열차 크기마다 대기역 이름을 다르게 해서 구분하거나..


2. LTN Network ID 및 요청 공급 원리

아주 간단하게 지은 공급역이다. 자세한건 기본편에 설명 나와있으니 참고


LTN Network ID를 2로 설정했는데 이것도 Encoding 된 신호임. 자세한건 아래서 설명함.


마찬가지로 간단하게 중유 요청역을 지어준다. 어차피 대충 테스트하는게 목적이라 무식하게 25k 요청했는데, 실제로 일케 요청했다가 조금 더 실어서 와서 다 하차 못하면 그순간 재앙이 발생한다. 요청은 웬만하면 탱크 용량보다 1k정도 적게 하는걸 기본으로 하는게 좋다.


LTN Network ID를 1로 설정해줬다. 이게 Encoding 된 신호라 위의 공급역과 겹치는 회선이 없어서 요청이 생성되지 않는 모습이 채팅에 로그로 남는 모습을 확인할 수 있다.


다음 역인데 이 친구는 좀 특이하게 지을 거다. LTN Network ID는 3으로 잡되 요청도 하고 공급도 할거임 ㅇㅇ. 그걸 테스트 하기 위해 초기 가동에 중유가 필요하지만 중유를 불리는 공정인 석탄 액화 공장을 기깔나게 하나 지어서 테스트 할거임.


대충 역에 대해 설명하면 중유가 1k이하면 2k가 되게 요청할거고, 중유가 22k가 넘어가면 공급을 할거임(20k가 아닌 22k인 이유는 요청하는데 중유 신호가 -2000만큼 들어가서 LTN에서 실제로 가진 중유보다 2천 적게 인식함)



Network ID가 3(1+2)라서 2인 공급역에서 정상적으로 2천만큼 공급을 받은 로그를 확인할 수 있다.



하차하고 나서 석탄 액화 공정에 의해 중유가 잘 불어나고 있다.


탱크에 담긴 유체양을 같이 찍었어야했는데 좀 바보같이 찍었다. 아무튼 2만2천 이상 중유가 쌓이자 중유를 가져가고자 열차가 온 모습이다.


그리고 요청역에서 정상적으로 하차하는 모습을 확인할 수 있다.


역 세부 신호는 다음과 같음. 솔직히 이런 식으로 쓸일 없어서 구조는 뒤에 둠.

LTN Output에서 항등 연산한 값을 기존과 다른 전선으로 뽑아 하차하는 선에 연결 후 신호값 -1일시 작동(LTN의 경우 유체 요청에서 하차하는 경우 -1신호를 출력함)

상차하는 펌프는 그냥 공급역하고 똑같이 조건 걸면 문제 없음.


그리고 이 역을 통해 알 수 있는건 LTN에서 요청/공급역의 개념을 따로 나누지 않음. 공급 임계점을 넘으면 공급하는거고 요청 임게점을 넘으면 요청하는거임. 그런데 보통 투입기/펌프는 단방향이니까 효율좋게 운용하려면 유저입장에선 요청역/공급역을 나눠야하고, 그래서 요청역에는 공급 임계점을 크게(21억 정도) 잡고 공급역은 굳이 음수 신호를 주지 않는 이상 요청이 발생하지 않지만 구분하자면 요청 임계점을 크게(21억 정도) 잡아주는 이유이다.


근데 ㅇㅈㄹ할바에 그냥 역을 나누는게 낫다.


그래도 Network 분리하는건 나름 쓸 수 있는게 우탐모를 예로 들면

그냥 광맥에서 캔 광물은 네트워크 2로/공급 우선순위 1로 걸고, 코어마이닝에서 나온 광물은 네트워크3/공급 우선순위 2로 건 다음

썩어 넘치는 광물을 매립으로 바꾸기 위한 역을 네트워크1로 하면 그냥 캔 광물에선 매립으로 요청을 안하는데 코어마이닝 결과물은 넘치면 매립으로 가는걸 볼 수 있음. 이런식으로 넘쳐나는 부산물을 처리하는 곳도 구역을 나눌땐 이 네트워크 시스템이 나름 유용함.


더 쓸거 생각나면 심화편2로 찾아오긴 할건데 더 있을진 몰?루