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 (ベトナム語)
Українська (ウクライナ語)
翻訳の問題を報告
but refueling sucks is well known problem
i basically copied a chemfuel generator (tweaked to be crafted via certain things, and to give an output of grown Mushrooms (rimshroom) every so many hours), but in 1 game, when i had like 20 of them, they all stopped producing when that timer was reached, (even in admin mode) :)
now i build less of them to play safe, but that same issue could crop up again im sure.
we have a sound error that when you exit the game may fill your entire hdd with FMod sound errors that has been known about since 1.1 but never fixed or even explained
the entire concept of
the reds egglayer comp fix needing to exist
if you have too many fueltypes on the map then the refueling comp may just die and tick everything as a backup
the deep drills has a backup state where instead of just ticking for stone
it ticks for everything in existence that is seen very commonly causing immense perf drain at just 3 drills
theres all sorts of these issues that were reported to ludeon and got told "its not viable to fix that"
but it WONT be a magic fix
everyone here keeps taking it as a magical fix for rws problems
as per my words
BAD CODE IS BAD EVEN IF YOU THREAD IT
and ludeon
Literally has repeatedly denied basic level optimizations
even something as simple as fixing a missing ! in an early exit
was denied for 4 years
As a C programmer, I do admit some programming paradigms are significantly faster than others, but the compiler often times fixes your skill issues. Regardless, there isn't a much larger 'problem' as the main bridge here is C# being used against it's intended purpose, this isn't made with IL2CPP. The best course of action to maintain the games modularity & improve execution speed is parallel execution, as the best way to optimise it from this point would sacrifice, if not destroy it's modularity all together which would make updates harder, and break most mods.
Uhhh, no.
Multi-threaded can quite literally (if done well) make it have significantly greater execution speed, especially on AMD devices with many cores. Even if the optimisation is garbage this would outperform a single (or in this case, dual-core) software setup.
Micro-optimising the code base would be to completely revoke use of Unity engine all together, as C# is not described for it's execution speed, as it's for modularity & high level abstractions.
'Bad Code' is somewhat a rare thing of modern time; Most compilers, especially of higher-level languages completely deny what you do, & compile to the 'more efficient ways' byte code.
Take C for example, run a check that'll never happen?
Denied, it's completely removed.
Make a recursive function?
Likely converted into a function with an unrolled loop to prevent stack spamming.
Threading simply isn't a magical fix to performance
Bad code is bad
Even if it's threaded
Ludeon doesn't care to optimize