현재 컨텍스트의 이름을 얻는 것 외에는 대부분 원하는게 가능할 것 같습니다. pObjectExtention 에 어떤 객체의 포인터를 넣어 놓고, procTranslate 가 호출되었을 때 그 값을 객체로 캐스팅해서 사용하면 객체의 분기문제도 해결될 수 있을 것 같네요
제 생각에는 현재 컨텍스트의 이름을 알려주는 것이 좋을 것 같은데요.. 예를 들어 보겠습니다.
상황) 이름과 대사부분이 서로 다른 포인트에서 잡히는 게임을 후킹합니다. 각 컨텍스트명은 각각
"NAME" 과 "TEXT" 라고 하겠습니다. 그리고 필터는 커스텀딕과 비슷한 역할을 하는데, 각 컨텍스트마다
다른 사전을 가지도록 합니다. 예를 들면 이름쪽은(마나카, 유이), 대사쪽은 (안녕하세요, 오랫만이에요)
뭐 이런..
문제 1) OnObjectInit 가 NAME, TEXT 컨텍스트 순으로 불렸습니다. 필터 쪽에서는 컨텍스트명을 알 수 없으니
첫번째 객체는 1, 두번째 객체는 2 로 명명합니다 (곧, NAME=1, TEXT=2). 그래서 데이타 파일을 다음과
같이 만들었다고 하겠습니다.
[1]
(일어) 마나카
(일어) 유이
[2]
(일어) 안녕하세요
(일어) 오랫만이에요
물론 (일어) 자리에는 각각의 한글에 해당하는 일어 내용이 들어있다고 합니다.. -_-
이제 게임을 종료시키고 새로 게임을 시작합니다. 이 때 반드시 NAME=1, TEXT=2 에 맞게 데이타가
들어온다고는 할 수 없지 않을까요? 또한, 만약 새로 선택지 포인트가 발견되어 선택지 컨텍스트가
생긴다면 각각의 데이터가 잘못된 컨텍스트에 배당될 가능성이 있습니다.
문제 2) 이 게임을 다른 작업자가 보고 데이타 파일에 부족한 부분을 보충하려고 합니다. 첫번째
데이타 파일 작업자는 대충 [1] = NAME, [2] = TEXT 라는 것을 알고 있습니다만 두번째 작업자는
[1] [2] 라는 숫자만 봐서는 이 숫자가 무엇을 뜻하는지 바로 알 수 없겠죠. 물론 이름과 대사 정도면
바로 구분이 가능하지만 대사와 선택지가 되면 바로 구분하기는 어렵죠. 결국 두번째 작업자는
각각의 컨텍스트에 무엇이 오는지를 게임을 다시 실행해보면서 하나하나 알아봐야 각각의 데이터
파일이 무엇을 의미하는지 알 수 있을 것 같습니다.
-------------------------------------------
뭐.. 사실 제 머리속에서만 상상한 거라 실제로는 별 문제 없을지도 모르겠습니다.. 만 한번 생각해 볼
필요는 있지 않을까 해서 문제제기를 합니다. 다른 분들의 의견은 어떠신지요?
whoami
- 2009.12.24
- 10:26:30
새 멤버가 구조체의 가장 마지막으로 들어간다면 예전 컴파일된 필터를 재컴파일 하지 않더라도
제대로 동작하지 않을까요? 뭐.. 제대로 재컴파일 하는게 좋겠습니다만.
아, 그러고보니. 재컴파일 이야기 나와서 생각난건데요. FontMapper 플러그인의 임포트 DLL 을 보면
MSVCR90.dll 과 MSVCP90.dll 이 있는데.. 이거 일반 XP 에서는 VC2008 런타임 패키지를 설치해야
제대로 작동할 겁니다. 아직은 별 오류보고가 없는 것 같습니다만 그래도 알고 계시는 것이 나을 듯.
whoami
- 2009.12.25
- 19:13:17
pPreTransBuf 나 pPostTransBuf 를 보면 void * 형 이라는 것을 알 수 있습니다.
이게 char * 나 WCHAR * 형이 아닌 것으로 봤을 때.. 이 데이타가 0.2 때처럼 "/0 으로 끝나는 MBCS
캐릭터 문자열" 만이 오지 않을 것이라는 것을 짐작할 수 있지요.
그렇다면.. 이 데이타가 어떤 형식인가.. 를 알려주는 것도 있어야 하지 않을까요. 가장 간단한 예로는
"이건 유니코드 문자열이다" 라는 것을 옵션 같은 것으로 알려주어야 하지 않을까 싶군요.
... 그렇게 된다면, 알고리즘 플러그인 쪽에서 "이건 유니코드 문자열이다" 라는 것을 알려줄 방법이
있어야 하는데.. TranslateUsingCtx 의 인자는 LPCWSTR cwszContextName, LPVOID pSrcData,
int nSrcDataLen, LPVOID pTarBuf, int nTarBufLen 밖에 없다는 문제가 생깁니다.
이에 대한 다른 분들의 생각은 어떠신지요? (왜인지, 어려운 문제만 들고 오는 것 같아 죄송합니당 ㅜ_ㅜ)
맞습니다. 순서대로 컨텍스트를 생성하긴 하지만 앞으로 꼭 그렇다는 보장도 없죠.
컨텍스트의 이름을 플러그인도 알 수 있어야 하겠네요.
금방 떠오르는 방법들은 이렇습니다.
1. TRANSLATION_OBJECT 구조체에 cwszContextName이란 멤버를 추가해서, OnInitObject를 호출할 때 여기에 컨텍스트 이름이 세팅되어서 넘어온다.
- 장점 : 구조상 명확하고 단순.
- 단점 : 공통 헤더 변경으로 인한 모든 플러그인 재컴파일 필요
2. 컨텍스트는 TRANSLATION_OBJECT 구조체의 더블링크드리스트로 구성되어 있는데, 이중 헤더의 wszObjectOption 값이 컨텍스트의 이름이다.
[헤더 ] ->wszObjectOption == '컨텍스트 이름'
[Filter 1 ]
[Filter 2 ]
[Filter 3 ]
[테일 ]
- 장점 : 공통 헤더 변경 없음.
- 단점 : 꼼수같아 보이며 장기적으로 봤을 때 별로 좋아보이지 않음
어떤 방식이 좋을지, 또는 더 좋은 아이디어가 있을지 댓글 부탁드립니다.