Razor

00 한눈에

이 문서에 걸린 질문은 Open items.

01 이 포크

• Outlands 클라이언트의 Razor = Razor CE 포크. CE에 없는 명령 다수
• 근거 우선순위: 위키 Razor Scripting 먼저, CE 가이드는 기본 문법 확인용
• 공개 스크립트: outlands.uorazorscripts.com

02 확장 문법

Razor CE에 없거나 CE보다 넓어진 것. 존재 여부만 기록, 인자 형식은 위키에서 확인.

02.A 고정 문구 검사와 타겟 커서의 한계

• Razor CE 표현식의 insysmsg: 고정 문구 검사
  • 이름이 든 문구도 리터럴 그대로(insysmsg "xuezhonglian has applied telekinesis to you."). 문자열용 setvar 불필요
• Outlands Razor Scripting의 name 표현식
  • Journal에서 시전자 이름 추출, 이름 변수를 메시지 검색 문자열에 붙이기의 증거는 아님
  • 이 조합은 인게임 미검증. 이름은 고유 serial도 아님
• 메시지 존재, 새 메시지 도착, 현재 타겟만으로 서버 응답을 특정 시전 요청에 묶는다고 가정 금지
  • TK를 받을 때와 걸 때 같은 안내가 나오는 사례: PvP 04.D절
  • clearsysmsg가 다른 루프의 신호까지 지우는 경쟁도 있음. 초기화만으로 모호함 해소 불가
• Razor CE 명령의 targetrelloc: 폭발 포션 지면의 안전, LOS와 높이, 폭발 반경은 보증 안 함
• targetexists만으로 포션 커서인지 회복 주문 커서인지 판단 금지. 커서를 연 행동과 소유권을 함께 추적

이 절은 문서로 확인한 문법과 설계상 제한. 새 실행 선례나 포션 복구 성공의 증명 아님.

02.B findlayer의 레이어

“The valid layers are:” — 위키 Razor Scripting, findlayer

righthand lefthand shoes pants shirt head gloves ring talisman neck hair waist innertorso bracelet face facialhair middletorso earrings arms cloak backpack outertorso outerlegs innerlegs onehandedsecondary quiver outerbody

• 27개. 장비는 hair, facialhair를 뺀 25개 → gear/dress 블록이 모두 다룸(restock/loadout, hotkey/regear)
• Outlands가 더한 페이퍼돌 부위는 findlayer 이름이 없음 → 레이어로 훑는 스크립트는 못 봄
• Razor의 Arm/Dress 목록은 담음. Add Current로 gold rim glasses(Eyewear), gravediggers lantern, tidal tomb travel pack이 목록에 들어감. 인게임 확인됨 2026-10-18
  • 목록은 아이템 serial을 담음 → 장비를 바꾸면 Razor 화면에서 다시 담아야 함. 목록을 고치는 스크립트 명령은 없음(Razor CE 명령)
  • 실행은 스크립트로: CE 문법 dress ('name of dress list'). 목록이 없는 프로필에서는 오류 없이 지나감인게임 확인됨
  • 그 목록의 Dress가 이 부위 아이템을 실제로 다시 입히는지는 확인되지 않았다
• 이 저장소의 방식: 모든 프로필에 Arm/Dress 목록 cosmetic. 이름 없는 부위의 아이템만 손으로 담음
  • hotkey/regear가 레이어 25개를 다시 입힌 뒤 gear/cosmetic 블록에서 dress 'cosmetic'
  • 일반 부위를 담지 않는 이유: 장비를 바꾼 뒤 목록에 남은 옛 장비가 백팩에 있으면, 켜져 있는 Auto-move conflicts가 새 장비를 벗기고 옛것을 입힘
  • 2026-10-18 summoner의 목록 nomeehej 16개 중 이름 없는 부위 셋만 남겨 cosmetic으로: tidal tomb travel pack with bedroll(Back), gold rim glasses(Eyewear), gravediggers lantern(2H Secondary). default는 빈 목록. 부위는 Drip 데이터 기준

Outlands Drip의 부위와 대응. 부위 이름은 2026-10-18 사이트 번들에서 읽음.

• Drip의 Neck은 고짓 같은 목 방어구. 목걸이는 따로 Necklace 부위

03 확인된 함정

.razor 수정 전 이 절의 표 확인. 대부분 인게임에서 깨졌거나 프로브로 잰 것. 선례 없음, 미확인은 증상 칸에 표시. 긴 근거는 05절, 비용 숫자는 06절.

오류가 나는 구문

중첩 반복의 조기 종료

조건과 변수

검색

거리 확인과 Last Target

• 수동으로 고른 플레이어 대상은 find로 거리 확인 불가 → 완료한 주문 커서는 Razor Last Target 거리 검사로 유지 가능
• Razor CE Options: Range check Last Target이 켜져 있으면 범위 밖 대상 요청 거부, 커서 유지. target serial의 거리 검사까지 보증하지는 않음
• 이전 bard-necro-pvp는 이 경로로 Explosion과 후속 EB 요청. 지금 루프는 공격 수동(PvP Loop)
• 커서가 닫혔다는 것만으로 명중, 거리, 취소 확정 금지
• 지금 Outlands 클라이언트에서 거리 밖에서 안으로 들어올 때의 전환은 확인되지 않았다. 확인 항목: Open items 08.B절
• 공통 PvP v5: 아이템, 자기 주문, 장비 중 하나를 처리하는 조건 사슬 후 다음 패스. 반복문 안 break, continue 없음. 새 본문 동작은 아직 확인되지 않았다

커서와 타겟

장착과 손 도구도 지금 포크의 실제 결과 기준.

• CE dress 문서: serial 장착 지원
  • 벌목 본문의 dress alias__spare_hatchet: 백팩에서 찾은 도끼에 not found 반복. 인게임 확인됨 2026-10-05
  • Outlands에서의 실패 원인은 확인되지 않았다 → 벌목은 기존 무기 핫키처럼 lift 후 drop self lefthand
• v9: 빈손인데 백팩 도끼 미장착 보고. 인게임 확인됨 2026-10-05
  • findtype … self의 실제 반환, 실패한 가드는 기록 없음 → 검색 범위를 원인으로 확정하지 않음
• v10: bard-mace의 장착 선례처럼 lhandempty 먼저
  • 캐시 serial 장착 후 findlayer self lefthand 결과가 그 serial과 같아야 도구 사용
  • CE 공식 문서도 lhandempty를 빈손 표현식으로 설명. 이 경로의 실제 장착은 아직 확인되지 않았다
• CE UseItemInHand: 오른손 먼저 사용 → 왼손 Hatchet만 확인하고 일반 손 사용 핫키를 부르면 오른손의 다른 도구 사용 가능
• CE Queued 표현식: 행동 큐가 비었는지 검사
  • 도구 사용 후 커서가 떠도 큐가 남으면 not queued 때문에 자기 타깃을 건너뛸 수 있음
  • 벌목 v8: 손 도구 직후 같은 블록에서 3000ms까지 커서 대기, 중립 커서면 자기 타깃
  • 대기 명령이 실행 흐름을 붙잡음 → 별도 pending 상태, 다음 패스 커서 처리 블록 없음
  • 큐가 실제 원인이었는지는 아직 확인되지 않았다
• v8 기본 채집: 사용자 보고로 정상. 인게임 확인됨 2026-10-05
• v10: 오른손 제어 추가 없음, 실제 왼손과 캐시 serial 비교. 새 장착과 교체 경로의 확인 항목: Open items 09절

insysmsg의 소비 범위:

• CE 원본 SystemMessages.Exists: 맞은 최신 줄과 그보다 오래된 줄을 함께 지움
• 한 줄에서 거리 문구와 발견 문구를 따로 읽는 구조 회피, 중요한 경보 먼저
• Outlands 포크에서도 같은지는 인게임에서 확인되지 않았다

타겟 주문 한 번의 모양: 04절 끝.

03.A 대상 조회 진단 핫키

• 용도: 몬스터에서는 되던 조회가 플레이어에서 실패할 때의 단발 진단
• debug-target-find: 검색
• debug-target-state: 상태, 변수 비교, 시전 전 조건
• 주문, 공격, 소환수 명령은 보내지 않음
• v1의 alt 검색, NPC 검색, 상태 조회는 인게임 확인됨 2026-10-04
• 실행별 반환값과 아직 안 한 검사: 아래 결과 표

같은 조건으로 비교하기

1. 전투 스크립트 Stop. pvp=0 일반 필드에서 조회가 되던 몬스터와 alt 비교
   • 검사 중 서로 이동, 타겟 변경 금지. pvp=1이면 제한된 결과가 섞이지 않게 진단 중단
2. Scripts 탭 Reload all scripts → debug-target-find Play
   • TARGET FIND PROBE v1 loaded, [ target, pick ] → 가까운 몬스터 타겟
   • F END까지 나오면 같은 거리의 alt로 반복. 시작 문구가 없으면 비교 전에 캐시 확인
3. 가능하면 2칸 안, 3~5칸, 6~10칸, 11~12칸, 13~18칸에서 반복, 실제 거리 기록
   • 넓은 범위에서 찾은 대상을 좁은 범위에서 놓치는지 비교. 기본 검색부터 실패면 거리 판정 불가
4. 마지막 대상과 변수 경로 비교: 먼저 Q로 같은 대상 지정. 2026-10-20부터 Q는 Set Last Target (Harmful)이라 진단도 lastharmful을 읽음. 그 전 결과는 lasttarget 기준
   • find 본문의 config__probe_find_use_last_target를 1로 → 새 커서 없이 그 serial로 실행
   • 기본값 0: 직접 찍은 serial과 Q serial이 다르면 F11 건너뜀
5. Q로 같은 대상 선택 → debug-target-state Play
   • TARGET STATE PROBE v1 loaded부터 S END까지의 제한 경고와 결과 함께 확인
   • 기본 Q 모드는 기존 주문 커서를 취소하지 않음. 시전 전 조건은 새 타겟 커서 요구 전에 읽음

핫키 실행의 캐시 반영, 종료 후 git status: Workflow 04.A절, 04.B절.

검색 번호

• F14, F15는 기본 SKIP. 대상 >info의 graphic ID나 body ID로 config__probe_find_body의 0을 바꾸면 실행. serial 칸 아님
• find 진단은 시작 시 남은 커서 취소, ignore 목록 비움. 바디 검색 중 임시 ignore도 끝나면 비움

상태와 변수 번호

• state 진단의 config__probe_state_use_last_target 기본값 1. 0이면 새 대상 타겟, 이미 시전 중이거나 커서가 있으면 중단
• 설정과 세션 변수: config__probe_find_*, config__probe_state_*, var__probe_find_*, var__probe_state_*
• alias, label도 probe 이름으로 따로. 추가 타이머 없음

실패 로그 읽기

• BEGIN 다음의 TRUE, FALSE, RETURN, LABEL = 명령의 반환
• FALSE만 있고 제한 경고 없음 → 검색 실패 관찰만 기록. Skipped, Cannot check 같은 경고 → 조회 제한으로 기록
• Script Error, 결과와 END 없음 → 마지막 BEGIN 번호와 오류 줄 번호가 멈춘 지점
• 두 진단은 별도 파일 → 하나가 멈춰도 다른 파일로 나머지 비교 가능

2026-10-04 v1 진단 결과

사용자가 올린 alt 로그와 NPC 로그 비교. 양쪽 모두 find 진단과 state 진단이 END까지 실행, Script Error 아님. 인게임 확인됨 2026-10-04.

• NPC 거리 필터: 2칸에서 놓침, 5칸 이상에서 찾음. 실제 거리와 이동 여부 미기록 → 정확한 칸 수 미확정
• alt: 거리 인자 없는 기본 검색부터 실패 → 거리 초과로 판단 불가
• 검색에서 플레이어가 빠지는 내부 이유(의도한 필터인지 결함인지)는 확인되지 않았다
• NPC: ignore 등록 후에도 serial 직접 검색 성공 → 이번 테스트의 find serial은 ignore 등록만으로 빠지지 않음
  • ignore 기능 전체 고장으로 일반화 금지. findtype에 ignore가 먹는지는 이 프로브에서 미검사
• alt 상태 진단: pvp, casting, cursor, walk cooldown 0. TK와 dump의 마나 조건, TK 시약 두 가지 1
  • 기존 TK 재시도 타이머 ready=1, me 바와 target 바 0
  • 진단 시점의 값. 전투 루프의 대상 캐시, 자기 회복, 버프 우선순위, Explosion과 EB 시약 전체 통과의 뜻 아님
• find의 직접 선택은 Q(Last Target)를 바꾸지 않음. state 기본 모드는 Q를 읽음
• NPC 상태: Q를 NPC로 바꾼 뒤 selected=885491 실행에서 확인
• 상태 조회 비교 시 캐릭터 이름 대신 context의 selected serial로 검사 대상 확인
• alt의 바디 findtype, 여러 거리 반복 결과는 확인되지 않았다

04 되는 구문과 선례

모두 저장소에 선례 있음. 새 패턴 전에 여기서 먼저 찾음.

타겟 주문의 모양

magery/rotation의 타겟 주문 모양.

1. 패스의 첫 커서 폴링 전에 남은 끊김 줄을 한 번 읽어 비움
2. 대상을 find … as로 찾은 블록 안에서 cast. alias는 블록 밖에서 못 읽음 → target까지 모두 안에
3. for 60 폴링. 커서, 끊김 줄, 긴급 HP 중 먼저 온 것에서 break. HP 때문이면 hotkey "> Interrupt"로 제 시전 먼저 끊음
4. 커서 없음 → 아무것도 안 찍음. 커서 있음 → lastharmful 재확인
   • 대상 사망, 플레이어의 대상 변경 → Cancel Current Target
   • 그대로 → target, wait wait__cast

flowchart TD
  drain("남은 끊김 줄을 읽어 비운다<br>패스의 첫 커서 폴링보다 먼저") --> cast("find … as로 찾은 블록 안에서 cast")
  cast --> poll("for 60 폴링<br>커서, 끊김 줄, 긴급 HP 중 먼저 온 것에서 break<br>HP 때문이면 Interrupt 핫키로 먼저 끊는다") --> cursor{"커서가 떴나"}
  cursor -- 예 --> reread("lastharmful을 다시 읽는다") --> same{"대상이 살아 있고 그대로인가"}
  cursor -- 아니요 --> none("아무것도 찍지 않는다")
  same -- 예 --> hit("target 대상<br>wait wait__cast")
  same -- 아니요 --> cancel("Cancel Current Target")

05 안 되는 구문의 근거

03절 표의 긴 근거, 표와 같은 순서. 선례가 없어 쓰지 않는 것은 맨 끝.

• for <변수>: Invalid for loop syntax(프로브, 인게임 확인됨 2026-09-28). 횟수는 리터럴만. 변수 횟수가 필요하면 값마다 for N 사슬
• while not list 'x' >= var: syntax error, 파싱 불가인게임 확인됨 2026-09-28. not 뒤에 list 비교식 금지
• findtypelist를 명령으로: Unknown command. 쓴다면 findtype처럼 if 안의 표현식일 것, 확인되지 않았다
• 중첩 반복에서 if 안의 break
  • CE Script.ExecuteNext의 BREAK: 반복문 뒤로 이동, 현재 범위는 PopScope 한 번으로만 지움
  • if 범위만 지워지고 안쪽 반복 범위가 남으면 바깥 FOR가 새 진입으로 보고 index를 0으로 되돌릴 수 있음
  • 2026-10-05 CE 원본 제어 흐름 재현: for 2 안의 for 1에서 if를 거쳐 break → 바깥 반복이 0단계 반복
  • lumberjack v12 본문도 Logs 단계만 반복, END 미도달
  • CE 소스 재현일 뿐, Outlands 내부 구현도 같다는 인게임 확인 아님
  • 이전의 재귀형 모의 검사는 이 경우를 Python의 정상 반복 종료로 처리해 차이를 놓침
  • v13 목재 정리에서 이 경로 제거. 다른 기존 루프의 일괄 변경, 모든 break 실패로의 일반화는 하지 않음
• 변수가 왼쪽인 크기 비교: var__symbols >= config__symbols_blood_oath처럼 변수끼리, 변수와 숫자의 크기 비교. 조건에서 변수는 =, !=만
  • Razor CE EvaluateBinaryOperand와 CompareOperands: session 변수를 문자열로 읽고 오른쪽 값을 왼쪽 자료형으로 변환
  • → var < 0x40000000은 숫자 범위 검사가 아닌 문자열 비교가 될 수 있음
  • Bard Necro의 네크로 능력이 한 번도 안 나가던 원인. 조건이 조용히 거짓
  • 2026-10-04 전체 루프의 var < 0x40000000 경로도 대상 저장 전에 멈춤
    • 순서를 바꾸자 같은 Q serial에서 mobile=1, 대상 저장, TK, Explosion에 이은 EB 피해까지 나옴. 인게임 확인됨 2026-10-04
  • CE 소스의 변환 방향에 따라 serial 범위 검사는 0x40000000 > var. 이 값은 Serial.IsMobile의 모빌과 아이템 경계, 개인 serial 아님
    • 이 순서의 모빌 판정은 지금 클라이언트의 alt 테스트에서 확인. 내부 자료형 전체가 CE와 같다고 일반화하지는 않음
  • 수 세기: 옛 bard-necro처럼 리스트에 항목을 밀어 넣고 list 'name' >= n으로 비교
  • mana >= config__x처럼 내장 식이 왼쪽이면 가능. 내장 index도 왼쪽이면 변수와 비교 가능
  • while 조건에도 변수 크기 비교 금지(선례 없음)
• as alias를 묶은 블록 밖에서 읽기: if findtype … as alias__x와 endif 뒤에서 alias__x를 읽으면 4294967295, noto가 Mobile … not found
  • 블록 안에서 @setvar! var__x alias__x로 복사. 모듈의 alias가 모두 블록 안에서만 쓰이는 이유
• getlabel 라벨을 블록 밖에서 읽기: if findlayer … as alias__x 안에서 getlabel alias__x label__y, endif 뒤의 sysmsg "… {{label__y}}"가 <not found>(2026-10-19 gear/aspect 방어구 진단 줄의 Journal. 그 줄은 커밋 dc675e2, 블록은 그 뒤 다시 씀)
  • 같은 실행에서 getlabel과 같은 블록 안의 sysmsg는 손에 든 주문서 라벨을 그대로 찍음 → alias처럼 블록을 벗어나면 사라지는 것으로 판단
• 중첩 라벨의 varexist: CE VarExist는 일반 호출에서 ExistAlias 사용
  • Interpreter의 ExistAlias는 루트 범위만 검사. 라벨 읽기는 부모 범위를 따라가지만 이 존재 검사는 그렇지 않음
  • @varexist도 대안으로 단정 불가. CE는 if 평가 전에 새 범위를 만들고, 이 표현식은 현재 범위만 확인
  • debug-target-state의 존재 검사 선례는 루트에서 조회한 라벨. 중첩 while의 선례 아님
  • loot/recycle: 같은 반복 범위에서 @unsetvar! label__item, @setvar! label__item 0, getlabel 순서. 결과가 0이면 이동과 분해 생략
  • 숫자 초기값은 라벨 문자열 복사가 아님. 이전 반복의 라벨을 지워야 조회 실패가 옛 라벨로 통과하지 않음
  • 2026-10-21 CE 소스와 범위 모형으로 확인. Outlands 포크에서 새 경로의 인게임 동작은 확인되지 않았다
• 단어를 변수에 담기: @setvar! var__x nomeeheh는 따옴표 유무와 무관하게 4294967295(2026-09-28 프로브)
  • 숫자 5000은 5000, 0x622396은 10진수 6431638. 변수에는 숫자와 serial만
  • → rename <serial> <변수>는 엉뚱한 이름을 보내 That name is unacceptable.. 단어는 리스트에 담아 foreach로. serial 쪽은 변수 가능
• 숫자를 펫 이름으로: serial을 그대로 주면 That name is unacceptable.(2026-09-28 프로브). 이름에 숫자 불가
• ignore 후 소속 판별: 공식 문서상 ignore는 검색 명령에서 객체를 뺌
  • 2026-10-05 v13 목재 정리는 파우치 소속 검사 전에 ignore. 검색 제외 동작을 넣은 모의 재현에서 파우치에 이미 있던 Boards를 다시 들어 올림
  • 앞선 NPC 직접 serial 프로브에서는 ignore 후에도 TRUE → 지금 포크의 아이템 검색에 같은 동작이 적용되는지는 아직 확인되지 않았다
  • v14: 두 검색 동작 모두에서 파우치에 이미 있는 Boards 제외
  • clearignore는 단계의 시작과 끝 → 다음 정리 주기에 실패한 요청과 새 묶음 재탐색. 단계 중 매번 비우면 이미 본 묶음을 다시 고를 수 있음
• 플레이어 serial의 find: 지금 클라이언트의 파란 alt 테스트에서 Q serial은 유효, find serial과 find serial ground -1 -1 18 모두 거짓. 인게임 확인됨 2026-10-04
  • 단발 setvar → cast → target 경로와 이전 bard-necro-pvp의 Q serial 직접 저장 경로는 모두 같은 플레이어에게 TK 성공, 공격 대상 이름과 30초 부착 안내 수신
  • 검색 실패 원인은 확인되지 않았다. 모든 클라이언트와 모든 플레이어의 일반 규칙으로 확장 금지
• dead serial: 전체 루프 실행, TK, Explosion, EB도 상대에게 들어감. 그래도 조회마다 경고인게임 확인됨 2026-10-04
• findtype은 매번 같은 모빌 반환: Razor CE처럼 무작위 아님. 한 번만 부르면 이미 처리한 모빌만 계속(2026-09-28, 둘째 소환수에 이름 미부여)
  • while findtype … as로 돌며 검사, 아니면 @ignore, endwhile 뒤 @clearignore로 한 번에 전부
• findbuff로 스탯 포션 판정: 위키 BuffIcons는 같은 아이콘을 Strength Spell / Potion으로 표기
  • Bless는 버프 바에 Strength, Agility, Cunning으로 뜸, 포션 버프 이름에 Potion 없음인게임 확인됨 2026-10-09
  • 위키 표의 Strength Potion Usage Cooldown도 인게임 이름으로 확인되지 않았다
• 선례가 없어 쓰지 않는 것
  • 산술 @setvar! var__n var__n + 1
  • menu <serial> <변수>. 인덱스는 반드시 리터럴
  • 조건 안의 괄호

06 명령문 비용

비용 = 검색 종류가 아닌 “이 패스에서 밟는 줄 수”. 그중 findtype이 가장 비쌈. → 자주 안 바뀌는 상태는 타이머로 막고, 흔한 경로가 밟는 줄을 줄임.

• Razor CE 원본 스크립트 엔진: 타이머 1틱에 명령문 하나 실행
  • ScriptManager.ScriptTimer → Interpreter.ExecuteScript → ExecuteNext 1회. 틱 기본 25ms
  • 거짓 if는 본문 건너뛰기까지 한 틱, elseif 사슬은 한 틱 안에서 평가
• 이 포크는 그보다 빠르지만 모양은 같음. 2026-09-28 프로브(probe-tick, 지금은 삭제)로 잰 값:

getlabel도 즉시 끝나는 로컬 조회로 가정 금지.

• CE GetLabel: 서버에 단일 클릭 전송, 첫 라벨 뒤 500ms 동안 후속 라벨 수집. 첫 응답이 없으면 2000ms 타임아웃
• 이 시간은 CE 구현의 값. Outlands 포크의 내부 대기 시간은 확인되지 않았다
• 반복 조회 제거가 우선. 응답 대기가 필요한 곳은 결과를 확인한 뒤 진행, 미확인 상태로 분류하거나 파괴하지 않음
• 대기용 getlabel backpack 사용 금지. 백팩 라벨은 다른 아이템의 감정, 분해, 이동 완료 신호가 아님 실제 대상의 품질 라벨, 소속 변경, 제거 여부로 확인. queued는 클라이언트 행동 큐 상태이며 서버 작업 성공과 별개

Bard Necro 루프 적용 결과: Bard Necro Enhanced 01.H절. 패스마다 findtype 최대 32번이던 시약 플래그 읽기를 10초에 7번으로 줄임(처음에는 30초).

07 PvP 제약

구조화 PvP, 팩션 상태의 스크립트 제약.

PvP 겸용 스크립트 규칙: Conventions 07절. 게임 쪽 PvP 규칙과 숫자: PvP.