TIL
- 재화, 힐, 드롭 아이템이 몬스터를 막는 문제 해결
- 재화, 힐 바운싱 넣기
재화, 힐, 드롭 아이템이 몬스터를 막는 문제 해결
몬스터 드롭으로 나온 아이템이 몬스터를 막는 문제, 몬스터가 이걸 못뚫고 지나감
콜리전쪽을 먼저확인해보니 콜리전은 Custom으로 플레이어한테 오버랩만 가능하게 되어있었음
문제는 네비메시를 드롭쪽에서 건드렸기 때문인데 각각 SetCanEverAffectNavigation설정을 false로 해주어서 해결하였음
재화, 힐 바운스 넣기
파츠쪽에는 현재 사인파를 이용한 바운싱 로직이 들어가 있다.
UpdateBobAnimation(float DeltaSeconds) 함수를 통해서
월드시간*스피드를 사인화 시키고 여기에 진폭을 곱한 후 틱을 돌면서 UpdateBobAnimation을 호출해서 바운싱가능하게 설정하는것을 재화와 힐에도 적용해주었다.
파츠 겹침 방지 로직 및 언덕에 파묻히는 증상 해결
우선 파츠 겹침의 경우 몬스터가 드롭할때 파츠 레지스트리에 파츠를 등록해서 파츠끼리 일정량 겹치지 않게 하는 로직이 들어갔었음
근데 이게 교체를 선택했을때도 레지스트리에 파츠가 등록되어 있어서 파츠를 스폰하는 함수에서 랜덤 위치에 드롭되는 것을 타고 있었음 근데 이는 드롭할때 드롭위치를 확실하게 확인하는 로직이 없으므로 벽에 겹치거나 지형에 파묻히는 증상이 발생 (SpawnInWorld함수에서는 파츠끼리 겹치는지만 판단함), 교체시에는 드롭 파츠 레지스트리에서 해제해주는 식으로 해결하였음
그리고 파츠 상호작용 범위를 조금 늘려줌
상호작용을 정면에 있는것만 가능하게
ToCandidate와 ViewForward는 둘다 정규화된 (길이1)벡터라서, 내적(DotProduct)이 바로 두 벡터 사이 각도의 코사인 값이 됨
ViewForward : 카메라가 보는 방향
ToCandidate : 카메라 -> 후보 액터 방향
이 둘의 내적 = 두 방향 사이 각도0의 코사인
코사인 함수는 0 ~ 180도 구간에서 각도가 커질수록 값이 감소(0 ->1, 90 -> 0, 180 -> -1) 그래서 후보가 정면이면 (0도) 내적 = 1, 후보가 측면이면(90도) 내적 = 0, 후보가 뒤면 (180도) 내적 = -1
ViewCosThreshold를 미리 구해두고, DotProduct < ViewCosThreshold면 0 > HalfAngleDeg라는 뜻이라 시야각 밖이라고 판정해 continue로 후보에서 제외
파츠 GE만들기
파츠에 실제로 스텟 표기 뿐 아니라 GE로 적용을 해주어야 한다.
이미 파츠쪽에 Apply하는 구간이 있어서 GE만 만들면 됨
우리 프로젝트는 지금 현재 NSCombatStatAttributeMapping을 쓰고 있는데 CommonUpgrade/증강이 모든 스탯의 Modifier가 다 들어있는 공유 GE1개를 쓰고 있는 구조라서 스탯이 15개라고 SetbyCaller 태그도 15쌍 필요하고, 안쓰는 태그는 중립값으로 채우고 그래야 하기때문에 조회/중립화 담당 테이블이 있다.
그냥 쉽게 말해서 CombatStat 태그 -> 공용 GE의 SetByCaller 태그 번역기, 공용 GE에 Modifier가 다 들어가 있음
구현계획 Claude
- NSPartTypes.h — FNSPartDefinitionRow에 Operation 필드 추가 (증강 Row와 동일한 ENSCombatStatModifierOperation 재사용, 기본 Add)
- NSPartEquipComponent.h — SharedPartEffectClass 프로퍼티(증강의 SharedAttributeStackEffectClass와 동일 패턴) + Internal_ApplySharedGE
선언 - NSPartEquipComponent.cpp — ApplyPartEffect에 분기 추가(EffectClass 비어있으면 공용 경로) + Internal_ApplySharedGE 구현. 매핑 조회 →
중립화 → SetByCaller 주입 → 슬롯별 핸들 저장. 전체 코드 문서에 포함 - 빌드 — 사용자
- 에디터 — 공용 GE BP(증강 공용 GE 복제 추천, Stacking None 필수), PlayerState BP에 할당, DT Row의 StatTag/Operation 설정
- 검증 8항목 — 장착/리롤/등급업/교체/2슬롯 독립성/Seamless Travel/접속자 클라/예외 로그
- 하이브리드 유지 — 기존 Internal_ApplyGE/OnEffectLoaded 경로는 한 줄도 안 건드림, EffectClass가 지정된 파츠는 예전처럼 개별 GE를 타서, 나중에 MMC형 특수 파츠가 와도 수용
- 초기엔 전 파츠 Add 통일 권장 — 등급별 ValueRange(FNSPartUpgradeRow)가 모든 스탯 공용이라, Add 파츠(+50)와 Multiply 파츠(×1.2)가 같은 범위를 공유할 수 없음
- Multiply가 필요해지면 스탯별 ValueRange 분리를 별도 작업으로 논의하는 게 안전합니다.
게임수학
라디안
Degree(도) : 우리가 일상에서 쓰는 단위, 원 한바퀴 = 360도
Radian(라디언) : 수학/프로그래밍에서 쓰는 단위, 원 한바퀴 = 2파이
왜 두개나 있냐면 : Cos, Sin 같은 삼각함수는 라디안을 입력받도록 정의되어 있음, 근데 사람이 코드에서 각도를 다룰땐 도 단위가 직관적
그래서 FMath::Cos(FMath::DegreesToRadians(InteractViewHalfAngleDeg))
InteractViewHalfAngleDeg = 60.f(사람이 이해하기 쉬운 60도)를 Cos 함수가 요구하는 라디안으로 변환한 뒤 넘김
언제쓰는가 : 사람이 지정한 각도를 삼각함수 (Sin, Cos, Tan등 라디안 요구하는 함수)에 넣어야 할때마다 이 변환이 필요함
내적
벡터 두개를 넣으면 숫자(스칼라) 하나가 나오는 연산. 3D 벡터 A=(x1, y1, z1), B=(x2, y2, z2)면 A내적B는 = x1x2 + y1y2 + z1*z2
언제쓰냐: 두 벡터가 얼마나 같은 방향을 보고있는지 알고 싶을 때, 정규화된(길이1) 벡터끼리 내적하면 그 결과가 정확히 두 방향 사이 각도의 코사인 값이 됨
