Цитата:
We value compatibility and performance over raw flexibility in this sense. Just because you "can" do something with script doesn't necessarily mean that it's a good idea. We use this logic in determining whether a given feature will be exposed to script- if it doesn't belong in script for performance and compatibility reasons, we don't add it.
Both physics and sound are no-go as far as script is concerned. We're happy to expose interfaces to control the physics system (for example, setting traction parameters, providing a scripted cab interface, etc.) but we're not going to provide mechanisms for implementing a custom physics simulation in script. Similarly, we provide basic sound playback support for user interface purposes and so on, but we're not going to provide the detailed controls necessary for implementing engine sounds or track sounds.
|
Типа скрипты должны использовать дефолтную кривую и нерусскую физику, а не реализовать ту, которую хотелось бы. То есть в реалистичной физике и звуках они не заинтересованы — ТРС игра для детей. В таком плане он мне неинтересен.
Цитата:
> These derive from a misunderstanding of what scripts should be
> doing. Scripting is not intended to allow external parties the
> ability to re-implement major game systems; it's intended to allow
> command and control of the existing systems. Anything that extends
> beyond that will very quickly run into performance and compatibility
> issues, so we actively discourage it.
|
Ну и отписка про совместимость и производительность. Будто все вокруг мудаки и только и хотят писать тормозной код, а Ауран, в каждом релизе калечащий совместимость, во всем белом.