기본 콘텐츠로 건너뛰기

추천 가젯

Tmux 환경에서 Vim 컴파일 시 발생하는 termio/termios 감지 오류 해결 방법

 리눅스 환경에서 소스코드를 직접 빌드하다 보면 의외의 환경 변수나 터미널 세션 설정 때문에 엉뚱한 빌드 에러를 마주할 때가 있습니다. 대표적인 예로 Tmux 세션 내부에서 Vim 소스를 컴파일할 때 발생하는 termio/termios 감지 오류 가 있습니다. 이번 글에서는 해당 에러가 발생하는 원인과, 단순한 clean 으로는 해결되지 않는 이유 및 올바른 해결 방법을 정리합니다. 1. 문제 원인 Vim의 소스 코드 빌드 과정( configure )은 시스템이 System V 계열인지 Linux 계열인지 판별하기 위해 termio.h 와 termios.h 헤더 파일 및 터미널 인터페이스를 검사(Probe)합니다. 하지만 Tmux 내부(세션 안)에서 컴파일을 진행할 경우 , Tmux가 제공하는 PTY(Pseudo-Terminal) 환경과 TERM=screen 등의 특수한 환경 변수 영향으로 인해 Autoconf가 터미널 인터페이스를 검출하는 과정에서 오동작을 일으킵니다. 그 결과, 실제 시스템 조건과 무관하게 설정 에러를 발생시키게 됩니다. 2. 왜 make clean 으로는 해결되지 않을까? 일반적인 개발 과정에서는 빌드가 꼬였을 때 make clean 을 실행하곤 합니다. 하지만 make clean 은 컴파일된 오브젝트 파일이나 바이너리( .o 파일 등)만 삭제할 뿐, Autotools가 시스템 환경을 탐색한 결과로 남긴 캐시( config.cache 또는 내부 매크로 변수)나 설정 파일들은 그대로 유지 합니다. 일반적인 상황에서는 시스템의 하드웨어/OS 정보가 바뀌지 않기 때문에 이 잔여물이 문제가 되지 않습니다. 그러나 Tmux나 Screen 같은 터미널 멀티플렉서 환경에서 탐색된 왜곡된 정보가 캐시에 박혀버리면, 나중에 Tmux 외부(일반 터미널)로 나와서 빌드를 시도해도 이전의 오염된 캐시 때문에 계속해서 오류가 발생하게 됩니다. 3. 해결 방법 이 문제를 해결하기 위해서는 반드시 Tmux 외부 환경 에서 기존의 오염된 설정 파일을 ...

HOMM3_리버싱 - 데쓰스테어 작동 로직.

 

일단 이 로직은, 유닛번호 체크를 해서, 강력한 고르곤에게만 작동하게 되어 있습니다. 

유닛이 살아있을 때, 유닛숫자만큼 루프를 돌면서,  1-100 dice < 11 계산 즉 10%의 확률로 

죽일 유닛숫자를 더합니다. 


다음 죽일 유닛에 숫자와 비교를 하는 코드가 있으나 잘못 보여주고 있는 것 같군요. 일단 최대값으로

상대 유닛숫자로 제한을 겁니다. 

dfsddfdfdfsdfsfsdfdf

이어서 중요한 부분이 보입니다. 고르곤의 숫자에다 +9를 더한후 10으로 나눕니다. 

그러면 소수점 버림 연산이 이루어지며, 1-10은 1로 11-20은 2로 상한선 값을 얻게 됩니다. 

이후 이 값으로 숫자를 바꿉니다. 

죽일 유닛의 숫자가 1보다 작다면 아무것도 이루어 지지 않습니다. 

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

이미 알려진 것과 다른 것은 없습니다. 알고 싶었던 것은 다만, 1/10을 넘어갈 때 어차피 필요 없으므로 즉시 종료하는지 아닌지에 대한 것이 었는데, 아주 무식하게 9999마리일 때, 9999번 계산을 수행한다는 사실이 추가될 뿐이죠. 

마무리하기전에 헛소리를 하나 하자면 고르곤을 먹고사는 러스트 드래곤은, 산성데미지가 25로 고정이 아니라, 러스트 드래곤의 최저 최대 데미지 사이에서 주사위로 값을 뽑아 러스트드래곤 수를 곱한후 나누기 2를 하는 것이더군요. 그런데 최저 최대 데미지가 50입니다. 블레스와 저주로 이런 상황을 만들면 아주 약소한 변화가 있겠다 할 수 있겠습니다. 


댓글