I’m a person who tends to program stuff in Godot and also likes to look at clouds. Sometimes they look really spicy outside.
Currently the completion is implemented via keyboard shortcut.
Would you prefer it, if I made it automatically complete the code? I personally feel, that intentionally asking for it to complete the code is more natural than waiting for it to do so.
Are there some other features you would like to see? I am currently working on a function-refactoring UI.
Ollama is really great. The simplicity of it, the easy use via REST API, the fun CLI…
What a fun program.
I will likely post on here when I release the plugin to GitLab and the AssetLib.
But I also don’t want to spam this community, so there won’t be many, if any updates until the actual release.
If you want to have something similar right now, there is Fuku for the chat interaction and selfhosted copilot for code completion on the AssetLib! I can’t get the code completion one to work, but Fuku works pretty well, but can’t read the users code at all.
I will upload the files to my GitLab soon though.
EDIT: Updates the gitlab link to actually point to my gitlab page
Just fixed the problem where it inserts too many lines after completing code.
This issue can be seen in the first demo video with the vector example. There are two newlines added for no reason. That’s fixed now:
I mean, i know that they are literally cold, but what happened that were not excited about them?
Ok, why are soils cool now?
Hey, that’s really cool! So with a VPN, I could steer this thing form anywhere! That ks for telling me.
Hey, Frankfurt am Main! Das ist nicht allzu weit weg von mir. Ich wohne in der Nähe von Mainz, da kann ich einen zu spät kommenden Zug nehmen und ich bring meine Öhrchen mit <3
Ja aber wo seid ihr beide denn? :3
Es ist noch viel lustiger beim zweiten Mal!
Eine sehr gute Pizza. Eine der besten vorgefertigten Gerichte, die ich ja aß.
Tomaten und Gurken sind beide super. Aber Kartoffeln!? Besser geht es nicht
Ich hab das deutsch vorgelesen…
Saat, bot tru!
Gute Künstler kopieren, die besten Künstler stehlen!
Ich glaube, dies hier soll eine MaiMai vorlage sein. In etwa so:
Ich habe das
das Glas leer getrunken
Eine Wiederholung der Aussage ist angeblich humorös.
Sag, wo wohnst du denn? Dann könnten wir uns als Gruppe treffen! <3
You are right in that it can be useful to feed in all of the contents in other related files.
However!
LLMs take a really long time before writing anything with a large context input. the fact that githubs copilot can generate code so quickly even though it has to keep the entire code file in context is a miracle to me.
Including all related or opened GDScript files would be way too much for most models and it would likely take about 20 seconds for it to actually start generate some code (also called
first token lag). So I will likely only implement the current file into the context window, as that might already take some time. Remember, we are running local LLMs here, so not everyone has a blazingly fast GPU or CPU (I use a GTX1060 6GB for instance).Example
I just tried it and it took a good 10 seconds for it to complete some 111 line code without any other context using this pretty small model and then about 6 seconds for it to write about 5 lines of comment documentation (on my CPU). It takes about 1 second with a very short script.
You can try this yourself using something like HuggingChat to test out a big context window model like Command R+ and fill its context windw with some really really long string (copy paste it a bunch times) and see how it takes longer to respond. For me, it’s the difference between one second and 13 seconds!
I am thinking about
embeddingeither the current working file, or maybe some other opened files though, to get the most important functions out of the script to keep context length short. This way we can shorten thisfirst token delaya bit.This is a completely different story with hosted LLMs, as they tend to have blazingly quick
first token delays, which makes the wait trivial.