Priority fetching policy (Do not merge)

[icepeng]

TypeBaseFetchingPolicy는 대체로 잘 동작하나, 소환수가 버프를 제공하는 경우, 소환수가 극딜인 경우, 여러 종류의 버프를 한번에 사용하는 경우 사용 순서가 꼬여 최적의 딜사이클이 나오지 않는 문제가 있습니다.

이를 해결하기 위해 PriorityFetchingPolicy를 간단하게 만들어 보았습니다. JobGenerator에 get_skill_priority()를 작성해두면 우선순위 목록을 읽어오고, 이후로는 TypeBaseFetchingPolicy와 비슷하게 동작합니다.

예시로 mechanic.py에 get_skill_priority()를 작성해 두었습니다. 여기서 의아했던 점은 '서포트 웨이버(버프) 등 설치기의 onAfter으로 걸려있는 버프도 일일이 명시해줘야만 버프 효과가 제대로 동작한다는 것이였습니다. 오버 드라이브(페널티)도 마찬가지입니다. 그런데 메탈아머 전탄발사(버프)는 또 없어도 괜찮고... 이 부분은 확인 부탁드립니다.

적용하면 1800s 기준 약 2%정도의 딜 차이를 보입니다. 큰 차이는 아니지만 두가지 장점이 있습니다.

• 딜점유율이 더 정확하게 나옵니다.
  • 기존에는 호밍 미사일(봄버)(전탄)의 점유율이 지나치게 낮게 나왔습니다. 스킬 가동 순서가 꼬여서 봄버와 전탄 사이에 딜레이가 매우 길었습니다.
• 10초 딜을 측정할 때 더 정확합니다.
  • 가장 문제되던 부분이 맨 처음이였으므로, 10초딜에서는 확실한 차이를 보입니다.
  • 메카닉 기준 약 5.8%의 딜 차이가 납니다.

[oleneyl]

말씀해주신 버그의 발생 원인은 다음과 같습니다. 사실 버그까지는 아닙니다.

• Simulator는 generate()를 통해 접근가능한 object를 받아옵니다.

• Simulator는, Policy를 통해 다음에 사용 할 object를 받아옵니다.

• Simulator는, 사용할 object를 사용한 후, onAfter method 등으로 연계된 다른 object를 사용합니다.

• 서포트 웨이버(버프), 오버 드라이브(페널티) 는 직접적으로 사용되어야 합니다.

• 메탈아머 전탄발사(버프)는, 전탄발사 이후에 사용되므로, 직접 사용할 필요는 없습니다.

• 이는 코드 내에서 확인가능합니다.

SupportWaver.onAfter(SupportWaverBuff.controller(1)) # SupportWaverBuff의 남은 쿨타임을 1ms로 변경합니다. 사용하지는 않습니다.
Overdrive.onAfter(OverdrivePenalty.controller(30*1000)) # OverdrivePenalty의 남은 쿨타임을 30s로 변경합니다. 사용하지는 않습니다.
BusterCallInit.onAfters([BusterCall, BusterCallBuff]) # BusterCallInit이 사용된 이후, BusterCallBuff를 사용합니다.

Policy를 변경하는 사안은 괜찮은 것 같습니다. 한번 진행해보는게 좋을까요?

[icepeng]

주석으로 설명해주시니 바로 이해가 되네요. 감사합니다.

오버 드라이브(디버프)의 사용 횟수가 오버 드라이브의 2배로 찍히던데, 쿨타임 변경될 때도 사용으로 찍히는 거였군요.

그렇다면 onAfter가 아닌 controller(1)으로 구현된 이유가 따로 있을까요? 오버 드라이브는 그럴 수 있겠다 싶은데 로봇 버프들은 바로 연결되어도 상관없지 않을까 싶습니다.

Policy 변경은 진행해두면 좋을 것 같습니다. 아무래도 가동률 plot이 더 이쁘게 찍힐 것 같습니다.

[oleneyl]

• 아마 한 일년정도 전에 구현한 형태라 예쁘게 안바꿔둔것 같습니다. onAfter로 구현되어도 됩니다. 변경하셔도 될 것 같습니다. 다만, 이경우 버프들의 쿨타임을 -1로 주어야 onAfter 이외의 방식으로 실행되지 않습니다.
• 그럼 branch를 하나 따서, 직업들에게 해당 부분 작업해주어야 겠습니다.