Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
BTW, using a stacking limit of 50,000 isn't advisable: such a full stack doesn't split well repeatedly. A better value might be 40,000, since it is divisible by two multiple times.
The changes are too extensive for me to paste them into a code block here. It would take me perhaps two hours just to condense those changes alone down into a compact form.
In other words, there's a lot of work to it. It's not even just tedious, it's also non-trivial.
I did a lot of testing on this, also on current version (1.8.3)
stacks above 30000 can cause item loss!
there seem to be some exceptions for some items
I did never encounter problems with a general limit of 30k
increasing a stack that defaults to 1 can also cause errors, I keep them untouched
(if you are not planning to use those items and just want to sell them there should be no errors)
(you maybe did not notice item loss since it only affects large amounts of stuff)
(i nekro this bc it's (still) a top search result for this topic and I just tested it again after coming back to empyrion after a while)
I've been using a stacksize of 40,000 in the game for no less than FOUR YEARS. You have to be mindful when stacking weapons, armor, armor boosts, etc.; trying to deploy boosts directly from a stack of them WILL cause the stack to be lost (a boost must be peeled from the stack BEFORE deployment). Otherwise there is no item loss, and your claimed stacksize limit is a fiction.
offense?! where is the logic in that? well, not very nice for a vulcan guy, and if your logic works, and if you are able to read and understand: i stated the reason why I necroed. a very good reason. AND i said i did the testing again with CURRENT VERSION! -- (i think it is some typecast error where some values are handled as dwords in the code sub functions and/or SQL, so 30k is 100% safe. and I bet you did no extensive and depth testing like i did and on a datatype base.) I bet some ppl will find this info at this place useful. and as a side note: 2 years ist a lot vor Microsoft for example, even more for google, almost nothing for a solo app developer, what do you think it is with the Empyrion devs? nothing more to say for me here.
EDIT: the mentioned method still works!!!
I've invested over 6000 hours playing the game, the majority of that spent using a stacksize of 40,000 for every player-usable object in the game, which I have extended to new game objects as they were added. I chose that value because of its useful divisability. There is no arbitrary 30,000 limit, as you claim.
stacks above 30k means also /far above/.
stacks up to 65k should be fine up to max at 65535.
for the case of signed values 32767 is it, rounded to 30k. that is a safe value with some coding knowledge in behind. i was not precise at saying exceeding that 65k "limit" i did not mean above 30k, should have said 65k.
it is possible to set values above and it works, but only partially, you can reproduce it if you create a full stacked box at 65k (16bit) and change it to the next integer range (65538 to 4.294.967.296 32bit) between 2 saves (and/or try to change back). that works for some blocks, for some it does not. the code is loosing some stuff when re-arranging stacks at these values. it is a bit random. (i guess it is a threading issue that can happen at CPU peaks) but it never happened with stacks below 30k(also 65k i guess)
the config file works for me but i have a rather small and clean one primary for self created sections and few other things. also more changes are in the other files. maybe my changes do not cause the said impact. so we both are correct.
and please, stop the offense. i've necroed it, ok, you do not like it, me neither, but again: it is a(the) top result when searching for it and manymany other threads have the same age and valuable content that is still up to date. no reason to try to bash me. that only helps your bad karmas and maybe gives some fun for others reading this...
have a good time out there!! i leave this planet now
It still works for some things, but does not work for other things.
For example it works for blocks but not for items.
It's unknown how much longer the config.ecf file will continue to function at all, so it's best not to use it and to instead use the actual config files.
Not only is the initial effort non-trivial, THEN you have to maintain it: every time a game patch - and there are at least half a dozen every year still - change the file(s) that you have modified, you have to identify what has changed and merge it into your modded file(s). Not doing this can break the game or make it behave unexpectedly. In order to do this safely and preserve the vanilla game intact, you have to create a custom scenario to encapsulate your changes.
As someone entirely new to modding you could still do this, but it will be challenging and you'll be spending far more time modding than playing. I played the game for at least two or three years before any sort of modding was even available for the game, so I was already intimate with the game mechanics.