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
Yes, this works in 1.4 / 2025
The Liquid ID matching FU in the first place, is very likely a mistake on our part long ago - as we didn't check the FU ID repository prior to implementing ID values.
If you'd like me to update to a new value, I'll make sure to check Elithian Races & Frackin Universe IDs and set something that's compatible with both of those, but please make the change locally if you have further issues after that change (might be preferable to make a local change to begin with!)
On a side note, I'm glad that FU is overriding Liquid Ammonia with Refined Mech Fuel and not the other way round, as that would've had greater implications on players.
No, this isn't intentional behaviour, and is a problem with FU.
Having recently just looked into the Frackin Universe github page: https://github.com/sayterdarkwynd/FrackinUniverse/blob/master/liquids/mechfuel.liquid
I have noticed that a Liquid ID of 20 is used for Refined Mech Fuel which is the same as Liquid Ammonia's ID. This means that FU is overriding the placement of Liquid Ammonia with Refined Mech Fuel.
This is significant because Starbound has a limited Liquid ID list of up to 255, meaning you can only have a maximum of 255 different liquids in the game, which is including the vanilla ones.
If I change the current value to be compatible with FU, it might possibly break another mod that uses a different ID.
You're welcome to change the ID locally though! (\Avali-colored-Items\liquids\ammonia.liquid) and change "liquidId" : 20, to a different value. Feel free to experiment!
(Stalker's Cloak s & f cover etc)
The item ID of the main crafting object is colorizer (with colorizer4 being the old one), and is added to avali.species via a patch file to be added to the crafting menu.
The mod actually also adds liquid ammonia (/spawnitem liquidammonia 1000) and a bottle of ammonia (/spawnitem bottledammonia 1000)
Furthermore, removing this mod would remove all of your coloured objects you used from this mod, which would be problematic for people with established builds. :)
Maybe it should be notified on this mod page as so people don't install it in case it just causes conflicts?
Interesting. Can't really change that now without affecting existing storage other players have, but it's good to know.
Both with and without Frackin. Please provide a pastebin with your starbound.log file contents inside, that may help with finding the issue.
The colorizer should never be empty, even with other races.
I just tested with Frackin and it was working just fine with the most up to date version available from Steam.
I believe the main reason for this is that the other tapestries at the time simply did not exist in the game image files, so we had to make colours up on the spot.
I'm not against the current versions, but.
I can see a reason to make a batch of new ones that fit more with the general colour palette theme to go along with the colours present in the other avali objects.
but then last time I used it, I used recoloured tent objects and did not even check the clothing. the instantiate errors are also oddly far away from where the error reports (like halfway down my logs) usually. could be nobody noticed it, but can also just be my setup. Either way if it works for others its not the most critical of things to fix
This error is quite bizzare, given that the actual item file should only be looking for one portion, not the other. I suspect it reads the other, in order to tell where the :chest is in that line.
Unfortunately, I will not know whether it is actually fixed or not if I implement a patch, due to the game not telling me. I'll just have to assume when I do so (I may just opt to do your method to remove the hassle entirely).
And yeah, not instantiating means the item itself became a PGI (Perfectly Generic Item), which is why I said it was unusual, as that isn't meant to happen, as that makes the items unspawnable.
Funnily enough, if you check bug reports someone already did the same fix you did in order to fix in the meantime (but it wasn't a instantiate error, so I didn't feel like I absolute must fix it at the time).
I was not aware it was an issue that would cause the items not to load with some mods, though. I figured conflicting mods would produce an error at the most.
So, thanks for the heads up!
[Error] Exception caught loading asset: /items/armor/avali/cloakarmsset5/icons.png:chest, (AssetException) No associated frames file found for image '/items/armor/avali/cloakarmsset5/icons.png' while resolving image frame '/items/armor/avali/cloakarmsset5/icons.png:chest'
[Error] Could not instantiate item '[cloakarmsset5chest, 1, {}]'. (AssetException) Error loading asset /items/armor/avali/cloakarmsset5/icons.png:chest
The above appearing for: cloakarmsset5, cloakarmsset5chest, avaliscientistarmsfcoverset9, cloakarmsset5b, cloakarmsset5c, cloakarmsfcoverset5c, cloakarmsfcoverset5cchest, avaliscientistarms9, cloakarmsfcoverset5, cloakarmsfcoverset5b, avaliscientistarms9chest
Turns out, Avali Triage mod has no purple value in their .frames files, making purple unusable and unreadable from the Avali Triage mod. They use "pink" as a value instead of "purple" - which is funny considering said "pink" is actually purple in look.