이젠 _G 도 보여준다.


_G 가 뭐냐고? 설명하자면 Lua의 전역변수를 정리해서 보여주는 Lua의 기본기능으로써 들어간 테이블이다.

지역변수를 포함해서 보여주는건 _ENV인가 그런데 디버깅할 때 초 도움됨.

사실 이 _G에 대해서 공부해서 알게된 경력은 며칠안댐. ㅋㅋㅋ

지금 아는척 하는중이니 코딩 고수님들이 보시기에 불편하실 수도 있겠으나 좀 봐주세요.


아무튼,

변수쓸 때, local 뭐시기 하고 쓰면 지역변수인데

처음 변수를 선언할 때 앞에 아무것도 안붙이고 쓰면 전역변수가 된다. 내가 전에 무표기 전역변수라고 그랬던거...

그런 변수는 _G에서 리스트를 전부 확인할 수 있다.

_G 안에 있는건 코드안이든 콘솔커맨드(그냥 /c만 쓰면 level에 있는 것만)든 그냥 호출하면 호출되는 녀석들의 목록이다.

특별히 다른 모드에 있는걸 호출하려면 전에도 알려줬다시피 /c __모드이름__ 루아코드... 를 써야함.


그리고 팩토리오는 게임 플레이중에 _G를 변조하면 나중에 들어오는 사람들 디싱크로 튕긴다.

왜냐하면 _G는 저장이 안되기 때문.

참여하려는 경우 먼저 저장을 하고 세이브파일을 전송해주는데, 그 안엔 _G에 있던 데이터가 없음. global 것만 저장된다.

저장을 할 수 있는 전역변수를 따로 관리하라고 던져준게 global 테이블이다.


_G는 require와 마찬가지로, 스크립트를 읽는 단계, ~ on_load ~ on_configuration_changed / on_init 같은 단계에서만 변조하는것.

그것도 멀티에서 쓰려면 게임을 플레이중인 사람과 중간에 참여하는 사람의 _G의 내용이 완전히 똑같이 동기화되도록 로딩 단계의 코드를 짜야한다.

안그럼 비동기로 튕튕...


중간에 참여하는 사람은 저장된 맵을 자기혼자 불러오고 자기혼자 로딩하고 로딩이 끝나면 서버랑 비교대조하는데 이게 아다리가 안맞으면 튕기는거임.

on_load 같은 특수한 이벤트는 중간에 참여하는 사람 컴퓨터에서 혼자 돌아가는 특수한 이벤트이다. 서버에서는 그 사람이 로딩이 다 끝나고 참여하면 on_player_created(첫 참여만) 하고 on_player_joined_game만 발동한다.



아무튼 그걸 확인하는 기능을 넣었음.

실수로 local 안붙이고 써먹은 변수도 확인할 수 있다.


_G와 global 모두를 확인하면 남들이 만든 시나리오나 모드가 어떻게 구성되어있는지 좀더 명확히 파악가능할거임.

특히 남들이 짜둔 코드에서 _G 목록을 잘 봐두면 잘 가다가 난데없이 등장하는 변수같은게 전역변수였다는 걸 확인할 수 있어서 좀 더 편함.


컴피 서버가서 세이브하나 훔쳐와서 들여다보는 짤.


-------------------------------


그 다음은 이벤트 기록

이제 gvv랑 연동해서 gvv모드 안에다가 기록을 할 수 있다.


gvv에서 제공해준 임의 코드를 실행할 수 있는 remote interface를 event trace가 사용해서 gvv 모드 속에다가 새로운 remote interface를 만드는 코드를 주입한거임.


정작 event trace 모드의 모드 요구사항엔 gvv를 안넣었는데,

이 이벤트 모드의 이름 앞에 0 숫자가 붙은것도 그렇고, 가능한한 다른 모드보다 먼저 실행되도록 하기 위한거임.


요구사항을 붙여버리면 요구사항이 걸린 모드가 먼저 실행되고 그담에 실행되도록 순서가 바뀌거든.


그럼 gvv가 event trace보다 늦게 로딩되는데 remote interface 실행순서는 어찌되었길래 event trace가 gvv의 remote를 가져다 쓸 수 있는가?

gvv는 remote 등록을 스크립트 읽기 단계에서 실행하고,

event trace는 on_load, on_init등 이벤트 단계에서 실행하기 때문임.



script.get_event_order() 를 쓰면 문자열로 모드들의 이벤트 실행순서를 return함.

level보다 앞에 실행시키고 싶었는데 방법을 모르겠다... 이벤트 추적기는 그래서 level바로 뒤, 그리고 다른 어떤 모드들보다도 먼저 이벤트가 실행됨.


그걸 위한 이름 앞글자 0.


예를 들면, 앞에 모드가 이벤트 처리하면서 이벤트의 엔티티같은걸 die()죽어라던가 destroy()사라져라던가 해서 쳐 날리면 뒤에 이벤트 처리하는 모드는 엔티티가 뒤져서 뭘 못하니까.

뷰어 같은걸로 만들 생각이면 다른 모드가 건들기 전에 먼저 들여다봐야할 필요성이 있어서 이름이나 등등이 이렇게 만들어짐.




모드 여러개 굴러가면 내부 데이터는 어떻게 처리되나... 비슷한 고민을 했다면 고민할게 없다.


스크립트는 멀티코어 완벽하게 미지원인거 같다.

모든게 순차처리임. 심지어 for문도 순서대로만 돌아감. 최신 컴파일러 같은데에선 for문같은거 코어어쩌고 스레드어쩌고 해서 for문 돌리면 패러럴로 돌아가서 순서가 바껴서 나오기도 하고 그러는데, 여긴 그런거 없다. 무조건 시리얼인거 같아...

코딩하기 단순하다. 뭔가 임시로 만들고 바로 지우는 코드를 짠다고 치면 코드가 실행되는 동안 그 사이에 다른 무언가가 끼어들 여지가 0%기 때문에 그렇게 해도 됨.



이런 모든게 순차처리인데 이 게임 최적화는 미친거 같다. 오히려 지금 막 뜯어고쳐서 멀티코어 지원 이런거 해버리면 모드 만들던 사람들 피꺼솟할지도.


모드는 event trace, gvv, global 등 검색하면 나옴.