Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

加一个建议刷新时间 #4

Open
JenningsWu opened this issue Jan 8, 2017 · 7 comments
Open

加一个建议刷新时间 #4

JenningsWu opened this issue Jan 8, 2017 · 7 comments

Comments

@JenningsWu
Copy link
Member

计算泊地修理效率,增加一个"建议过多久之后回港刷新",供(甘地)玩家参考。

效率定义:用于修理的有效时间 / 总时间
例如:
某长门回复一点 HP 需要 25min,那么在 20min 时,由于游戏机制此时回港必定回复一点 HP,效率为 25 / 20 = 125%。而在 60min 时,回复 2hp,效率为 2 * 25 / 60 = 83%。

ps1:记得好像说修理是有延迟的。如果说理论上 25min 修复一点,那么 50min 时马上回港并不能修复 2hp,而要等到 50min + 10 ~ 30 s 后才能回复两点。具体延迟多久我也忘了。
ps2:旧版那个泊地修理插件有这个计算

@KagamiChan
Copy link
Member

KagamiChan commented Jan 8, 2017

@JenningsWu 现在有一个预计回复量的计算,还有一个已过去时间的计算,算起来应该没问题。但是不知道放哪里好 = =

据说是有延迟的,不过没找到确信的参考来源,我自己测的话太麻烦(躺),所以就等有没有人报告出错了……
不过应该还好,预计回复量的更新本来就是隔几秒 setState 刷新一次的(性能考虑),此外大概没有人能卡得那么精准

@JenningsWu
Copy link
Member Author

作为 label 放在最上边单列一行?
延迟的话我之前自己定性测过,记得大概在 10 ~ 30 s 之间。

@KagamiChan
Copy link
Member

这个感觉是和船本身属性相关的,可能需要放到表格里,我看是和预计回复量放一起还是单开一列吧
现在列出明石修理时间和入渠修理时间是为了方便看修理话不划算的,好像也可以考虑和原版那样不显示

@KagamiChan
Copy link
Member

@JenningsWu 确认一下,刚才举的例子里面,“理论上 25min 修复一点这个的理论时间是基于 api_ndock_time/ (api_maxhp - api_nowhp) 来算的吗

@JenningsWu
Copy link
Member Author

JenningsWu commented Jan 8, 2017

@KagamiChan 是根据那个来算。

和船无关吧,只需要计算总的维修效率,不需要列出来每只船的维修效率。
例如当前编队有两只船,一个单位维修时间是 25min,另一个是 30min,那么在 40min 时的总效率为 (25 + 30) / (40 * 2)

另外目的不是为了算当前效率,而是寻找一个从当前开始的效率最大值,所以是要算当前效率、以后的几个船只 hp 回复的时间节点的效率,然后取最大作为“建议刷新时间”。
以及,最好再加一个可设置的 input,类似于“检查之后 X min 内何时回港效率最高”。

@KagamiChan
Copy link
Member

KagamiChan commented Jan 9, 2017

@JenningsWu 那个总时间本身会多 30s,所以会是不准的
哦,是这个意思,受教了,加两个显示项:当前维修效率,距下次建议刷新时间的倒计时,这样子?

@KagamiChan
Copy link
Member

聊天记录找不到了……忘了当时说好该怎么改了……

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants