1. 유닛 객체에겐 부모 객체의 일부 정보를 위해 부모 주소값 정보가 있음 ex) 라바 (부모) - 랠리포인트 설정 - 유닛(자식) - 랠리포인트로 이동 히드라(부모) HP - 럴커 고치(자식) HP 2. 저그 유닛 부화 매커니즘은 에그 - 부화 - 유닛 순으로 실행됨 ex) 부화 단계에서 죽는 유닛은 사망 모션이 없는 것으로 미루어보아, 에그와 유닛 사이에 새로운 객체가 존재하는 것을 알 수 있음 에그의 정보를 유닛에게 전달하기 위한 연산 및 메모리 할당 작업 시간을 벌기 위함 3. 부화 스프라이트가 적용되면서 메모리 초기화 발생, HP 값이 0/0 형태로 존재. 단순한 애니메이션 스프라이트를 위한 작업이기에 실질적 유닛에는 관여 못함 4. 때문에 부화와 동시에 공격을 받으면 부화 스프라이트가 사망처리 됨 하지만, 그와 별개로 연산완료된 유닛은 부화가 되면서 메모리에 생성된 유닛값이 할당됨 5. 부대지정, 그래픽 UI에서도 에그 - 부화 - 유닛 순으로 진행 이 과정에서 부화 오브젝트는 사망처리가 되며 그래픽 UI에서 사망처리(선택 영역 사라짐)이 되고, 동시에 유닛 정보의 주소값을 가져오게 되면서 부대지정 UI에는 유닛오브젝트 내에 유닛주소값을 통한 정보값들이 들어와있음 소결론. 유닛 객체는 사망처리되어 있지만, 메모리 주소값으로는 살아있는 버그가 걸린 유닛이 생성됨 7. 메모리 주소값 유닛이 사망해도, 스프라이트 오브젝트는 이미 사망처리가 되어있어 변경값이 갱신되지 않으면서 부대지정에서 이탈되지 않음 8. 뮤탈의 기본 공격 또한 유닛 생성과 같은 메모리에 올라가게 됨 하지만 기본공격은 초상화와 체력이 없기 때문에 부대지정 UI가 변경되지 않음 9. (정)뮤탈 무리들이 기본공격을 하며 사망 (정)뮤탈이 있던 메모리 자리에는 죽은 뮤탈의 기본공격 개체가 자리잡게 됨 10. 1에서 말했듯 자식 개체는 부모 주소값을 참조하게 되는데, 기본공격이 부모 주소값을 참조하지만 죽어버린 뮤탈의 주소값은 본인 주소값이 되어버림 11. 자신이 마지막에 튕겼던 곳을 부모 개체로 인식하며 부모 주소값을 변경 결론. (정)뮤탈이 죽는 순간 해당 메모리에 (정)뮤탈 혹은 죽은 뮤탈의 공격이 올라오고, 참조할 부모 주소값이 자신이 마지막에 튕긴 스포닝풀이 되면서 스포닝풀의 주소로 부모주소값을 바꿔버리게 된다. 부모주소값과 자신의 주소값이 동일하여 결국 죽은 (정)뮤탈 자리에는 스포닝풀이 남게 된다
1. 러커버그를 에그로도 가능 2. 자기러커가 아니라 상대러커로도 버그 가능 3. 상대 에그로 버그 가능 4. 그 에그가 스커지일 경우 자폭했을시 자폭당한 나의 뮤탈이 좀비화 되는 가능성? 여튼 상대 유닛으로 좀비화 시킨걸 내 화면에서 선택 가능한지를 확인하면 실마리가 풀릴거 같아요.
컴공과 빌런이 한번 추측해보자면 1. CPU가 한 오브젝트의 대한 정보를 기억하기 위해선 반드시 특정 메모리 주소값에 오브젝트의 내용을 할당시켜야 함 3. 스타크래프트를 개발하던 당시. 다수 몹을 다뤄야 하는 게임을 개발하기엔 극악의 환경이였음. 메모리가 쥐똥만하고, CPU가 느려 터졋기 때문. 4. 그래서 오브젝트가 없어지면 그 오브젝트의 주소값을 없애지 않고 물리적 연결만 끊어버린 다음, 새로운 오브젝트 값을 저장해야 할 경우 그 주소에다가 값을 덮어 씌우는 방식을 선택했을 거임 이는 CPU사용률도 아끼고, 메모리 할당량도 아끼는 굉장히 효율적인 구조임, 컴퓨터 정보 저장 장치인 하드 디스크나 SSD도 이방식을 채택함 또한 이것이 디지털 포렌식이 가능한 이유임 우리가 파일을 지워도 덮어씌워지지만 않으면 주소값에는 그정보가 남아 있으니까. 스타크래프트의 개발언어는 객체지향인 C++언어로 접근지정자를 이용하여 충분히 이방식을 구현 가능함 5. 메모리의 할당, 참조는 탐색 시간 (seek time)이라는 것이 있음 시간이 잠깐 걸린 다는 것임 이는 게임 엔진에 따라, 정보의 양에 따라 , 각종 변수에 따라 그 속도가 달라짐 6. 우리가 부대를 선택했을때 나오는 정보는 아마도 ' 주소값 참조' 일 것임 7. 럴커가 부화하기 직전에 쳐맞으면 버그 발생함 8. 고치가 쳐맞고 HP가 깎인 정보를 저장하는 것이 럴커로 변태하는 것보다 저장하는 속도가 느린 것으로 추정됨. 정해진 로직에따라 주소에 있는 값을 "초기화" 하기만 하면 되는 후자와 달리, 전자는 공격력 몇짜리 공격에 맞았는지, 일반형 공격인지, 아니면 진동형, 폭발형 공격인지, 또 방어력은 몇인지, 계산결과 값이 소수이면 올림을 할것인지 내림을 할것인지 정해야 하는 등 "연산"을 한 다음 "초기화" 해야함 9. 그래서 고치가 쳐맞은 정보가 럴커로 변태한 정보보다 뒤늦게 갱신되어 ''오브젝트 럴커의 주소값''엔 ''얻어맞은 고치의 정보''가 저장되어있는 레전드 갓겜 상황 발생 ㅋㅋㅋ 원이 안 생기는 이유도 고치는 다른 유닛과 같이 안묶이기 때문 10.영상을 보면 럴커가 쳐맞고 죽어도 부대정보엔 남아있음 추측컨데, 인터페이스에 나오는 정보는 메모리 주소 값을 참조 하는 것일 거임 그래서 ''오브젝트 럴커는'' 죽었지만, 오브젝트 럴커의 주소값엔 체력200에 방어력 10인 레전드 금강불괴 맷집에 대한 정보가 있기 때문에 럴커가 죽은 공격따위로는 절대 안죽음, 따라서 주소값에는 여전히 살아있는 몹의 정보가 들어있음, 다만, 죽으면 정크파일로 분류하는 로직이 발동되어 새로 추가된 오브젝트의 정보가 해당 주소값을 덮어 씌움 11. 개좆버그 발생 ㅇㅇ 12. 예기치 못한 버그로 죽어야 몹이 죽었는데도, 선택할 수 있는 버그를 방지하기 위한 로직은 시야값을 기반으로 만든 듯함. 몹은 죽으면 시야값이 0이 되고, 시야에 안들어온 유닛은 절대 조종할 수 없으니까, 그래서 시야에 없는 유닛을 지정 할 경우 팅겨 버리는 로직을 설계 한 듯함. 일부 유즈맵에 경우 시야가 없어도 조종이 가능한 경우가 있는데 (ex: 톰과제리 가스버전 겹치기맵) 이런맵은 해킹툴인 UED로 만든 맵이라서 가능 ㅇㅇ 13. 뮤탈리스크 사례에 경우 일단 뮤탈리스크가 스커지에 얻어맞고 적팀 뮤탈리스크의 직격, 쿠션 공격을 받는등 격렬하게 정보 변화가 이루어짐. 버그가 시작된 시점이 뮤탈 1마리가 죽은 직후였음 그렇다면 여기서 추측이 가능함. 오브젝트가 죽으면, 물리적 참조를 끊어버리는 과정2보다 덮어씌워도 파일로 변경하는 과정1이 더 일찍 이루어 진다는 것임. 그리고 격렬하게 싸운 정보때문에 과정 1과 과정2의 수행속도가 느려짐 그래서 클릭 실수로 스포닝 풀을 치던, 쿠션공격으로 스포닝플을 건들이던 스포닝풀의 체력값에 변화가 생겼고, 정보를 알뜰하게 저장하기 위해 뒤진 뮤탈 주소값에 새롭게 스포닝 풀정보를 저장하는 작업이 과정 1과 과정 2사이에 발생, 부대정보에 상대방 스포닝풀이 들어와 버림 14. 유닛 뽑지 않는 건물을 선택할 경우 시스템적으로 우클릭이 봉쇄됨, 하지만 업그레이드 선택이나 다른 오브젝트 선택같은건 해야해서 좌클릭은 활성화 됨. 이동버튼 눌러서 조종하거나 어택땅 둘다 좌클릭이라 가능 그냥 움직이는건 우클릭이라 불가능 결론: 유닛이 죽으면 덮어씌워도 되는 값으로 변경하고 물리적 참조를 끊어버리는 작업사이에 아주 작은 시간적 틈이 있음, 그 틈 사이에 오브젝트에 변화가 생기면 그 주소값에 오브젝트 정보가 갱신되버림 다만 이틈은 매우 좁고, 각종 변수에 따라 틈의 시간적 크기가 변화함 초고속 계산기인 CPU가 연산 2번하는 틈에 들어가야 해서 정말 극단적으로 드물게 발생
과거에는 메모리를 할당하고 해제 하는 과정이 되게 오래 걸렸기 때문에 한번에 쓸 만큼 메모리를 할당하고 그 메모리 내에서 재활용 했습니다. 이를 메모리 풀이라고 하는데, 유닛이 죽어도 해당 유닛을 가르킨 메모리는 해제 되지 않고 남아있다가 다른 유닛이 생성 되면서 그 유닛에 대한 정보를 해당 메모리에 썼기 때문인 것 같네요. + 이는 알에 대한 버그를 설명한 것이고 뮤탈은 뭔지 모르겠네요.
댓글 보니 좀비 스커지가 박혀 죽은 순간 걸리는데 부대지정 맨 앞 칸에 있던 딸피 무탈에 박혔음. 그런데 분래대러면 좀비 스커지가 빈 공간이 지정되어야 하는데 자폭 메커니즘에서 뭔가 특수한게 있을 거임 주소 주는 식으로, 그래서 좀비 스커지에 죽은 뮤탈도 동시에 좀비 슬롯이 됬음. 여기서 좀비 슬롯이 된 곳에 좀비 스커지 정보가 들어가야 되는데 스커지는 이미 죽은 상태라 다른 정보가 들어가야 되는 상황인데 이 때 뭔가의 이유로 스포닝풀이 들어감. 마지막에 스커지를 스포닝풀로 무빙 땡겻다든지 뭐.. 그렇지 않을까 엄청난 우연이라 첨 보는게 당연할듯
에그버그가 맞다면 좀비가 되는건 애초에 인터페이스상에 존재하는 유닛일걸로 추측됩니다. 따라서 애초에 스커지가 좀비로 내 아군유닛에 들어와있을 이유가 없다고 보여집니다. 이미 인터페이스상에 좀비가 존재하는 상태로 새로운 주소값에 상대방의 라바가 설정되었고 그 라바가 스커지가 되는 경우는 좀비스커지가 아닌 새로운 스커지가 좀비대신 자리잡은거니 오해 없으시길 바랍니다. 또한 저도 버그의 정확한 이유를 모르니 개인적인 의견이니 틀리더라도 그냥 사람마다 생각이 달랐다고 생각해주십쇼 ㅠ
1. 발견된 사항 정리 1) 애그가 변신을 완료하기 직전 쳐맞고 변신 완료 후 선택된 부대에서 죽으면 부대 안에서는 죽은 유닛의 슬롯이 사라지지 않고 남는다.(=죽은자의 온기를 남긴다.) 2) 부대에 죽은자의 온기가 남은 상태에서 (죽은자의 온기를 남긴 개체가 있던) 그 주소에 새로운 개체가 발생하면 그 새로운 개체는(적이든 아군이든) 기존 부대에 자동 편입된다. 3) 부대에 강제로 편입된 개체가 정유닛이면 (부대에서 제일 좌측 위) 일반적인 우클릭이 불가능해진다. 하지만 M컨이나 A 컨은 가능하다.(아마 스탑, 홀드나 페트롤도 가능할 것이다.) 2. 제보 영상에서 추가로 밝혀내야 하는 문제들 1) 체력30몇짜리 뮤탈이 죽은자의 온기를 남겼다. -> 하지만 이 뮤탈은 애그상태에서 쳐맞지 않았다. -> 애그상태에서 때리는 방법 말고 죽은자의 온기를 남기는 방법이 있다. -> 아마 스컬지 자폭과 연관된 것 같다. 2) 뮤탈이 죽은자의 온기를 남긴 후 빈자리에 적군의 스포닝풀이 편입되었다. 그러나 스포닝풀은 완성된지 한참 지난 건물이다. 3) (필자 의견) 즉, 흑운장이 찾아낸 버그 원리 (남은 빈슬롯(죽은 자의 온기)에 같은 주소의 다른 개체가 발생하면서 강제 부대 편입) 외에도, 다른 원리로 부대에 강제편입되는 버그가 존재할 가능성이 높다.
추측하신거처럼 메모리 관련 문제는 맞는거 같아요 슬롯에 남아있는 좀비 유닛이 포인터 변수처럼 기존 메모리 주소를 계속 가르키고 있으면 새로 생산된 유닛, 건물이 포함될 수는 있을 것 같은데 스포닝풀은 원래부터 있던거라 GC 같은 메모리 재배치하는 로직이 있다면 저렇게 될 수도 있겠네요
근데 럴커버그랑 궤는 다르다 생각되는게 럴커버그는 나중에 나온 유닛이 기존에 선택되어있는 슬롯에 새로 입장이 되는건데 스포닝풀은 이미 지어져있는상태고 기존슬롯에 들어갈 트리거는 없다고 생각됩니다 기존에 지어져있는 유닛에 변동이 생겨도 다시 들어간 실험은 여러가지하셨는데 맞는 결과가 없어서 그렇게 생각되는거라서 일단 저는 답은 못내리겠지만 럴커버그와는 다른거같습니다
21:17 여태 설명한것처럼 태어나자마자 공격을 당하면 좀비가 되는 버그라는 가정은 그대로 두고 스커지가 태어난지 좀 되서 공격당했는데 좀비가 됐느냐 아니냐가 스커지나 저글링은 단일이 아니라 알에서 깨서 두마리로 인식되는 시간까지 포함한 상태에서 공격당해서 좀비 스커지가 되지 않았나 추측
일단 여태까지 안 알려진 버그인 만큼 트리거가 상당히 복잡할 거란 걸 생각하고 들어가야 됨 1. 첫 번째 트리거 - 21:17 여기서 빨강이 스커지가 쿠션 맞으면서 태어나서 버그 걸림 (실제 스커지와 빨강이 유저 부대지정에 등록된 스커지의 주소가 다름) - 그 스커지가 자폭에 성공함 - 이 때 "스커지 자폭이펙트 발생 → 파랑이 뮤탈의 체력이 0이됨 → 뮤탈 사망" 과정이 중요한데, "스커지는 자폭으로 소멸 + 뮤탈은 체력 0으로 존재"하는 찰나의 순간에 뮤탈이 스커지의 주소를 참조함. 그리고 사망 스프라이트 발생 다만, 이것 만으로는 왜 이미 지어져 있던 스포닝풀이 부대지정으로 들어온 것인가는 설명이 안 됨 2. 두 번째 트리거 원래 뮤탈의 기본 공격은 유닛 메모리를 발생시킴 (예전에 맵에 유닛 너무 많으면 발키리 공격 안하는 원리) - 파랑이 뮤탈이 체력이 0이 된 상태로 사망 직전 기본 공격 유닛을 발생시킴 - 그 직후 뮤탈이 죽으면서 주소 버그가 뮤탈에게서 쿠션이(뮤탈 기본공격 유닛)에게로 옮겨감 (이유 : 쿠션 객체는 부모 객체인 뮤탈에게서 정보를 참조하기 때문. ex. 공업) - 쿠션이가 스포닝풀에 튕기면서 소멸. 버그 주소가 스포닝풀에 남음 - 파랑이 유저 부대 지정에 스포닝풀이 나타남 요약 : 빨강이 스커지에 주소 버그 발생 → 파랑이 뮤탈이 죽을 때 체력 0 상태일 때 잠시 버그 가져감 → 뮤탈의 쿠션이에게 옮겨감 → 스포닝풀에 붙음
저도 예전에 제 유닛과 상대 건물이 같이 선택되는 버그가 걸린 적이 있습니다. 그 당시에 저는 아마 중학생이었을 것이고 간단한 유즈맵을 하는 정도였습니다. 와이파이가 자주 끊기는 환경에서 노트북으로 게임을 했기 때문에 노트북이 구려서 그렇다고 생각하고 말았었죠... 이 영상을 보니 어릴 때의 추억들이 연결지어 생각나네요ㅋㅋ 아무튼 잘 찾아보면 해당 버그를 경험한 사람은 꽤 많지 않을까요?
이런걸 알아내는게 정말 대단하네... C/C++ 언어는 포인터를 쓰고 프로그래머가 직접 메모리 관리를 칼같이 잘 해야 하는데 인간들이 자꾸 실수를 함. 그래서 지금 다른 많은 언어들이 나온 것이죠. 그래도 여전히 효율성은 C/C++이 좋음. 프로그래머가 문제지... ------------------------------------------- C/C++ 언어가 효율적이라는 것은 프로그래머라면 다들 아는 얘기지만 생산성이 좋다는 얘기가 아니라(개발을 빨리 할 수 있는) 능력있는 개발자라면 느린 컴퓨터에서 빠른 프로그램을 만들 수 있다는 얘기. 메모리가 적은 컴퓨터에서 충분히 돌릴 수 있는 프로그램을 만들 수 있다는 얘기. 문제는 복잡한 프로그램을 여러 사람이 만들다 보면 실수가 들어가고 그 실수는 찾는게 너무나 힘듦. 그래서 이후의 언어들은 그런 실수를 막아주는 언어들이 나왔으나 그 만큼 속도와 메모리 효율성은 떨어짐. 스타는 나올 당시 정말 컴퓨터 성능을 최대한 활용한 잘 만든 프로그램이었으니...
스커지 탄생순간이 정확히 3번째 쿠션 맞을 위치와 타이밍이였네요. 3쿠션에 결정되었던 공격 포인터 대상이 알에서 스커지로 변하는 순간 맞기 직전에 사라지면서 포인터가 가르키는 곳에 문제가 생긴 버그 같습니다. '변하는 순간 공격시 포인터 문제'라는 같은 맥락. C 포인터는 메모리 주소 맞죠, 사라진 대상을 가르키는 순간, 각종 버그 메모리 크래쉬와 직결이 되죠.
ㅋㅋㅋㅋ 댕글링 포인터인거 같은데 예측해보자면, 럴커가 죽을 때, 프로그램 내부 메모리에 럴커 객체가 죽기 직전의 상태로 남아있음. 그리고 원래대로면 부대 안의 유닛이 죽으면 해당 유닛 객체의 메모리 주소를 가리키는 포인터도 제거해줘야 하는데. 포인터가 제거가 안됐던 듯. 그래서 이미 죽어서 없어진 럴커의 객체 포인터를 들고있는 상황임. 이제 새로운 유닛, 건물 등의 객체가 추가되면 원래는 새롭게 메모리를 잡아서 객체를 할당해 줘야 함. 그런데 메모리를 할당받는게 원래 시간이 좀 걸리는 작업이라서 보통은 메모리 풀 이라는 기법을 사용함. 사전에 메모리를 잔뜩 할당받아 놓고, 그 안에서 쓸모없는 녀석을 버리고 그 자리를 새로운 데이터로 채워넣는 식으로 돌려막기하는 거임. 그래서 다른 유닛을 생성하면, 메모리 풀 안에서 이미 사망 처리됐거나 필요없어진 객체의 메모리를 초기화한 다음, 새로 만들어진 유닛의 내용으로 덮어씌움. 위 경우엔 사망처리된 럴커 객체가 있던 메모리 주소에, 새롭게 생성된 배럭의 내용을 써넣은거임. 부대지정안에 보이는 건 해당 메모리 주소에 있는 유닛의내용을 그대로 보여줄 뿐이기 때문에, 이제 메모리 주소에 배럭이 생겼으니 그 배럭이 선택됨. c나 c++ 하다보면 알게 됩니다.
@@jesselingard2116 애초에 메모리가 해제된 영역 또는 다른 살아있는 객체에 포인터가 연결된 경우 매우 높은 확률로 튕기거나 정의되지 않은 행동을 할 가능성이 큼. 거기다가 메모리 풀을 별도로 짜서 쓰지 않았다면, 실제 메모리 물리 주소에 언제 어떤 객체가 할당되서 버그가 날지는 매 순간순간 운영체제의 메모리 할당 정책에 따라 달렸음. 즉, 완벽한 재현이 처음부터 불가능함. 보통 저런 문제가 생기면 그냥 댕글링 포인터가 발생하는 상황만 재현하고 디버깅하지. 그 포인터에 어떤 객체가 고정적으로 들어오게 만드는건 hack 비슷한 짓을 해야 가능함. 예를 들면 슈퍼마리오64의 경우 완전히 동일한 버그를 사용해서 객체를 복사하는 글리치가 있음. 이건 슈퍼마리오64의 소스코드를 알기 때문에 메모리 할당 및 해제 정책을 전부 알고 있기 때문에 가능한거임. 스타2 리마스터는 소스코드가 공개된 적이 없으니 메모리 할당 및 해제 알고리즘을 알 수 없고, 따라서 완전히 동일한 버그가 계속 발생하도록 하는건 힘들 가능성이 높음.
부대 지정할때 유닛들 메모리 주소를 저장하는데 버그걸리면서 이게 삭제가 안돼서 생기는 현상같고 정상유닛1번이랑 버그걸린유닛2번이 순서대로 할당되고 1,2번 유닛이 모두 죽은 후 1번 유닛 자리에 죽기 전 유닛보다 큰 메모리가 들어가고 2번 유닛 자리까지 덮어쓴상태에서 2번 유닛을 불러오니 덮어쓴 주소가 우연히 스포닝풀 주소였던거 아닐까요 영상에서도 버그 시험 중 메모리 충돌로 게임꺼지는것도 덮어쓴곳이 잘못된 위치를 가르켜서 강종된걸로 보이네요
20년 전 즈음에 벙커지키는 유즈맵하던 중 제 벙커에 건물띄우기 버튼이 생기는 버그가 걸린 적이 있습니다. 뭐지? 하고 띄우기 눌러보니까 아무 모션 없어서, 건물 내리기 눌러보니까 착륙선택할 수 있게 되어서 상대 진영 아무대나 눌러봤는데 이동하는 모션 없이 순식간에 이동되더라고요. 이것도 비슷한 버그였나봅니다. 사례도 찾아보기 힘든 버그라 궁금했었는데, 버로우 버튼이 생기는거 보니까 저도 비슷한 버그였다는 생각이 드네요. 20년의 물음표가 조금 해소되었습니다. 참고로 이전까지는 우주방사선으로 인한 버그로 생각했었습니다
1. 유닛 객체에겐 부모 객체의 일부 정보를 위해 부모 주소값 정보가 있음
ex) 라바 (부모) - 랠리포인트 설정 - 유닛(자식) - 랠리포인트로 이동
히드라(부모) HP - 럴커 고치(자식) HP
2. 저그 유닛 부화 매커니즘은 에그 - 부화 - 유닛 순으로 실행됨
ex) 부화 단계에서 죽는 유닛은 사망 모션이 없는 것으로 미루어보아, 에그와 유닛 사이에 새로운 객체가 존재하는 것을 알 수 있음
에그의 정보를 유닛에게 전달하기 위한 연산 및 메모리 할당 작업 시간을 벌기 위함
3. 부화 스프라이트가 적용되면서 메모리 초기화 발생, HP 값이 0/0 형태로 존재. 단순한 애니메이션 스프라이트를 위한 작업이기에 실질적 유닛에는 관여 못함
4. 때문에 부화와 동시에 공격을 받으면 부화 스프라이트가 사망처리 됨
하지만, 그와 별개로 연산완료된 유닛은 부화가 되면서 메모리에 생성된 유닛값이 할당됨
5. 부대지정, 그래픽 UI에서도 에그 - 부화 - 유닛 순으로 진행
이 과정에서 부화 오브젝트는 사망처리가 되며 그래픽 UI에서 사망처리(선택 영역 사라짐)이 되고,
동시에 유닛 정보의 주소값을 가져오게 되면서 부대지정 UI에는 유닛오브젝트 내에 유닛주소값을 통한 정보값들이 들어와있음
소결론. 유닛 객체는 사망처리되어 있지만, 메모리 주소값으로는 살아있는 버그가 걸린 유닛이 생성됨
7. 메모리 주소값 유닛이 사망해도, 스프라이트 오브젝트는 이미 사망처리가 되어있어 변경값이 갱신되지 않으면서 부대지정에서 이탈되지 않음
8. 뮤탈의 기본 공격 또한 유닛 생성과 같은 메모리에 올라가게 됨
하지만 기본공격은 초상화와 체력이 없기 때문에 부대지정 UI가 변경되지 않음
9. (정)뮤탈 무리들이 기본공격을 하며 사망
(정)뮤탈이 있던 메모리 자리에는 죽은 뮤탈의 기본공격 개체가 자리잡게 됨
10. 1에서 말했듯 자식 개체는 부모 주소값을 참조하게 되는데, 기본공격이 부모 주소값을 참조하지만 죽어버린 뮤탈의 주소값은 본인 주소값이 되어버림
11. 자신이 마지막에 튕겼던 곳을 부모 개체로 인식하며 부모 주소값을 변경
결론. (정)뮤탈이 죽는 순간 해당 메모리에 (정)뮤탈 혹은 죽은 뮤탈의 공격이 올라오고,
참조할 부모 주소값이 자신이 마지막에 튕긴 스포닝풀이 되면서 스포닝풀의 주소로 부모주소값을 바꿔버리게 된다.
부모주소값과 자신의 주소값이 동일하여 결국 죽은 (정)뮤탈 자리에는 스포닝풀이 남게 된다
이런경우는 게임할때 너무 많이 발생할거 같긴한데.. 죽으면서 딜하는 뮤탈이 한게임에서 여러번 발새할거 같아요..
@@훈동다 기본적으로 해당 뮤탈이 태어날때 연산을 위한 스프라이트가 죽은 버그뮤탈이어야하는데 이 자체도 발생빈도가 매우 낮을텐데
다른거보다 이게 젤 신빙성 있어보임. 부모-자식 객체 간 주소값 참조 때문에 이렇게 된거 같긴 한데 마지막에 튕긴 곳을 부모 객체로 인식한다는 것만 증명할 수 있다면 속 시원할 거 같음
박수치고갑니당
이러한 트리거였다면 맨 윗분 말대로 평소에도 엄청 많이 발생할 것 같은데... 터렛 짤짤이하면서 수도 없이 발생하는 케이스
와.. 그시절 메모리를 아껴쓰려고 별의별 똥꼬쇼를 했던 개발자의 노고가 보여서 가슴아프네.. ㅠ
ㅁㅊ 개웃곀ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
파생된 주소가 플레이 타임에 없어졌으면 재활용하는게 메모리를 아끼려고 똥꼬쇼 고생은 아닌데
오히려 더욱 쉽게 코딩한 방법인건데 그래서 저렇게 튕기는 현상도 발생하는거인거고
잘못알고 있으신거같아서 말하는거지 스타 제작진이 고생한걸 부정하는건아님
윗분 말대로 정확히는 시간 절약이 맞죠
이 상황에서는 메모리 낭비하는 쪽이 더 느려서 딱히 똥꼬쇼한건 아닙니다
메모리 최적화에 계산시간 최적화 까지 다 하려고 했던 거 아닌가?
메모리풀 자체는 메모리 할당 시간을 없애려고 하는거고.
메모리풀 안에서도 정책을 잘 짜서 메모리 사용량이랑 memset 비용도 다 줄였겠지
단순히 그 시절 사양에 맞춰서 사용할 메모리 범위를 제한하다보니까 생긴 문제라고 보는데. 딱히 최적화와 관련된 부분이라기 보다는
가물가물하다는 건
이미 알고는 있었다는 건데..
버그마스터 그는 대체..
1. 러커버그를 에그로도 가능
2. 자기러커가 아니라 상대러커로도 버그 가능
3. 상대 에그로 버그 가능
4. 그 에그가 스커지일 경우 자폭했을시 자폭당한 나의 뮤탈이 좀비화 되는 가능성?
여튼 상대 유닛으로 좀비화 시킨걸 내 화면에서 선택 가능한지를 확인하면 실마리가 풀릴거 같아요.
컴공과 빌런이 한번 추측해보자면
1. CPU가 한 오브젝트의 대한 정보를 기억하기 위해선 반드시 특정 메모리 주소값에 오브젝트의 내용을 할당시켜야 함
3. 스타크래프트를 개발하던 당시. 다수 몹을 다뤄야 하는 게임을 개발하기엔 극악의 환경이였음. 메모리가 쥐똥만하고, CPU가 느려 터졋기 때문.
4. 그래서 오브젝트가 없어지면 그 오브젝트의 주소값을 없애지 않고 물리적 연결만 끊어버린 다음, 새로운 오브젝트 값을 저장해야 할 경우 그 주소에다가 값을 덮어 씌우는 방식을 선택했을 거임
이는 CPU사용률도 아끼고, 메모리 할당량도 아끼는 굉장히 효율적인 구조임, 컴퓨터 정보 저장 장치인 하드 디스크나 SSD도 이방식을 채택함 또한 이것이 디지털 포렌식이 가능한 이유임 우리가 파일을 지워도 덮어씌워지지만 않으면 주소값에는 그정보가 남아 있으니까. 스타크래프트의 개발언어는 객체지향인 C++언어로 접근지정자를 이용하여 충분히 이방식을 구현 가능함
5. 메모리의 할당, 참조는 탐색 시간 (seek time)이라는 것이 있음 시간이 잠깐 걸린 다는 것임 이는 게임 엔진에 따라, 정보의 양에 따라 , 각종 변수에 따라 그 속도가 달라짐
6. 우리가 부대를 선택했을때 나오는 정보는 아마도 ' 주소값 참조' 일 것임
7. 럴커가 부화하기 직전에 쳐맞으면 버그 발생함
8. 고치가 쳐맞고 HP가 깎인 정보를 저장하는 것이 럴커로 변태하는 것보다 저장하는 속도가 느린 것으로 추정됨. 정해진 로직에따라 주소에 있는 값을 "초기화" 하기만 하면 되는 후자와 달리, 전자는 공격력 몇짜리 공격에 맞았는지, 일반형 공격인지, 아니면 진동형, 폭발형 공격인지, 또 방어력은 몇인지, 계산결과 값이 소수이면 올림을 할것인지 내림을 할것인지 정해야 하는 등 "연산"을 한 다음 "초기화" 해야함
9. 그래서 고치가 쳐맞은 정보가 럴커로 변태한 정보보다 뒤늦게 갱신되어 ''오브젝트 럴커의 주소값''엔 ''얻어맞은 고치의 정보''가 저장되어있는 레전드 갓겜 상황 발생 ㅋㅋㅋ 원이 안 생기는 이유도 고치는 다른 유닛과 같이 안묶이기 때문
10.영상을 보면 럴커가 쳐맞고 죽어도 부대정보엔 남아있음 추측컨데, 인터페이스에 나오는 정보는 메모리 주소 값을 참조 하는 것일 거임 그래서 ''오브젝트 럴커는'' 죽었지만, 오브젝트 럴커의 주소값엔 체력200에 방어력 10인 레전드 금강불괴 맷집에 대한 정보가 있기 때문에 럴커가 죽은 공격따위로는 절대 안죽음, 따라서 주소값에는 여전히 살아있는 몹의 정보가 들어있음, 다만, 죽으면 정크파일로 분류하는 로직이 발동되어 새로 추가된 오브젝트의 정보가 해당 주소값을 덮어 씌움
11. 개좆버그 발생 ㅇㅇ
12. 예기치 못한 버그로 죽어야 몹이 죽었는데도, 선택할 수 있는 버그를 방지하기 위한 로직은 시야값을 기반으로 만든 듯함. 몹은 죽으면 시야값이 0이 되고, 시야에 안들어온 유닛은 절대 조종할 수 없으니까, 그래서 시야에 없는 유닛을 지정 할 경우 팅겨 버리는 로직을 설계 한 듯함. 일부 유즈맵에 경우 시야가 없어도 조종이 가능한 경우가 있는데 (ex: 톰과제리 가스버전 겹치기맵) 이런맵은 해킹툴인 UED로 만든 맵이라서 가능 ㅇㅇ
13. 뮤탈리스크 사례에 경우 일단 뮤탈리스크가 스커지에 얻어맞고 적팀 뮤탈리스크의 직격, 쿠션 공격을 받는등 격렬하게 정보 변화가 이루어짐. 버그가 시작된 시점이 뮤탈 1마리가 죽은 직후였음
그렇다면 여기서 추측이 가능함. 오브젝트가 죽으면, 물리적 참조를 끊어버리는 과정2보다 덮어씌워도 파일로 변경하는 과정1이 더 일찍 이루어 진다는 것임. 그리고 격렬하게 싸운 정보때문에 과정 1과 과정2의 수행속도가 느려짐
그래서 클릭 실수로 스포닝 풀을 치던, 쿠션공격으로 스포닝플을 건들이던 스포닝풀의 체력값에 변화가 생겼고, 정보를 알뜰하게 저장하기 위해 뒤진 뮤탈 주소값에 새롭게 스포닝 풀정보를 저장하는 작업이 과정 1과 과정 2사이에 발생, 부대정보에 상대방 스포닝풀이 들어와 버림
14. 유닛 뽑지 않는 건물을 선택할 경우 시스템적으로 우클릭이 봉쇄됨, 하지만 업그레이드 선택이나 다른 오브젝트 선택같은건 해야해서 좌클릭은 활성화 됨. 이동버튼 눌러서 조종하거나 어택땅 둘다 좌클릭이라 가능 그냥 움직이는건 우클릭이라 불가능
결론: 유닛이 죽으면 덮어씌워도 되는 값으로 변경하고 물리적 참조를 끊어버리는 작업사이에 아주 작은 시간적 틈이 있음, 그 틈 사이에 오브젝트에 변화가 생기면 그 주소값에 오브젝트 정보가 갱신되버림 다만 이틈은 매우 좁고, 각종 변수에 따라 틈의 시간적 크기가 변화함 초고속 계산기인 CPU가 연산 2번하는 틈에 들어가야 해서 정말 극단적으로 드물게 발생
이게 맞는거 같은데, 근데 13번 과정에서 뮤탈->스커지 정보를 가져와야 했는데 이미 죽어있었기에 뮤탈 스플뎀의 n번째 타겟인 스포닝풀이 들어가지 않았을까? 싶은데 이건 어떻게 생각하심?
그... 예?
아 완벽히 이해했어! 짤 나와주세요
자 그럼 디버깅하고 코드 수정하러 가자
@@zana9207 컴끼야아아아아악!!!
스타 역사상 탄생과 죽음에 가장 많은 관심이 몰린 무탈 ㄷㄷ
포인터와 메모리에 대한 지식을 습득한 게이머 ㄷㄷ ㅋㅋㅋ 진짜 어려운 개념인데
포인터 뭐 어려울거 있나?ㅋㅋ 참조, 값복사, 주소를 가르킨다. 객체에 값을 할당한다 등등 이런 기초개념만 있으면 가능한데... C에서 포인터가 자바나 C#에선 Ref 매개변수랑 비슷한거고. (현직 개발자 입장에서...)
@@zana9207 포인터의 존재를 미리 알고 배우니 쉬운거지 0에서부터 쌓아가는게 쉬웠다면 2세대언어부터는 포인터를 꽤나 당연하게 썼었을 겁니다
@@짧은거-u9s 아마 포인터 개념이 어렵다기보단 실제로 현업의 복잡한 프로그램에서 포인트 변수 선언하고 활용하는게 어려울겁니다. C언어가 사용자입장에서 그렇게 편리한 툴도 아니라서 c#처럼 가비지콜렉터가 잘되어있는것도 아니고
@@zana9207 그러게요?ㅋㅋ 근데 왜 면접에서 물어보면 제대로 대답하는 사람이 없을까요
@@MealTimeForDove 그러게요 ㅋㅋ
진짜 20년된 게임에 버그 나오는게 순수 꿀잼인거같아요 형님 ㅋㅋㅋㅋ 지금 스타를 플레이 하는 유저는 아닌데도 정말 호기심넘치는 눈으로 영상 봤습니다 ㅋㅋㅋ
스타로 배우는 메모리 참조의 이해 ㅋㅋ
malloc! calloc! realloc!
@@changheonLee-we5de 만류귀종 ㄷㄷ
@@changheonLee-we5de혹시 맵에디터에 비슷한 개념이 있으려나요
@@김대의-m1ceud 맵 만들면 가장먼저 공부하는게 포인터입니다
21:17 여기서 스커지 맞으면서 러커에그처럼 버그 걸렸고 스커지 자폭하면서 스포닝으로 대체된거네요
어? 다시 보니 태어나기 직전에도 쿠션 데미지가 들어갔네요.
태어나면서 쿠션을 맞아서 알버그처럼 비슷한 환경이 된것 같네요? 버그 걸린 스커지가 자폭하면서 세입자신고가 된 것 같네요 정황상
이거다. 올려보자
저도 이게 가장 의심됐습니다. 흑운장님 혹시 짬나시면 이 시나리오 테스트 한번만 부탁드려요
저가 보기엔 저렇게 맞으면 맞는 모션이 스커지한태 튀지않나요 아래 에그가 맞은거 같은데
새로운 연구거리 발견하면 눈을 반짝이는 그야말로 교수님이네 ㅋㅋㅋㅋㅋㅋㅋ
과거에는 메모리를 할당하고 해제 하는 과정이 되게 오래 걸렸기 때문에 한번에 쓸 만큼 메모리를 할당하고 그 메모리 내에서 재활용 했습니다. 이를 메모리 풀이라고 하는데, 유닛이 죽어도 해당 유닛을 가르킨 메모리는 해제 되지 않고 남아있다가 다른 유닛이 생성 되면서 그 유닛에 대한 정보를 해당 메모리에 썼기 때문인 것 같네요.
+ 이는 알에 대한 버그를 설명한 것이고 뮤탈은 뭔지 모르겠네요.
태어날때 찰나에 공격시 기존에 살아있는 유닛 플래그 값과는 다른 느낌으로 가져가는거 같구요
그게 아마 상대에게 내 유닛 보여주기 위한 주소값인데 그게 유실되고 그 주소값은 상대가 지은 건물로 간게 아닐까 추측 해봅니다
자꾸 아는척 할려고 메모리 타령 하는 사람이 많은데 그냥 화면에 표시되는 오브젝트들을 배열로 관리하다가 삭제되면 그 자리에 그대로 변수를 할당했곘지. 뭐 메모리 어쩌고 할 정도 개념이 아닌데 왤케 다들 아는척 하고 싶어서 난리인지
뭔개솔 배열은 메모리 할당안하고 디스크 스왑만쓰냐? ㅋㅋ 원인은 짜여진 코딩에따라 여러가지일수 있는데 메모리 관련은 100퍼 맞다
배열, 변수, 오브젝트 얘기하면서 메모리 문제가 아니라고요? ㅋㅋㅋ
@@GrayBear-n7b 그 배열이 저장되는 곳은 메모리에요... 님이 말하는 방식 자체가 메모리 풀의 일종임.
댓글 보니 좀비 스커지가 박혀 죽은 순간 걸리는데 부대지정 맨 앞 칸에 있던 딸피 무탈에 박혔음. 그런데 분래대러면 좀비 스커지가 빈 공간이 지정되어야 하는데 자폭 메커니즘에서 뭔가 특수한게 있을 거임 주소 주는 식으로, 그래서 좀비 스커지에 죽은 뮤탈도 동시에 좀비 슬롯이 됬음. 여기서 좀비 슬롯이 된 곳에 좀비 스커지 정보가 들어가야 되는데 스커지는 이미 죽은 상태라 다른 정보가 들어가야 되는 상황인데 이 때 뭔가의 이유로 스포닝풀이 들어감. 마지막에 스커지를 스포닝풀로 무빙 땡겻다든지 뭐.. 그렇지 않을까 엄청난 우연이라 첨 보는게 당연할듯
빈 공간에 들어가는 애는 새로 업데이트된 주소에 할당된 유닛/건물인데 그게 스포닝풀이라면 스커지가 죽기 전 마지막에 뮤탈에 박으면서 스포닝풀에 무빙 눌르면서 스포닝풀이 묘한 스커자 자폭메커니즘 때문에 업데이트 됬을 거임
에그버그가 맞다면 좀비가 되는건 애초에 인터페이스상에 존재하는 유닛일걸로 추측됩니다. 따라서 애초에 스커지가 좀비로 내 아군유닛에 들어와있을 이유가 없다고 보여집니다.
이미 인터페이스상에 좀비가 존재하는 상태로 새로운 주소값에 상대방의 라바가 설정되었고 그 라바가 스커지가 되는 경우는 좀비스커지가 아닌 새로운 스커지가 좀비대신 자리잡은거니 오해 없으시길 바랍니다. 또한 저도 버그의 정확한 이유를 모르니 개인적인 의견이니 틀리더라도 그냥 사람마다 생각이 달랐다고 생각해주십쇼 ㅠ
스타식 전세사기 ㄷㄷ
c언어의 포인터 개념을 설명하고 계시군뇨
하 기승전 까지는 개지려서 흥분하면서 봤는데 밝혀지지 않은게 너무 아쉽습니다 ㅠㅠ 부디 귀인이 나타나셔서 밝혀주시길 간절히 바랍니다!! 아니 근데 힌트주신 버그마스터께서는 도대체 어떤 삶을 사신겁니까..?
17:54 일단 여기서 맞고 태어나긴 했네
오 쿠션 드감
이거 맞는거 같네요
스커지 죽을때 스포닝풀에 혹시 발업이 완성 되는지도 궁금합니다 스포닝풀도 한번 찍어봐주시지
1. 발견된 사항 정리
1) 애그가 변신을 완료하기 직전 쳐맞고 변신 완료 후 선택된 부대에서 죽으면 부대 안에서는 죽은 유닛의 슬롯이 사라지지 않고 남는다.(=죽은자의 온기를 남긴다.)
2) 부대에 죽은자의 온기가 남은 상태에서 (죽은자의 온기를 남긴 개체가 있던) 그 주소에 새로운 개체가 발생하면 그 새로운 개체는(적이든 아군이든) 기존 부대에 자동 편입된다.
3) 부대에 강제로 편입된 개체가 정유닛이면 (부대에서 제일 좌측 위) 일반적인 우클릭이 불가능해진다. 하지만 M컨이나 A 컨은 가능하다.(아마 스탑, 홀드나 페트롤도 가능할 것이다.)
2. 제보 영상에서 추가로 밝혀내야 하는 문제들
1) 체력30몇짜리 뮤탈이 죽은자의 온기를 남겼다.
-> 하지만 이 뮤탈은 애그상태에서 쳐맞지 않았다.
-> 애그상태에서 때리는 방법 말고 죽은자의 온기를 남기는 방법이 있다.
-> 아마 스컬지 자폭과 연관된 것 같다.
2) 뮤탈이 죽은자의 온기를 남긴 후 빈자리에 적군의 스포닝풀이 편입되었다. 그러나 스포닝풀은 완성된지 한참 지난 건물이다.
3) (필자 의견) 즉, 흑운장이 찾아낸 버그 원리 (남은 빈슬롯(죽은 자의 온기)에 같은 주소의 다른 개체가 발생하면서 강제 부대 편입) 외에도,
다른 원리로 부대에 강제편입되는 버그가 존재할 가능성이 높다.
21:16 이때 쿠션 막타가 그때 막 부화중인 스커지 에그를 때리긴 하네요
이게 수상함
추측하신거처럼 메모리 관련 문제는 맞는거 같아요
슬롯에 남아있는 좀비 유닛이 포인터 변수처럼 기존 메모리 주소를 계속 가르키고 있으면 새로 생산된 유닛, 건물이 포함될 수는 있을 것 같은데
스포닝풀은 원래부터 있던거라 GC 같은 메모리 재배치하는 로직이 있다면 저렇게 될 수도 있겠네요
흑카데미 1승 축하드립니다🎉🎉
저녁에 못보고 오늘 리딸로 시청 했습니다.. ㅎㅎ
형님 뒤에서 게임만들고 계신거아닌가요 어느날 갑자기 저희가 새로운 게임 냈습니다 하면서 게임내는거 아닌가요 ㅋㅋ😂😂 qa에 재능이 넘치시는거 같습니다 ㅋㅋ
근데 럴커버그랑 궤는 다르다 생각되는게
럴커버그는 나중에 나온 유닛이 기존에 선택되어있는 슬롯에 새로 입장이 되는건데
스포닝풀은 이미 지어져있는상태고 기존슬롯에 들어갈 트리거는 없다고 생각됩니다
기존에 지어져있는 유닛에 변동이 생겨도 다시 들어간 실험은 여러가지하셨는데 맞는 결과가 없어서 그렇게 생각되는거라서
일단 저는 답은 못내리겠지만 럴커버그와는 다른거같습니다
비슷한 현상이라 거기에 얽매여서 해답을 못찾는거일수도 ㅇㅇ
저도 같은생각 큰 틀의 포인터 이슈는 맞는데 상황이 좀 다른거같음
21:17 여태 설명한것처럼
태어나자마자 공격을 당하면 좀비가 되는 버그라는 가정은 그대로 두고
스커지가 태어난지 좀 되서 공격당했는데
좀비가 됐느냐 아니냐가
스커지나 저글링은 단일이 아니라
알에서 깨서 두마리로 인식되는 시간까지 포함한 상태에서 공격당해서 좀비 스커지가 되지 않았나 추측
버그를 플레이어가 발동 원리를 찾고 버그에 걸리지않게 조심해서 컨트롤 해야하는 갓겜
개인적인 추측을 하자면 위치좌표에 의해 발생하는 버그가 아닐까요? 뮤탈이 사망하는 순간 뮤탈의 ui는 사라지지만 뮤탈의 데이터가 남아있는데 그 순간 죽은 뮤탈과 스포닝풀의 위치좌표가 픽셀단위로 일치해서 컴퓨터가 둘을 동일 개체로 인식해버렸다?
일반적으로 지상개체는 충돌크기가 있으니 보기가 어렵고 공중유닛도 별 조작을 안하면 자동으로 밀려나니까 평소에는 보기 어려운 버그가 아닐까...하는게 개인적인추측입니다
그 순간에 뮤탈과 풀의 좌표와 관련된 두 포인터가 같은 메모리 주소를 가리켰나? 그러면 이런 버그 날 수도 있겠는데, 스타 개발할 시기에는 스마트 포인터 없었다는거 보니까 동기화 문제 맞을 수 있겠다
21:17 여기서 스커지 태어날때 쿠션 맞으면서 태어나는데 관련 없을까요?
럴커 버그처럼 걸렸고 죽는 순간 프레임에 가장 가까운 스포닝풀이 인식돼서 된 느낌
20년 넘은 게임에서 아직도 새로운게 나오네 ㅋㅋㅋ
일단 여태까지 안 알려진 버그인 만큼 트리거가 상당히 복잡할 거란 걸 생각하고 들어가야 됨
1. 첫 번째 트리거
- 21:17 여기서 빨강이 스커지가 쿠션 맞으면서 태어나서 버그 걸림 (실제 스커지와 빨강이 유저 부대지정에 등록된 스커지의 주소가 다름)
- 그 스커지가 자폭에 성공함
- 이 때 "스커지 자폭이펙트 발생 → 파랑이 뮤탈의 체력이 0이됨 → 뮤탈 사망" 과정이 중요한데, "스커지는 자폭으로 소멸 + 뮤탈은 체력 0으로 존재"하는 찰나의 순간에 뮤탈이 스커지의 주소를 참조함. 그리고 사망 스프라이트 발생
다만, 이것 만으로는 왜 이미 지어져 있던 스포닝풀이 부대지정으로 들어온 것인가는 설명이 안 됨
2. 두 번째 트리거
원래 뮤탈의 기본 공격은 유닛 메모리를 발생시킴 (예전에 맵에 유닛 너무 많으면 발키리 공격 안하는 원리)
- 파랑이 뮤탈이 체력이 0이 된 상태로 사망 직전 기본 공격 유닛을 발생시킴
- 그 직후 뮤탈이 죽으면서 주소 버그가 뮤탈에게서 쿠션이(뮤탈 기본공격 유닛)에게로 옮겨감 (이유 : 쿠션 객체는 부모 객체인 뮤탈에게서 정보를 참조하기 때문. ex. 공업)
- 쿠션이가 스포닝풀에 튕기면서 소멸. 버그 주소가 스포닝풀에 남음
- 파랑이 유저 부대 지정에 스포닝풀이 나타남
요약 : 빨강이 스커지에 주소 버그 발생 → 파랑이 뮤탈이 죽을 때 체력 0 상태일 때 잠시 버그 가져감 → 뮤탈의 쿠션이에게 옮겨감 → 스포닝풀에 붙음
결국 왜 이미 건설된 스포닝으로 대체됐는지가 가장 논점이네요.
오오 이거 이제야 올라오네여 ㅋㅋㅋ 진짜 사상 처음봤음 건물이 유닛이라니
제보자입니다 결국 여기까지 파셨네요 ㅋ.ㅋ
너무 재밌게 봤습니다 ㅎㅎㅎ
18:25 뮤탈 맞으면서 태어나는거 아닌가요?
이거다
이거는 이미 버그 걸린 뒤에 태어나는거라 아닌거같고
저는 21:17 스커지가 맞으면서 태어나는게 의심되긴한데
맞으면서 태어나는거 맞는거 같은데 뮤탈 공격 이펙트가 라바 까지는거 밑에 묻혀있긴 함
이부분은 자세히 보시면 밑에 라바가 그냥 새로 생겼습니다 그게 맞은거 같습니다
와 이런 버그를 구현시도를 하면서 연구를 한다는것 자체가 진짜 스타에대한 찐사랑 입니다 운장이형님.. 곧 해커자격증도 딸수있을거 같네요ㅋㅋ
12:27 하드디스크의 원리 느낌입니다?
스컬지 맞으면서 태어났고 그게 두마리중 하나가 버그가 걸림. 걸린 스컬지가 자폭으로 체력없는 뮤탈이 선택이 됨. 뮤탈 죽고 온기가 남아 있는 상태에서 부대지정된 쓰리쿠션 중 하나가 스포닝 풀에 맞고 번호지정이 되고 개체로 인식이 됨. 이건가요…??
21:18 저 우측 스컬지가 갖다박고 죽으면서 럴커랑 같은 개념이 된듯?
21:17 21:18 에 알이 맞으면서 스커지가 부화해서 그런것 같아요
진짜 흑운장 클라쓰 오진다
이건 뭐 제작자도 처음보는 버그일것같은뎈ㅋㅋ
저도 예전에 제 유닛과 상대 건물이 같이 선택되는 버그가 걸린 적이 있습니다.
그 당시에 저는 아마 중학생이었을 것이고
간단한 유즈맵을 하는 정도였습니다.
와이파이가 자주 끊기는 환경에서 노트북으로 게임을 했기 때문에 노트북이 구려서 그렇다고 생각하고 말았었죠...
이 영상을 보니 어릴 때의 추억들이 연결지어 생각나네요ㅋㅋ
아무튼 잘 찾아보면 해당 버그를 경험한 사람은 꽤 많지 않을까요?
내일 ㅈㄴ 기대된다 내일되면 누군가 해답을 써두고 베댓에떠있곘지
이런걸 알아내는게 정말 대단하네...
C/C++ 언어는 포인터를 쓰고 프로그래머가 직접 메모리 관리를 칼같이 잘 해야 하는데
인간들이 자꾸 실수를 함. 그래서 지금 다른 많은 언어들이 나온 것이죠.
그래도 여전히 효율성은 C/C++이 좋음. 프로그래머가 문제지...
-------------------------------------------
C/C++ 언어가 효율적이라는 것은 프로그래머라면 다들 아는 얘기지만 생산성이 좋다는 얘기가 아니라(개발을 빨리 할 수 있는)
능력있는 개발자라면 느린 컴퓨터에서 빠른 프로그램을 만들 수 있다는 얘기.
메모리가 적은 컴퓨터에서 충분히 돌릴 수 있는 프로그램을 만들 수 있다는 얘기.
문제는 복잡한 프로그램을 여러 사람이 만들다 보면 실수가 들어가고 그 실수는 찾는게 너무나 힘듦.
그래서 이후의 언어들은 그런 실수를 막아주는 언어들이 나왔으나 그 만큼 속도와 메모리 효율성은 떨어짐.
스타는 나올 당시 정말 컴퓨터 성능을 최대한 활용한 잘 만든 프로그램이었으니...
21:17 스컬지가 맞으면서 태어나는데요?!
이거다
그거다
영상 재미있게 잘 봤습니다~
형님 이번에 흑카데미 장독대 역전승 진짜 감동적이었습니다 구독박고갑니다
스커지 탄생순간이 정확히 3번째 쿠션 맞을 위치와 타이밍이였네요.
3쿠션에 결정되었던 공격 포인터 대상이
알에서 스커지로 변하는 순간 맞기 직전에 사라지면서
포인터가 가르키는 곳에 문제가 생긴 버그 같습니다.
'변하는 순간 공격시 포인터 문제'라는 같은 맥락.
C 포인터는 메모리 주소 맞죠,
사라진 대상을 가르키는 순간, 각종 버그 메모리 크래쉬와 직결이 되죠.
확실히 이런거보면 연구적인 관점에서 조건 설정이라던지 열정같은게 보인다
ㅋㅋㅋㅋ 댕글링 포인터인거 같은데
예측해보자면,
럴커가 죽을 때, 프로그램 내부 메모리에 럴커 객체가 죽기 직전의 상태로 남아있음.
그리고 원래대로면 부대 안의 유닛이 죽으면 해당 유닛 객체의 메모리 주소를 가리키는 포인터도 제거해줘야 하는데. 포인터가 제거가 안됐던 듯.
그래서 이미 죽어서 없어진 럴커의 객체 포인터를 들고있는 상황임.
이제 새로운 유닛, 건물 등의 객체가 추가되면 원래는 새롭게 메모리를 잡아서 객체를 할당해 줘야 함.
그런데 메모리를 할당받는게 원래 시간이 좀 걸리는 작업이라서 보통은 메모리 풀 이라는 기법을 사용함.
사전에 메모리를 잔뜩 할당받아 놓고, 그 안에서 쓸모없는 녀석을 버리고 그 자리를 새로운 데이터로 채워넣는 식으로 돌려막기하는 거임.
그래서 다른 유닛을 생성하면, 메모리 풀 안에서 이미 사망 처리됐거나 필요없어진 객체의 메모리를 초기화한 다음, 새로 만들어진 유닛의 내용으로 덮어씌움.
위 경우엔 사망처리된 럴커 객체가 있던 메모리 주소에, 새롭게 생성된 배럭의 내용을 써넣은거임.
부대지정안에 보이는 건 해당 메모리 주소에 있는 유닛의내용을 그대로 보여줄 뿐이기 때문에, 이제 메모리 주소에 배럭이 생겼으니 그 배럭이 선택됨.
c나 c++ 하다보면 알게 됩니다.
지금 배럭이 중요한게 아니야 보다말고 댓글 썼어?
@@jesselingard2116 뒤에 내용도 차피 포인터 관련 문제일텐데 뭐가 다른가?
메모리풀 정리하거나, 최적화 하려고 포인터 오프셋 관련 연산하면서 다른 객체가 튀어나오는 거겠죠 뭐
@@jesselingard2116 애초에 메모리가 해제된 영역 또는 다른 살아있는 객체에 포인터가 연결된 경우 매우 높은 확률로 튕기거나 정의되지 않은 행동을 할 가능성이 큼.
거기다가 메모리 풀을 별도로 짜서 쓰지 않았다면, 실제 메모리 물리 주소에 언제 어떤 객체가 할당되서 버그가 날지는 매 순간순간 운영체제의 메모리 할당 정책에 따라 달렸음. 즉, 완벽한 재현이 처음부터 불가능함.
보통 저런 문제가 생기면 그냥 댕글링 포인터가 발생하는 상황만 재현하고 디버깅하지. 그 포인터에 어떤 객체가 고정적으로 들어오게 만드는건 hack 비슷한 짓을 해야 가능함.
예를 들면 슈퍼마리오64의 경우 완전히 동일한 버그를 사용해서 객체를 복사하는 글리치가 있음. 이건 슈퍼마리오64의 소스코드를 알기 때문에 메모리 할당 및 해제 정책을 전부 알고 있기 때문에 가능한거임.
스타2 리마스터는 소스코드가 공개된 적이 없으니 메모리 할당 및 해제 알고리즘을 알 수 없고, 따라서 완전히 동일한 버그가 계속 발생하도록 하는건 힘들 가능성이 높음.
버그마스터도 그렇고 흑운장도 그렇고 스타계의 교수 ㄹㅇ 맞다
스타 리마스터 전에는 8명 풀방으로 무한맵에서 8명 다 후반전까지 가면 생성제한 걸려서 건물, 유닛, 투사체가 더 이상 생성 안되는 현상도 있었죠. 건물, 유닛, 미사일마다 생성되면 주소값이 할당되고 모종의 이유로 없어지면 주소값이 없어지는게 디폴트같긴합니다.
저 버그걸린 스포닝풀 자리가 사실 스타크래프트 연산내에서는
15:41 어떠한 계기로 1번자리로 버그 라바가 지정되고
그 버그라바가 > 버그 드론 > 버그 스포닝풀까지 이어진건 아닐까!?
비어있는 집주소에 스포닝풀이 들어왔다면 비비기 판정 오류 밖에 없지않나..
흑운장님 영상중
"여러분은 당분간 9드론을 만나게 될겁니다"
이 강의.마지막 버그랑 동일현상인가여..... 비슷한거 같은뎅
흑형 많ㅇㅣ 후덕해지셨네요
형 현역때는 존잘러였는데
혹시 스포닝풀 피 나는 것도 하나의 변화 취급인가...?
부대 지정할때 유닛들 메모리 주소를 저장하는데 버그걸리면서 이게 삭제가 안돼서 생기는 현상같고
정상유닛1번이랑 버그걸린유닛2번이 순서대로 할당되고 1,2번 유닛이 모두 죽은 후 1번 유닛 자리에 죽기 전 유닛보다 큰 메모리가 들어가고 2번 유닛 자리까지 덮어쓴상태에서 2번 유닛을 불러오니 덮어쓴 주소가 우연히 스포닝풀 주소였던거 아닐까요
영상에서도 버그 시험 중 메모리 충돌로 게임꺼지는것도 덮어쓴곳이 잘못된 위치를 가르켜서 강종된걸로 보이네요
전혀 아닐 수도 있지만, 한픽셀에 들어갈수 있는 유닛의 수가 초과되어 발생할수도 있지않을까여? 패트롤리콜 할때 유닛들이 통제 불능하게 움직이는게 떠올라서..
3:16 스커지가 뮤탈한테 접촉되서 터질려는 순간에 뮤탈이 스커지를 공격 혹은 쿠션딜로 스커지가 죽고, 뮤탈도 죽으면서 생기는게 아닐까싶네요.
오브젝트 풀링으로 만들어진 버그같기는 하네요 죽은 오브젝트를 삭제하는게 아니고 이제 재활용하는...
근데 벙커마린.고스트한테 후들겨맞으면 셔틀탄 리버도 죽는거도 수많은게이머들이 해봣겟지만 얼마전에 밝혀진거봐선 그냥 특수한 상황의 버그는 찾기힘들어서 조만간 또 이상한 버그튀어나올거같음
잘모르겠지만 뭔가 도움이 될꺼같아서 댓글 남겨봅니다.
1. 영상 21:17에서 21:18로 넘어갈때 상대 에그에서 스커지가 나오기 직전에 뮤탈이 쓰리쿠션으로 에그를 때렸고
2. 그 스커지가 피없는 파랑 뮤탈을 죽이면서 (마치 럴커를 직접 죽여서 버그가 생긴것처럼 스커지도 죽었으니) 버그가 발생한게 아닐까 싶습니다.
의심1) 상대 스포닝 위에서 부대지정을 하는 것 같은 모습 (의미없어보임…)
의심2) 스커지가 자폭하는 순간 공격 당해 죽는 피가 됐다? -> 피 0되는 순간 죽는게 아니니 피0이 된 스커지 자폭딜에 죽은 뮤탈에 의해 메모리가 꼬인건 어떨지…
꾸준히 새로운 버그 생성 부탁드립니다. 유저분들 분발 부탁드립니다. 너무 재밌읍니다.
머리쓰는 유즈맵이랑 스타고라스 컨텐츠가 넘 좋음
오늘따라 형 얼굴이 왜 허옇게 보이지 백운장 될라하나 ㅎㅎㅎ
와 이놈의 민속놀이는 왜 아직도 새롭냐;;;
0:08 후x장 입니다 ㄷㄷ
7질에 이은 후(군)장 ㄷㄷㄷ
그만 뇌절해라
7질 후X장 러쉬 ㄷㄷ;
ㅋㅋㅋㅋ
딴 건 모르겠고 희안하다 진짜 개열받는다
스타는 대체 언제쯤이면 모든걸 알게 되는 걸까 ㅋㅋㅋㅋㅋㅋㅋㅋ
유닛이 태어나고 죽는 것만과 관련있는 것 같은데... 때리고 맞는 것과는 무슨 연관이 있나요?
진짜 실전에서 저 버그가 터질 확률이 얼마나 될까ㅋㅋㅋㅋㅋ
오 곡고미
0.00005832%정도
로또스택 파괴ㅋㅋㅋㅋㅋ
ㄹㅇ 실전에서 나오지도 않을걸로 근들갑떠는거보면 웃기기만함 ㅋㅋ
21:18 여기장면 봐주세요
채팅차 제보한 스커지 맞으면서 태어나는 장면
스커지 맞으면서 태어나요
흑운장님이 확인하신 장면은 이후꺼 보신거고요
당시 상황에는 에그와 관련된 상황이 없는 걸로 보이는데 에그 버그와 비슷한 느낌이지만 당시 상황을 재현하는데에는 다른 접근이 필요하지 않나 싶습니다
가스통에 갇혀 나오지 못하는 프로브의 미스터리는 아직도 풀지 못했다고 전해진다
겜시간 05분 47초에 태어나기 바로전인 스커지 라바가 맞는걸로 보이는데요?
형림 희끗해진 머리털이 눈물겹읍미다
21:16초경 스커지가 태어나기 직전에 한방 맞는거같은데 .....
부대지정 풀리는건 어떤현상 때문인가요?
이거 마인드컨트롤 시험해봐도 재밌는거 나올거같은데여
21:19스커지 태어나면서 쿠션 맞고 앞에 알려주신 버그가 걸려서 테두리 없는 스커지 된거 아닌가요
웬만한 추리 영화보다 훨씬 재밌다
정보 : 30년된 게임이다.
30년까진 아님 ㅎ 98년도니까 26년 ㅎ
와 파도파도 끝이없네 이게임은 ㅋㅋㅋㅋㅋㅋ
형 오랜만에 봐서 그런가 뭔가 오늘따라 윤석열 닮은 것 같아
21:08
스커지 알에서 태어날때 맞으면서 태어남
그 스커지가 자폭하면서 버그발생
중간까지만 보고 궁금해서 적는건데
뮤탈과 배럭이 같이 부대지정 되는건 알겠는데
그 상태에서 뮤탈을 죽이면 배럭만 남게 됐을때
거기서 유닛을 뽑을 수 있나요?
뮤탈이 죽은 위치가 스포닝풀과 좌표가 완벽하게 겹쳐서 생겨난 버그 아닐까 추측해봅니다
부대지정 풀리는것이나 랠리포인트 안먹히는건 왜그런건가용
버그학개론 중간고사문제
이런 것 보면 유닛의 명령은 부대 지정한 유닛의 첫 자리에 위치한 유닛이 기준이 되는가봄 쓸모는 없겠지만
컴공과 학부생 포인터 배울때 이거 보여주면 되겠네 ㅋㅋㅋㅋㅋㅋㅋㅋ
이정도면 스타계의 한문철 이다
만약 스포닝풀처럼 버그걸린게 상대랑 서로 같은상황으로 걸리면 어떻게됨?
싱글게임 치트쓰면 인벤토리마다 다값이 있었죠
댓글에서 이러쿵 저러쿵 추측은 많은데
결국 "왜 살아있던 스포닝풀이 남의집에 등기를 치는가(제 집도 있으면서)" 는 아직 명쾌하진 않네요
20년 전 즈음에 벙커지키는 유즈맵하던 중 제 벙커에 건물띄우기 버튼이 생기는 버그가 걸린 적이 있습니다. 뭐지? 하고 띄우기 눌러보니까 아무 모션 없어서, 건물 내리기 눌러보니까 착륙선택할 수 있게 되어서 상대 진영 아무대나 눌러봤는데 이동하는 모션 없이 순식간에 이동되더라고요. 이것도 비슷한 버그였나봅니다. 사례도 찾아보기 힘든 버그라 궁금했었는데, 버로우 버튼이 생기는거 보니까 저도 비슷한 버그였다는 생각이 드네요. 20년의 물음표가 조금 해소되었습니다. 참고로 이전까지는 우주방사선으로 인한 버그로 생각했었습니다
와..... 까도 까도 계속 나오는 버그.......
그냥 구조오프셋이라는 값이 0부터 시작하면서 하나씩 채워가는 구조라 일어나는 문제 이 값이 유닛이 죽으면 하나씩 지워지는데 그 과정에서 생긴 오류인듯