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
0 
Report this post
I'm not sure there will be a fix, but then this doesn't represent anything but an annoyance... to modders like me who frequently look at the logs.
I looked at the source, and see no reason errors SHOULD be generated. Everything seems done correctly. The "no such item" items actually work fine in game. For example
I believe Starbound is inappropriately generating errors for problems that do not exist. Possibly the system that checks recipes at launch doesn't consider the possibility of a recipe generating... a recipe. I don't think a single thing could be done on this end unless both I and Weaver are missing something. But then again, nothing NEEDS done anyhow because everything works.
So again I say... ignore the errors. They're annoying but nothing more. And if you just can't do that, then examine the mod and point out anything that could fix the silly errors. I don't think you'll find anything but by all means give it your best shot.
Steam Proverb "Never ignore errors, and ignore people telling youto ignore errors."
On what basis do you believe YOU do?
I suspect nothing but gut level.
Still if you believe yourself more qualified to make that assessment, then point out where the "author has ♥♥♥♥ed up." This isn't a complex mod so it should be easy. Shouldn't take more than 20 minutes of your time. If you've checkout out the source, then you should be able to point out the errors.
If you've not done so, then you're completely unqualified to tell me(who has) anything about the subject because you'd then have no factual basis for your "knowledge." It's like you trying to argue the contents of a book that only I've read.
Two more questions. Have you ever coded anything in your life? Do you have even a basic understanding of how computer programs work? It really doesn't seem like you understand at all, but "my ignorance is as good as your knowledge" is a powerful notion to many.
1: Tamamo codes stuff for FU as well as myself. So yes, she can code just fine.
2: Yes, she has a basic understanding of how computer programs work.
So it seems your "gut" was incorrect in this instance. I don't see why you are flying off the handle about it, but you really don't need to be rude. Tamamo is merely calling it based on the information given. Granted, the response saying you didnt know what you were talking about comes across as rude...but even so. Your response was a lot more off the cuff.
The errors present themselves because there is an error. Period. This is not disputable. It might "look" fine to you, but there is quite obviously errors or they would not display as such.
I haven't personally viewed the code, but if they are using "itemname-recipe" as the output in recipe files...that is the issue. -recipe is only called in loot lists, and so forth, and not in the recipe files themselves. Those must have the item with its actual name, which the -recipe call refers to. That could be the source of the issue. It could be something else entirely , for all I know. Either way, it isn't my mod to fix.
but based on the error, that is akin to the issue. It is triyng to find "itemnameshiphatch-recipe" when it should be finding "itemnameshiphatch"
edit: yes, seems I am correct. I figured out the error *without even looking at the logs or code*.
Tamamo made the exact same conclusion in discord and verified in the mods files. Less than 2 minutes and we have the solution. Seems she does, in fact, know what she is talking about. Guess that makes her qualified.
First off, I do respect you Sayter and I recognize that you generally "know your stuff" with regards to Starbound. You've spent a tremendous amount of time on it. You probably know as much as anyone who doesn't have access to the C++ side of things. Nothing I say should give you the impression that I feel any different.
Apparently so. To you Tamamo is your friend. To me... "some person on the internet" so consider the difference in perspective as you reread this thread. Anyhow let this be a lesson to all about the reliablilty of assumptions and "gut."
I believe your perception here is colored by bias aka you "got your friend's back" and I suppose that's only natural. The assertion was made that I don't know what I'm talking about... without any basis given to back that assertion up. I'm not wrong to then question the qualifications of some random person on the internet making that false assertion. Neither am I wrong to ask if they've reviewed the source. I'm wrong to ASSUME what I did (and for that I apoligize), but that's still not taking as far as asserting such a thing. My response was fairly restrained IMO(you clearly disagree), although I'm more long winded and tone doesn't carry well over the internet. I could replace most of it with "citation needed" etc to convey the same message.
You know that "20 minutes" was intended to be a generous time frame rather than a speed trial or whatever. Putting that aside... you are both mistaken because your 'fix' changed the output. The edits you suggest would spawn the end product(objects). The intent is to unlock the recipes for players to build them(even if this mod where later uninstalled). A Novakid can learn how to build the Hylotl ship doors, etc. That's why a recipe produces "itemname-recipe" ...and that's why one should ALWAYS review the source no matter how qualified they are ;P The best of humankind is still merely human.
Not disputable...? Do not be so sure about that. As much as I see where you'd feel like that, I cannot agree and here's why. I've never used a piece of software that was truly perfect, and mostly likely neither have you. The system which generates errors should not be presumed infallible. This is a broader point than the context of Starbound alone. So lets step away to some other scenarios and then tie them back to the subject at hand.
Scenario 1. The main software process system of "ProgramXtreme 2.1"(what it does isn't important here) is designed to process files that are encoded in ANSI, UFT8, UFT16, etc. Before it runs, the files it would process are evaluated by a different system. This other system was never designed to process ANSI encoding and thus fails perfectly valid ANSI content. After getting past the evaluation system, you can add and thus process the ANSI file. Is the problem the content, or is the problem the pre-evaluation system's limitations?
Scnario 2. This involves Starbound specifically, but not the actual game. A while back I couldn't get a mod update to go on through the workshop uploader. Nothing about the state of the mod at that point caused issue with the game, nor did it make log entries. However the uploader kept failing, so I waited and tried again later. Several days later I was pretty annoyed. I decided to go ahead and upload to (just) the forums anyhow. But that too failed. And what did it take? Removing : from the description string in _metadata resolved the issues on the uploader and website(unless an amazing coincidence). "This:is a valid JSON string but the uploader wasn't having any of that." Was then the problem my _metadata, or the systems evaluating it? I do not know if this has since been resolved or not(but I could check I guess).
Now back to the current scenario. The game engine itself has no issue with the mod as-is. Whatever pre-evaluation occurs is failing the recipies despite being valid in game. That doesn't represent a problem in the content. Even if it is possible to change the content (I'm presuming The | Suit's -blueprint solution will work, will try that out in a bit) and prevent the error... that error still shouldn't trigger in the first place.
Update: that doesn't work either. Apparently only -recipe does unless you have other things to try.
Furthermore
So I maintain my position. You're under no obligation to accept my view, but I think that demonstrates well the merit of my position.
In any case, everyone have a good evening. Peace.
Just tried this edit. Something has changed as -blueprint doesn't work. What's more it generates the same starting error that -recipe does, but without the benefit of functioning when in game. You'll just get another error in game and a PGI.
So to match the current functionality, it apparently actually has to be -recipe
anyhow, to continue:
yes, /spawnitem mything-recipe will work. thats viable in-game. That's how they spawn blueprints you find in chests, etc.
but in a main recipe file you want just "myitemname". This is how its done in all vanilla assets (You don't want -blueprint as suggested by the other poster, since that isn't used anymore).
my main point is that there *is* an error, and it would be a simple thing to correct once localized. Specifically:
[11:07:30.620] [Error] Could not instantiate item '[glitchshiphatch-recipe, 1, {}]'. (ItemException) No such item 'glitchshiphatch-recipe'
the item is *not* glitchshiphatch-recipe. it is glitchshiphatch. it is looking for an itemID of "glitchshiphatch-recipe" which doesnt exist in any capacity and thus, failing. So whatever is calling -recipe here needs to simply be changed to remove the -recipe portion and the error should be fixed quite handily.
if you dont have this solved by later, perhaps ill do a quick fix or something (provided I can find the time to do so) as I've had to fix this exact sort of issue a trillion times in the past :)