Dev Talk

음, 제가 후킹한 장소에서는 복구코드를 사용하기 이전에 신형방식으로 하면 무조건 튕기는군요.

이 장소에서 사용하면 안되는 모양이네요.

복구코드 자체의 후킹방식이 신형방식이므로

직접 테스트를 해보지 못하겠습니다.

혹시 리얼라이브를 사용한 곳에서 복구코드를 사용하지 않고

그냥 신형방식으로만 하여도 튕기지 않고 문제없이 번역되는 지점이시라면 [복구코드 사용시 가능한 지점- 전제조건1]

복구코드를 사용해서 ~0x00000005 지점에서 바로 복구하도록 걸고

번역이 안된상태로 나오는지 확인 부탁드립니다.
(즉, 원문을 제대로 복원하여 깨진문자로 출력이 되는지)

포인터가 바뀐그대로여서 출력정지가 되네요.

지금 하려는 거는 아래와같은것을 할려구하고있구요.

테스트는 후킹지점에서 +5로 해보시면 될것같습니다.

+한가지 궁금한점

복구코드 지점이 앞쪽에 있을때는 어떤식으로 입력해야하나요.

//후킹

0F B7 41 01 83 C1 03

아래콜문 // [ebx]

//복구

8B 50 20 8B 4C 24 34 2B 50 18

//재 후킹

83 FE 3F 77 0E 8B D6

분기문 JA 아래지점

+ 공학용 계산기 여시고

HEX 상태에서 100000000 에서 - 하실만큼 입력하여 빼시면 됩니다.

ex. 0x100000000 - 0x5 = 0xFFFFFFFB

정정.

간단히 공학용 계산기 Hex 에서

복사위치 - 후킹위치 나온 결과 값의 8자리를 가져다 기입하시면 됩니다.

=====================================

흠. 포인터도 바뀌는 것이었나요.

리얼라이브 SOW 의 동작 방식을 제대로 보려고 한적이 없어서...

이참에 제대로 확인해보도록 하겠습니다.

제가 사용하는 이 게임에서...복구 위치는 바이너리 검색으로 잡히지 않는군요

후킹지점과 재 후킹지점은 걸립니다.

+ 재후킹지점은 대사 출력시나 세이브시에 아예 지나치질 않는군요.

복구위치는 

해당 포인터를 복원하는

004C6717    8B0B            |MOV ECX,DWORD PTR DS:[EBX]

004C6719    83F9 FF         |CMP ECX,-1

이런 장소에 걸어도 되나요.

포럼에 있는 리얼라이브 게시글중 두번째 스샷 음영들어간부분이 복구지점 이고 재후킹 지점은 두번째 흰색줄입니다.

댓글에보니 찾아가는 다른 방법이 있던데 한번 봐보시길바랍니다.

사용자 편의를 위해 자동확인 체크기능이 디폴트가 되어있는게 맞습니다. 실제 아랄설치후 편의상 자동확인을 해주는게 꽤 편리합니다. 지금까지 여러 os에서 실행 및 확인했지만 말씀해주신 해당버그는 아랄과는 무관한 다른 외부적인 기능 방해이므로 소수의 몇몇 분들 환경 탓에 해당 편리한 기능을 2차적인 설정으로 둬버려서 이에 따른 다수 분들이 이 기능을 눈치채지 못하는것과 비교한다면 지금 그대로가 좋다고 주장하는 바입니다.

어플로캘의 확인창을 패스하는 패치를 했을 경우에 생기는 오류 일수도 있습니다.

저 기능이 생기기전까지 제가 그렇게 쓰다 생기고 나서 옵션을 해제했었죠.

OS환경이 제각각이라 질문하는 분이 자세한 피드백을 하지 않으면 대응이 거의 불가능하죠.

그런 패치도 있었다는건 처음들었습니다;

확실히 그런경우라면 문제가 생기겠네요.

원래 개행번역 자체가

니트로 및 기리기리 등과 같은 스크립 전용으로

해당 부분은 번역으로 넘어오지 않게 하였습니다.

니트로에서 사용되는 명령어들이 픽스와 디나이에서 전부 처리하기가 말도 안된다고 판단되었기 때문에

고의로 {와 }사이의 문장은 무시하도록 하였습니다.(+ // 이후의 문장은 주석이므로 해당라인도 무시)

(개행분할번역 사용시 픽스에서 어디서 부터 어디까지에 처리가 다음과 이전문장에 걸처서 처리되지는 않으니까요.)

하지만 선택지 같은게 저 중괄호 사이의 명령어에서 나오더군요;

제외하는건 간단하지만

한번 테스트를 해보시기 바랍니다.

ATCode.zip

몇번정도의 명렁어는 간단한 픽스로 넘어갈 수 있지만

2줄 이상의 걸처서 하나의 명령어로 이루어진 경우는 픽스의 한계가 될것입니다.

여러게임에 테스트 부탁드립니다.

- ATData.zip 에 대해서

보통 파인더가 아닌 일반 유저들은 일단 데이타파일을 받아서 넣고 난 뒤에 코드를 적용시키지 않나요?

그렇지 않으면 게임 진행이 안될텐데..  ATData.zip 의 파일들이 풀리는 시점이 아랄트랜스가 후킹하기

바로 직전이니까 픽스라인이 새 파일을 만들지 않았을텐데요.. 코드부터 적용하고 ATData.zip 을 나중에

넣으면 데이타파일이 자동생성되는 경우 당연히 파일이 덮어쓰기될 수 밖에 없지요.

일단 간단하게 생각할 수 있는 방법은 데이타파일 자동생성이 되는 플러그인을 고쳐서 자동생성 기능을

막아버리는 방법이 있겠군요. 대신 옵션창에 "데이타파일 생성" 버튼 같은 것을 넣어서 누르면 만들어지도록

한다거나.. 혹 다른 아이디어 있으시면 적어주세요.

보통은 그렇습니다.

위 두통님이 말씀하는건 아주 극히 일부의 유저가

급한마음에 코드랑 필터부터 기입하고 바로가기를 생성한뒤

ATData.zip 만 넣고 실행하는 분도 어쩌다 있으니까요.

(정말 극소수의 인원이기 때문에 무시해도 되는 레벨이라고 판단됩니다)

근데 ATData 의 파일의 내용을 날짜 우위로 판단했던가요?

저번에 보았을때 그런 부분은 없던걸로 알고 있습니다만( 아닌가요? )

그리고 자동생성의 버튼을 따로 만드는 것은

지금의 UI도 심각한데 더욱 지저분해질것으로 보이므로 반대표를 냅니다.

넵. 날짜체크 합니다.

BOOL CAralGoodDlg::ExtractATData(void)

 {

    ... 중략 ...

    // 파일의 작성시간을 읽어온 다음
    TimetToFileTime(pfhInfo->GetTime(), &ftimeZippedFile); // 압축파일
    GetFileTime(hFile, &ftimeC, &ftimeA, &ftimeW); // 로컬파일

    // 압축파일 내의 파일이 로컬파일보다 최근이면 해당파일의 압축을 푼다.
    if (CompareFileTime(&ftimeZippedFile, &ftimeW) > 0)
     bNeedToExtract=true;

    ... 중략 ...

}

BOOL CAralGoodDlg::ArchiveATData(void) 도 비슷한 방법으로 최신 파일을 자동압축해 보관합니다.

+ 쉼표, 마침표, 느낌표, 물음표 는

커스텀 딕으로 해당 일어 2바이트 문자들을

한글 2바이트 문자로 넣으면 해결될것으로 보입니다.

따라서 따로 기능으로 넣는건 부적절하고 판단합니다.

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

코필터 자체에 이미 Deny와 Allow 기능이 있습니다.

ATData 내에 KoFilter.dat 을 생성하여 패턴을 기입하시면 처리됩니다.

(기입방법은 DenyWord 하고는 틀립니다 해당 사이트에 문서들을 찾아보시면 사용법이 있습니다)

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

픽스라인이 튕긴이유는 8140이 연속으로 2번 나와서

픽스 패턴 생성시 연속적인 오류에 인한 결과입니다.

애당초 그렇게 사용하는건 좋은 방법이 아니라고 판단합니다.

그래도 사용하시겠다면 아래와 같이 사용하셔야 올바른 사용방법입니다.

앞에 8140이 여러개 나올것을 감안해서

8140  (번역안함)

8140  (번역안함, 무시) <--이것은 앞에 여러개의 8140이 올것을 감안해서 생성될것만 같은 개수만큼 한줄씩 여러번생성 (아래와 같이)

8140  (번역안함, 무시)

8140  (번역안함, 무시)

8140  (번역안함, 무시)

....

{T}  (번역안함)

위에것을 기본이 아닌 본문전체 의 옵션으로 생성한다.

결론, 픽스라인 오류가 아닌 사용법의 미숙지.......

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

앨리스 소프트 튕기는 쪽은 다시 확인 부탁드립니다.

스마트를 사용한 드라큐리옷에서도 백로그가 튕긴다는 제보 때문에 2차 수정본으로 해당 게시판에서도 수정했지만

이에따라 앨리스도 아직까지 계속 튕기는지 재확인 부탁드립니다.

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

니트로 엔진은 어느 포인터에 코드를 거셨는지 모르겠으나

니트로엔진 기능 자체가

<PRE> 부터 </PRE> 를 가리키는 2개의 포인터가 담긴곳을 후킹하였습니다.

그 2개의 포인터 생성은 니트로 엔진쪽에서 자체적으로 담당한 것이므로

아랄에서의 </PRE> 의 포인터를 뒤쪽의 세미클론영역으로 옮겨버리면 에러가 날것입니다.

니트로 엔진 자체에서 스크립트명령어 시작과 끝을 부분적으로 불러 포인터로 쌓아 열거하는 형식이기 때문에

<PRE> 에서 시작했는데

</PRE>가 아닌 이상한 명령어에 세미클론 달린 영역을 가리키는건

일단 말 자체가 되지 않습니다

문장부호는 커딕대체시 좌우로 20 이 붙어서 보기않좋아서 문의드려봤습니다.

(커딕의 노마진 번역플러그인의 중복스페이스제거도 안먹힙니다.)

픽스라인 미번역으로 인해 코필터가 정상작동하지 않을때 사용하기위해서. 픽스라인 미번역문을 무시하자는 말이였습니다.

코필터데이터하는 allow [ 문자+길이] 디나이 [이건 디나이 [eaxct] 일것같아서 사용을 안해봤슴]

위 두가지 기능에 더해서 코필터에서 한글인지 일문인지 무시하고 계산하라는

무시문자 데이터를 넣었으면 어떨까하는 문의였습니다.

픽스라인에서 8140문이 아니라 다른문을 패턴사용시였습니다.(위 덤프스삿에서 제가 임의로 넣은 패턴은 8140 뒤에 있는 요시,~)

결국패턴을 사용할시 항시 8140 8140 문에 대한 예외 조항을 넣어줘야 한다는 결론인데요.

저러한 8140 예외조항없이 픽스 에러안나게 할수 없을까하는 문의였습니다.

니트로엔진은 한글자 지역을 후킹하지 않는이상 필히 파일수정이 있어야하기때문에 중요하진 않는내용인데요.

현재 읽어들이는게 </PRE> 앞에까지 읽어들여서 번역후 시작위치와 종결위치를 넣어주는것같은데

읽어들이기를 </PRE> 뒤에있는 SetText(); 여기가지 읽어들여서 후킹한 메모리가 가지고있고

종결위치를 </PRE> 위치로 잡아줘야 좀더 넓은 지역에서 니트로엔진방식을 사용할수있다는거였습니다.

대부분 종결문포인터 뒤쪽의 SetText(); 까지 검사해서 출력을 결정합니다. 유일하게 검사안하는곳이 있지만

그곳에서는 단문 뒷문이 짤립니다.

+ATData.zip 과 픽스에서 필터추가시 자동데이터생성을 안하고 설정시 자동데이터 생성을하면 어떨까합니다.

극히 일부라고 언급하셨지만 상당수가 우리가 생각하는것과 반대로 행동하고 질문이 올라옵니다.

앨리스소프트 저한테는 문제가 없어보이는데 꾸준히 올라오네요. 

추가로 문제가 제기된게 드라큐리옷 버그수정 업데이트 이후인것같습니다.

니트로 명령제어문 관련은 현재 파일수정으로 해결했습니다.

포럼게시판 > 니트로 후기 > CMP DL,7B 부분과 맨하단쪽 위쪽에 수정방식이 나와있습니다.

니트로 확인했습니다. 감사합니다

추가2 부분

코필터 데이터에서 하는 방식은 디나이의 EXACT 와 유사합니다.

데이터와 길이값이 일치하면 코필터 통과하는 기능입니다.

위에서 예로 든 방어의 어가 코필터에서 걸리는부분인데

어 만 올로우하더라도 코필터에걸리고

마법방어나 방어술등이 지나간다면 코필터에서 걸릴겁니다.

제가 위에서 제기한건 코필터에서보면 로마숫자 원문자 무시기능의 확장입니다.

픽스에서 8175를 미번역했을시 코필터에서 저러한 미번역문에 의해 정상작동이 안될때가 있습니다.

그래서 이러한기능이 있으면 어떨까하는 문의였습니다.

필터위치로 해결가능하지 않느냐는 의문이 들수있는데 안되는경우도 있어서 문의드려봤습니다.

추가3

이건 스마트 후킹의 호불호의 논의와는 다르게 업데이트이후 발생하는 튕기는 원인에데해서 논의하는거라

저번에 논의와는 약간 다릅니다.

앨리스소프트 게임있다면 한번 테스트해보고 결과를 올려주면 개발진에게 약간이나마 아마 도움이 될듯싶습니다.

앨리스 소프트 후킹 코드 다 찾지 않았나요?

게임 이름을 지정해 주시면 찾아보도록 할게요.

궁금한게 있는데, 8175를 왜 미번역 해야 하는거죠? 「 이거 아닌가요?

8175는 코필터 픽스 넣어도 미번역 되지 않나요?

코필터의 경우는 Deny는

포함되는 단어의 일부가 있을경우에는 번역하지 않게 하고

Allow 에는 정확히 일치할 경우에만 번역해라

라는 정도로 밖에 쓰이지 않습니다.

원하시는 바는

픽스라인에서 미번역과 번역의 나오는 특수기호의 구분을 두고

코필터에서 번역값과 미번역 값의 구분된 계산을 해달라는 것인가요?

코필터에 보면

로마숫자 사용안함 / 원문자 사용안함  요러한 체크박스가 있잔아요.

아마도 저 기능이 일문/한글 카운트시 제외시키고 카운트한다고 생각을해서

저런식으로 코필터 데이터에 값을 넣어서 카운트에서 그냥 영문처럼 일문/한글 카운터에서 제외시켜버리는 기능이있으면

픽스미번역쪽을 일문으로 카운트를 안해버리니 픽스+코필터 효율이 올라가지않을까해서 문의드려봤습니다.

실상 자주쓰이는 기능은 아닐듯합니다만 제 생각이 맞다면 필터수정을 조금해서 위와같은 기능이 구현된다면

좋겠다고 생각했습니다.

+윗글에보면 개행분할번역 {} 자체무시(x) 테스트용으로 ATCode.dll 올려주셨잔요.

요 버전까지는 문제가없는데 현재버전에서 스마트 사용시 튕기는 현상이 보입니다.

테스트로는 NeXas 기반 마지코이A-2

튕기는 구간쪽은 예전에 설정창사용시 ptrbackup 기능을 사용해야 튕기지않았던 설정창부분

스마트 / 스마트+복구 두가지 모두 튕기는걸 확인했습니다.

아하.

코필터에서 최초 미번역 문장이 왔을때는 픽스 위에 있을시

제대로 거르지만

픽스를 지나고

번역문이 다시 코필터를 올때 

픽스의 기호인 _/_ 같은 문자 탓에

한글의 카운터가 제대로 이루어지지 않겠군요.

이점에서 보면 사실

미번역은 코필터가 선행되고

번역문은 픽스 아래에서 처리되어야 올바른 처리법이네요.

음....

필터의 추가된 리스트를

미번역(전처리)와 번역(후처리) 의 필터 순서를

공통 순서가 아닌 따로 따로 지정할 수 있으면 좋겠군요.

좌우로 구분해서 전처리 필터순서, 후처리 필터순서 로 말이지요.

이러면 전처리에서는 코필터가 상위에, 후처리에서는 코필터가 픽스하단에 넣으면

말씀하신 문제는 해결되리라 생각됩니다. 맞나요?

+ 문제점이 저 버전에서 되고 드라큐리옷에서 설정한 부분에서 튕긴다는 얘기군요.

어디가 문제인지 감이 잡힌것 같습니다.

제보 감사합니다. 빠른시일내에 업데이트 해보겠습니다.

중복번역시에 코필터를 사용하는데  만약에 の 를 미번역시 처음엔 문제없고

두번째올때 나の 친구 // 이처럼 문장이 오니 코필터에서 일본어가 있으니 효율이 떨어지는겁니다.

그래서 の를 무시 문자로 등록할수있다면 // 한글 3 일문 0 이런식으로 카운터가 되어서 코필터 효율이 오르겠구나 생각했습니다.

실상 픽스에서 패턴 미번역하는건 주로 「【《 요러한 특문 미처리를 하는데

이때 위에서 제기되 8140 미번역을 추가해줘야하고 문제는 저 8140 이 코필터효율을 떨어지게합니다.

그러하긴한데 간단히 기능추가가안되고 위처럼 일이 커지는거라면 자주 사용되는 방식은아니니

그냥 놔두는게 나을것같습니다.

//필터 전처리 / 후처리 순서를 정하는게 나름 매력적으로 보이지만 너무 복잡해질것같습니다.

+번번히 죄송하긴한데

울프툴/마지코이A-1/란스퀘스트 매그넘

게시글 권한좀 주세요. 아이디를 삭제한후 번번히 질답게에 올라와서 수정을 조금 해야할듯합니다.

아... 그런 처리를 말씀하신거로군요.

지정한 글자, 단어, 문장 등을 체크 카운터에서 제외하란 소리로군요.

하지만 픽스라인 다음 코필터를 놓을때

픽스에서 번역안함 처리로 미번역을 지나가면 

_/_ 인가의 특문이 생겨서 체크 카운터가 이미 깨진상태로 가고

번역문장이 올때는 제대로 복구해서 _/_가 없고 원문이 있을테니

제대로 카운트가 되겠지만

근본적인 해결이 역시 되지 않습니다.

따라서 원하시는 바를 구현하려면 아래와 같이 2가지가 시행되어야 합니다.

1. 코필터에서 카운트 제외문자 지정(원문 제외 문장 혹은 번역 제외 문장. 구분하여 카운트에서 제외 하도록)

2. 필터 순서 원문, 번역의 개별 지정(ex. 원문시  코필터 - 픽스 순,    번역시 픽스 - 코필터 순)

이 2가지가 구현되어야 원하시는 결과가 정확히 나오게 됩니다.

+ 링크와 폴라리스 id(혹은 닉네임)을 적어주세요.

대부분 코필터를 픽스 위에 두고쓰는데

이때 무시기능이 있다고하면 코필터 단계에서 중복번역으로 되돌려보내니 해결되지않을까요..

란스퀘스트 매그넘 , ランス・クエスト マグナム

울프툴 , WOLF RPGエディター

[XP only]마지코이A-1 , 真剣で私に恋しなさい！A-1

닉네임은 같구요

id는 eros

필터의 순서와 원문, 번역문의 참조 순서를 생각하셔야 합니다.

코필터가 위로 간다면 원문에서는 처리가 되지만

번역문에서의 카운트가 픽스의 _/_ 탓에 망가지기 때문에 제대로된 처리가 되지 않습니다.

위에서 말한건 이것과 반대로

픽스가 위에 있을때 원문에서의 처리가 _/_ 탓에

원문의 카운트가 망가진다는 소리입니다.

요는 필터의 원본, 번역문의 합친 순서 때문에 코필터만 고친다고 해결될 문제가 아니라는 이야기었습니다.

이것저것 질문... 근데 여기다 이런거 계속 올려도 괜찮나요..

+ 현재 ez 번역플러그인 기본셋팅 중복스페이제거 미체크

요거 그냥 체크로 해도 되지않을까요.

대부분 xp 유저 / 단순사전 / 쉼표 좌우로벌려 번역/

저거 미체크와 체크시 크게 먼가 변화를 주는것같지는 않아서 한번 건의..

Qlie 노란색 오류 보고가 종종 올라오기도하고 편의상 낫지 않을까 싶기도해서요.

+커스텀딕 옵션중에서 노마진 옵션 현재 정상적으로 작동하는건가요..

체크/미체크시 변화가 안보여서 혹시나해서...

+유니코드 + ENCODEKOR + 픽스에 대한 잡생각...

현재 유니코드는 encodekor 옵션이 적용안되는데 저걸 적용시켜서 아랄에서 번역문 뱉을때

일본어로 변환후 내뱉고 출력시에 다시 한글로 변환 적용시킨다면 유니코드+픽스라인 패턴 조합 효율이 오르지않을까나 하는 생각이 문득 들더군요.

+강좌&팁 게시판 기본 소트중 최근수정 소트가 정상적으로 안되는듯합니다.

요즘 지나치게 여유롭다보니 이것저것 잡생각들이 쏟아지는군요. 쿨럭....

중복스페이스제거  건은 저도 체크를 디폴트로 하고 해당 란을 지우자는 것에 동의합니다.

커딕의 노마진은 소스를 봐야 알듯 싶습니다.

유니코드 일본어의 자리에 한글유니코드를 폰트 매핑하란건가요.

그래보아야 사용될 곳은 유니코드형 일어체크 정도만 회피하는 것으로 사용될것이고

픽스와는 전혀 관계 없습니다.

필터란에 가는 문장은 무조건 아스키 문장으로 갑니다.

(번역문이든 미번역문이든)

+ 최근수정 소트 되는 것 확인했습니다.

공지사항은 소트 되지 않습니다. 공지가 너무 많아서 안되는 것처럼 보신듯합니다.

기존 작성글은 되는데요 새로 작성된글에서 소트가 정상적으로 안되는것같습니다.

7/6일 게시 7/8일 최근수정일인데 최근수정이 요놈이 현재 최상위인데 소트가 안되더라구요...

+유니코드형 우선은 죄다 아스키로 변환후 번역및 필터를 거치잔아요.

그리고 아랄에서 내뱉을때 한글유니코드형으로 변환해서 내뱉구요.

근데 여기서 ENCODEKOR 옵션이 적용된다면 아랄에서 내뱉을때 일본유니코드형으로 내뱉게되고

이러면 픽스라인 미번역 패턴을 살릴수있지않을까요

(현재는 픽스라인 미번역 패턴이 유니코드형에서는 한글유니코드변환후 아랄에서 내뱉기때문에 사용불가지만)

+3개의 코드게시글 수정이 아직안됩니다.

DB가 제대로 깨져서 복구할 자신 없습니다.

+ 기능을 이해하시는데 오해가 계신듯 합니다.

ENCODEKOR 은 아스키에서 사용할때

일본어 폰트셋의 사용되는 문자 공간에 한글을 1대 1 매칭 시켜 일어출력시 출력단에서 한글로 출력합니다.

여기까지는 알고 계신다고 생각합니다.

유니코드는 아스키와의 변환에서 코드페이지가 쓰이는것 또한 인지하고 계실때

일본유니코드형으로 내밷으면 역으로 한글이 깨진다는 점을 알아주세요.

그렇다고 1대 1매핑방식으로 한글을 일어로 바꿔버리면

이 역시 마찬가지로 미번역 패턴인 원문마저 재변환될것이므로 크게 깨지게 됩니다.

그리고 ENCODEKOR 에서는 한글이 너무 많기 때문에

일어가 들어갈 장소 따위 없습니다.

따라서 미번역 패턴이 된 문장은 1대 1매핑이 불가능하기 때문에 그대로 두게 되고

해당 미번역 패턴을 재변환시에는 뷁괧 같은 깨진문자가 될것입니다.

요는 해당 방법은 적극적이지 못합니다.

개인적으로는 모든 필터를

아스키형과 유니코드형의 처리를 개별적으로 지원하는것이 좋다고 생각합니다.

코드상에서 아스키일경우 아스키로 필터로 내보내고

유니코드일경우는 번역한것을 유니코드로 내보내서

필터단에서 유니코드 문장을 처리한다면

해결됩니다.

혹은 다른 방안으로는

일한 체크를 글자 단위 처리로 바꾸어

아스키->유니코드 변환시

글자마다 일어, 한글 변환을 이행하는방법도 있지만

한글과 일어의 중첩된 지역의 문자일 경우는 판단의 방법이 없게 됩니다.

+3개의 게시글 해당 계정으로 권한넣었습니다.

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

이전댓글

Q: 이것저것 질문... 근데 여기다 이런거 계속 올려도 괜찮나요.. 

A: 연구개발에 관한 대화이니 문제 없다고 생각합니다.

이 글이 생각나서 테스트 결과 올립니다. 이 코드도 드라페코 튕깁니다. 막장 알파루트를 상대로 테스트 해보았는데 이벤트 cg나오는 장면에서 걸리는게 있는것 같네요.