安装 Steam
登录
|
语言
繁體中文(繁体中文)
日本語(日语)
한국어(韩语)
ไทย(泰语)
български(保加利亚语)
Čeština(捷克语)
Dansk(丹麦语)
Deutsch(德语)
English(英语)
Español-España(西班牙语 - 西班牙)
Español - Latinoamérica(西班牙语 - 拉丁美洲)
Ελληνικά(希腊语)
Français(法语)
Italiano(意大利语)
Bahasa Indonesia(印度尼西亚语)
Magyar(匈牙利语)
Nederlands(荷兰语)
Norsk(挪威语)
Polski(波兰语)
Português(葡萄牙语 - 葡萄牙)
Português-Brasil(葡萄牙语 - 巴西)
Română(罗马尼亚语)
Русский(俄语)
Suomi(芬兰语)
Svenska(瑞典语)
Türkçe(土耳其语)
Tiếng Việt(越南语)
Українська(乌克兰语)
报告翻译问题








These changes are nice! For the ammo mechanic, does it still function off a constant trickle of consumption like normal, or were you able to figure out how to have it only get consumed when firing?
Thankfully, they run on flamethrower rules. to be more precise, the ammo time only ticks down while the turret has a target locked on.
As an example, I've set the Missile pod turret to accept 8 Missile crates for full ammo. I've also set the ammo time as well as rate of fire so that it will only ever fire 8 missiles on 1 salvo from full to empty.
It doesn't always work out that way though; on instances where the salvo is interrupted, say. the target dies as soon as the 7th missile fires, the ammo time will stop immediately, then start again when it has a new target. Since reload times are accounted for when I set up the length of the ammo time, if the reload between the 7th and 8th missiles are taken out there's a chance it might fire a 9th missile. The chance to fire additional missiles increases if there are more interruptions and more reload times are ignored.
There's no way around that though, so I've just learned to accept it as part of game play, call it the gatcha missile or some sh*t.
Wish there was a way to implement that mechanic for human weapons. Ark Builder gave me some theoretical coding examples but it's a steep climb.
I just tested it; they do show up, but since bullets travel so fast they don't often render until the target is far enough.
Edit: I attached a picture at the gallery as proof, though I'll delete that in a few days.