Introduce Dispel skill #2435

U-lis · 2024-03-04T02:23:51Z

Add affected to SkillInfo to flag current buff/debuff is affected to target.
Update ProcessBuff function to add dispel effect.
AddBuff function now returns dispelList which is list of removed skill by dispel buff.

This PR resolves #2389

- Add `affected` to SkillInfo to check current dispel is affected - Update `ProcussBuff` function: Add dispel effect - `AddBuff` function now returns dispelList which is removed by dispel buff

pull-request-quantifier-deprecated · 2024-03-04T02:23:57Z

This PR has 227 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Large
Size       : +166 -61
Percentile : 62.7%

Total files changed: 13

Change summary by file extension:
.cs : +160 -60
.csv : +6 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-04T16:34:57Z

This PR has 300 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Large
Size       : +235 -65
Percentile : 70%

Total files changed: 16

Change summary by file extension:
.cs : +229 -60
.csv : +6 -5

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

…world-8-dispel

pull-request-quantifier-deprecated · 2024-03-04T23:21:35Z

This PR has 303 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Large
Size       : +238 -65
Percentile : 70.3%

Total files changed: 17

Change summary by file extension:
.cs : +229 -61
.Libplanet : +1 -1
.csv : +8 -3

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-05T01:30:29Z

This PR has 333 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Large
Size       : +268 -65
Percentile : 73.3%

Total files changed: 17

Change summary by file extension:
.cs : +259 -61
.Libplanet : +1 -1
.csv : +8 -3

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

U-lis · 2024-03-05T01:48:12Z

리뷰 주안점

Dispel 은 사용 시, 지속 시 양쪽에 효과가 있다. 두개의 효과가 각각 알맞은 타이밍에 계산되는지 확인 필요.
Dispel 은 debuff 만 지워야 하고, buff 는 남겨야 한다. 기준은 SkillSheet 에 Debuff 로 되어 있는 것들.
- deuff 를 찾기 위해 좀 복잡한 방법을 쓰고 있는데, 더 간결하게 할 수 있는 방법이 있을지?
Arena 에서도 잘 작동하는지 확인 필요. (아레나 테스트를 만들어야 할지도)

Lib9c/Model/Character/CharacterBase.cs

pull-request-quantifier-deprecated · 2024-03-06T02:25:15Z

This PR has 460 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +395 -65
Percentile : 82%

Total files changed: 19

Change summary by file extension:
.cs : +386 -61
.Libplanet : +1 -1
.csv : +8 -3

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

Lib9c/TableCSV/Skill/SkillSheet.csv

pull-request-quantifier-deprecated · 2024-03-06T09:02:18Z

This PR has 475 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +410 -65
Percentile : 82.5%

Total files changed: 19

Change summary by file extension:
.cs : +401 -61
.Libplanet : +1 -1
.csv : +8 -3

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-06T09:05:54Z

This PR has 475 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +410 -65
Percentile : 82.5%

Total files changed: 19

Change summary by file extension:
.cs : +401 -61
.Libplanet : +1 -1
.csv : +8 -3

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

Lib9c/Model/Character/ArenaCharacter.cs

jonny-jeahyunchoi · 2024-03-06T09:10:35Z

Lib9c/TableCSV/Skill/SkillSheet.csv

@@ -173,4 +173,5 @@ _250001,속도 증가(전체),Normal,Buff,SpeedBuff,Ally,1,1 // 미구현
 700007,집중,Normal,Buff,Focus,Self,1,15
 700008,더블 어택,Normal,Attack,DoubleAttack,Enemy,2,15,true
 700009,디버프 제거,Normal,Buff,Buff,Self,1,15


기존 디버프제거는 Dispel 스킬카테고리로 같이 변경되어야할것같습니다~!
아니면 두개가 다른 스킬인건가요?

네 제가 알기로는 두개가 다른걸겁니다.
슈님께 더블체크 해봐야 할지도 모르겠네요

@NineSyu 디버프제거와 면역스킬은 스킬을 지우는 Dispel 기능을 사용하되 수치밸런스로 구분하는 스킬같아보이는데요 확인 부탁드립니다~!

- Use `IsDebuff()` in `AddBuff()` method - Use `IsDebuff()` in `ProcessBuff()` method

pull-request-quantifier-deprecated · 2024-03-07T01:56:11Z

This PR has 469 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +404 -65
Percentile : 82.3%

Total files changed: 23

Change summary by file extension:
.cs : +395 -61
.Libplanet : +1 -1
.csv : +8 -3

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

sonohoshi

LGTM

U-lis added 9 commits February 26, 2024 11:54

Add Dispel skill type

71a790f

Dispel on action: remove prev. buffs on me

80bd146

Make simulator public to use simulator.random from outside

cce9b95

Dispel skill for arena

6efcfca

Add dispel to BuffFactory

ba54aaa

Add dispel skill to csv

c1953c4

Remove old, unused logic

45b3a36

Add Dispel to skill category

0f133c6

Introduce Dispel skill

8994566

- Add `affected` to SkillInfo to check current dispel is affected - Update `ProcussBuff` function: Add dispel effect - `AddBuff` function now returns dispelList which is removed by dispel buff

U-lis added the enhancement New feature or request label Mar 4, 2024

U-lis added this to the v160.0.0 milestone Mar 4, 2024

U-lis requested review from ipdae, sonohoshi, eugene-doobu, tyrosine1153 and jonny-jeahyunchoi March 4, 2024 02:23

U-lis self-assigned this Mar 4, 2024

pull-request-quantifier-deprecated bot added the Large label Mar 4, 2024

U-lis added 4 commits March 4, 2024 23:21

Remove wrong, unused draft data

0d4c545

Add Affected to check skill is affected to target

2e8cf7c

Update Dispel logic to get target debuff

d476f6a

Test Dispel skill

1142735

Merge remote-tracking branch 'upstream/feature/world-8' into feature/…

02c20d7

…world-8-dispel

U-lis marked this pull request as ready for review March 4, 2024 23:21

U-lis requested a review from boscohyun as a code owner March 4, 2024 23:21

U-lis marked this pull request as draft March 4, 2024 23:26

Dispel blocks only debuffs

02b74c5

U-lis marked this pull request as ready for review March 5, 2024 01:30

Make Dispel works on arena

bd2a2db

ipdae requested changes Mar 5, 2024

View reviewed changes

Lib9c/Model/Character/CharacterBase.cs Outdated Show resolved Hide resolved

Lib9c/Model/Character/CharacterBase.cs Outdated Show resolved Hide resolved

U-lis added 3 commits March 6, 2024 09:31

Embed debuff list to simulator

f46b27d

Set debuff list to ArenaCharacter

5002869

Test Dispel skill

d6e397d

pull-request-quantifier-deprecated bot added Extra Large and removed Large labels Mar 6, 2024

U-lis requested a review from ipdae March 6, 2024 02:25

jonny-jeahyunchoi reviewed Mar 6, 2024

View reviewed changes

Lib9c/TableCSV/Skill/SkillSheet.csv Outdated Show resolved Hide resolved

Merge two loops to one

a994e49

Add Dispel type to SkillSheet

998c92a

sonohoshi reviewed Mar 6, 2024

View reviewed changes

Lib9c/Model/Character/ArenaCharacter.cs Show resolved Hide resolved

sonohoshi reviewed Mar 6, 2024

View reviewed changes

Lib9c/Model/Character/ArenaCharacter.cs Outdated Show resolved Hide resolved

jonny-jeahyunchoi reviewed Mar 6, 2024

View reviewed changes

U-lis added 4 commits March 7, 2024 09:42

Write summary to AddBuff function to help to understand dispel effect

80f534c

Update ISkill interface to get this skill is buff or not

974bb9d

Make all skills and buffs can check it is buff or not

3022931

Update buff logic

c6513df

- Use `IsDebuff()` in `AddBuff()` method - Use `IsDebuff()` in `ProcessBuff()` method

jonny-jeahyunchoi approved these changes Mar 7, 2024

View reviewed changes

U-lis requested a review from sonohoshi March 7, 2024 01:56

sonohoshi approved these changes Mar 7, 2024

View reviewed changes

eugene-doobu approved these changes Mar 7, 2024

View reviewed changes

U-lis merged commit 1c0eb23 into planetarium:feature/world-8 Mar 11, 2024
7 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce Dispel skill #2435

Introduce Dispel skill #2435

U-lis commented Mar 4, 2024

pull-request-quantifier-deprecated bot commented Mar 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 5, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

U-lis commented Mar 5, 2024

pull-request-quantifier-deprecated bot commented Mar 6, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 6, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 6, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

jonny-jeahyunchoi Mar 6, 2024

U-lis Mar 6, 2024

jonny-jeahyunchoi Mar 6, 2024

pull-request-quantifier-deprecated bot commented Mar 7, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

sonohoshi left a comment

Introduce Dispel skill #2435

Introduce Dispel skill #2435

Conversation

U-lis commented Mar 4, 2024

pull-request-quantifier-deprecated bot commented Mar 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 5, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

U-lis commented Mar 5, 2024

pull-request-quantifier-deprecated bot commented Mar 6, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 6, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 6, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

jonny-jeahyunchoi Mar 6, 2024

Choose a reason for hiding this comment

U-lis Mar 6, 2024

Choose a reason for hiding this comment

jonny-jeahyunchoi Mar 6, 2024

Choose a reason for hiding this comment

pull-request-quantifier-deprecated bot commented Mar 7, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

sonohoshi left a comment

Choose a reason for hiding this comment