Smorty

joined 1 year ago
[–] Smorty@lemmy.blahaj.zone 2 points 3 days ago (1 children)

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).

ExampleI 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 embedding either 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 this first token delay a 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.

[–] Smorty@lemmy.blahaj.zone 1 points 4 days ago (3 children)

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.

[–] Smorty@lemmy.blahaj.zone 5 points 6 days ago

Ollama is really great. The simplicity of it, the easy use via REST API, the fun CLI...

What a fun program.

[–] Smorty@lemmy.blahaj.zone 4 points 1 week ago* (last edited 1 week ago)

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

[–] Smorty@lemmy.blahaj.zone 3 points 1 week ago* (last edited 1 week ago)

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:

 

video descriptionThe video shows the Godot code editor with some unfinished code. After the user presses a button offscreen, the code magically completes itself, seemingly due to an AI filling in the blanks. The examples provided include a print_hello_world function and a vector_length function. The user is able to accept and decline the generated code by pressing either tab or backspace

This is an addon I am working on. It can help you write some code and stuff.

It works by hooking into your local LLMs on ollama, which is a FOSS way to run large language models locally.

Here's a chat interface which is also part of the package

video descriptionThe video shows a chat interface in which the user can talk to a large language model. The model can read the users code an answer questions about it.

Do you have any suggestions for what I can improve? (Besides removing the blue particles around the user text field)

Important: This plugin is WIP and not released yet!

[–] Smorty@lemmy.blahaj.zone 1 points 1 week ago (1 children)

Hey, that's really cool! So with a VPN, I could steer this thing form anywhere! That ks for telling me.

[–] Smorty@lemmy.blahaj.zone 2 points 1 week ago (1 children)

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

[–] Smorty@lemmy.blahaj.zone 2 points 1 week ago (3 children)

Ja aber wo seid ihr beide denn? :3

[–] Smorty@lemmy.blahaj.zone 2 points 1 week ago

15 MegaMeter!

[–] Smorty@lemmy.blahaj.zone 2 points 1 week ago

Es ist noch viel lustiger beim zweiten Mal!

[–] Smorty@lemmy.blahaj.zone 1 points 1 week ago

Eine sehr gute Pizza. Eine der besten vorgefertigten Gerichte, die ich ja aß.

 

Hi there!

I'm looking into getting myself a good printer and I am wondering if I need to install some platform-specific drivers for them to run. I am running Debian 12 (GNU/Linux) and I am afraid that I must run some proprietary blob to connect to the printer.

Could someone share their experience please? Even if you don't use Linux, your feedback would be very appreciated!

(Also, while you are at it, please share some recommendations for printers, I don't really know where to go (>v<) Have about +-500€ )

 

I want to instatiate the inspector of a specific type like int and String into my own inspector plugin. It would be incredibly useful to use the premade inspector types as they are just really well made.

The image is not related, I just wanted to put some visual here.

 

Image descriptionThe linked image depicts a screenshot of some snowy terrain I made using the Terrain3D plugin for Godot. On the left there is some differently textured snow and multiple cabins along with some other wooden objects.
.

Why can't I use LightMapProbes without the LightMapGI Node? I don't want to use the shadow-baking, I just need the global illumination!

This is something I though about for quite a while. I keep wanting to use some kind of global illumination and the LightMapProbes are a perfect fit for that. One can place them whereever useful and their customizability makes them an incredibly useful tool! When there is a red wall, I sure want to put a LightMapProbe there, so that the lighting can reflect that reflection there.

But nope, that's not how it works! When you want to use LightMapProbe, you MUST use it with the LightMapGI Node, which is mostly used for baking shadowmaps. That works great for small scenes like insides of houses and such, but it does not work with a large terrain for example. This means that we have loads of lighting methods for small scale scenes (VoxelGI, LightMapGI, ReflectionProbe) but for larger areas we are kinda stuck with SDFGI which only works on the Forward+ renderer.

SDFGI is great and all, but unfortunately it is not yet ready for large scale games I feel and its limitation to Desktop platforms really limits its scope.

Imagine how cool it would be if we could do this in a large scale world:

  • Use a ReflectionProbe for general treversal (that's what The Legend of Zelda:Breath of the Wild and Tears of the Kingdom does too btw!)

  • And use a multitude of LightMapProbes for smaller areas like towns and castles on the overworld to make for better global illumination.

TLDR: I feel that the usage of LightMapProbes and their lighting functionality should be expanded beyond the use in combination with the LightMapGI Node. It could allow for better lighting in large scale worlds.

 

When animating my character in blender, I get somewhat smooth animations. I also made sure to use that cycles modifier so that it always knows how to interpolate the transform values

But when importing this model with the animations reguardless of the file type (.blend or .gltf / .glb) the animations don't loop very well

Does someone know how to fix this?

 

The messages here are mostly in German, but I'll try to translate mist of it:

**dpkg:** Error when editing the package linux-image-6.9.7+bpo-amd64 (--configure): <<Installed posts installation script of the package linux-headers-6.9.7+bpo-amd64<<-subprocess returned error code 1 **dpgk:** dependency error hinders configuration of <that Linux header package>: linux-headers-6.9.7+bpo-amd64 depends on linux-image-6.9.7+bpo-amd64 (= 6.9.7-1~bpo12+1) | linux-image-6.9.7+bpo-amd64 -unsigned (= 6.9.7-1~bpo12+1); but: Package linux-image-6.9.7+bpo-amd64 is not configured yet. Package linux-image-6.9.7+bpo-amd64-unsigned is not installed. **dpgk:** Error while editing the Package linux-headers-6.9.7+bpo-amd64 (--configure): Dependency problem - remains unconfigured **dpkg:** Dependency problem hinder configuration of linux-headers-amd64: linux-headers-amd64 depends on linux-headers-6.9.7+bpo-amd64 (= 6.9.7-1~bpo12+1); but: Package linux-headers-6.9.7+bpo-amd64is not configured yet. **dpkg:** Errow while editing package linux-headers-amd64 (--configure): Dependency problem - remains in configured Errors occurred while editing these: linux-image-6.9.7+bpo-amd64 linux-headers-6.9.7+bpo-amd64 linux-headers-amd64

I really hope someone can help me out here..

EDIT: I kinda forgot to actually mention my problem. When booting nornall, I get stuck at a lonely white blinking cursor on a black screen, so startx seems to make some problems. I enter a TTY and run startx and this is what I get when running startx:

output of startx

SOLUTION

  • Uninstall your current nvidia driver (for example using sudo apt remove nvidia-driver on Debian)
  • Install the headers for your kernel. your kernel you can check rather easily by running neofetch
  • Install the headers required for your kernel. Do that by listing all packages with your kernel name in it. For example like this: apt list *6.9.7+bpo*
  • reboot, install your nvidia driver again and rovoot again. Should be done.
 

Exactly what the title says. It's under MIT lisence and currently being approved by the moderators of the AssetLib. The project is currently very simple and contributions are very welcome! image of the tool window

 

Is this a feature or just another bug on the canvas?

Also right now it just keeps on trying to load the canvas while it all stays white. "Not cached" it says, but it just waits right there...

20
submitted 4 months ago* (last edited 4 months ago) by Smorty@lemmy.blahaj.zone to c/godot@programming.dev
 

I want to implement a threaded loading component into my game. I am currently saving all my settings and other level files as bytes externally (meaning not in the res:// folders), as I want to be able to export files and send them to others, so they can use them as well. There is the ResourceLoader.load_threaded_request() method, but that only returns Resources and not PackedByteArrays. As far as I can tell, there is only the FileAccess.get_file_as_bytes() method for importing byte files, which has to run in the main thread (and thus blocking it until the load is complete). Does someone know if I am missing some method here?

EDIT: I have put my fix for this into the comments

 

I have been trying to make receiving file paths really easy, with this method in an autoload:

func file_dialog_path(extentions:PackedStringArray = [], dialog_type:FileDialog.FileMode = FileDialog.FileMode.FILE_MODE_OPEN_FILE) -> String:
	var new_dialog:FileDialog = FileDialog.new()
	new_dialog.min_size = Vector2i(400, 400)
	new_dialog.access = FileDialog.ACCESS_FILESYSTEM
	new_dialog.file_mode = dialog_type
	for i in extentions:
		new_dialog.add_filter(i)
	get_tree().current_scene.add_child(new_dialog)
	new_dialog.popup_centered()
	var file_path:String = ""
	new_dialog.file_selected.connect( func receive_path(path:String):
		file_path = path
		print("file path from within the signal: ", path)
		return path)
	file_path = await new_dialog.files_selected
	print("this is the file now", file_path)
	
	#while file_path == "":
		#await get_tree().create_timer(0.1)
	return file_path

I commented out the while loop, as it froze the entire game when I do this.

I have tried this many times now, but the method always seems to get stuck somewhere. Right now, it gets stuck in the "receive path" function, where it will print the path, but not actually return. I am receiving the output from the file_dialog_path method like this:

var file:String = await file_dialog_path(["*.mml"], FileDialog.FileMode.FILE_MODE_SAVE_FILE)
print("This is the filepath for our level ", file)

Could anyone help me with this? The best idea I have right now would be to let that commented while loop run on a thread, but that seems unneccessarily difficult for such a simple problem.

17
I made an SDF Control Tool (files.catbox.moe)
submitted 4 months ago* (last edited 4 months ago) by Smorty@lemmy.blahaj.zone to c/godot@programming.dev
 

I made a Node which allows for very quick coloring and animating of signed distance field textures. In the linked video, a short demo shows what one can do with this Node and some signed distance field textures. Here is a little tour of the usage of the Node. Should I put it on the asset library, or is this kind of stuff too specific to be useful?

 

I didn't make any changes in the project settings or something, but I did change some GDScript. After I did that, every time I open a different scene in the scene dock the Engine crashes. This right here is the backtrace:

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.2.stable.official (15073afe3856abd2aa1622492fe50026c7d63dc1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x3c050) [0x7fbfbac9c050] (??:0)
[2] godot::SceneTree::get_edited_scene_root() const (??:0)
[3] OrchestratorMainView::_on_scene_tab_changed(int) (??:0)
[4] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x3b38b48] (??:0)
[5] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x3ba02d0] (??:0)
[6] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x15aca36] (??:0)
[7] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x3ba02d0] (??:0)
[8] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x2391ef6] (??:0)
[9] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x23a255d] (??:0)
[10] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x20cdda5] (??:0)
[11] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x2126a2e] (??:0)
[12] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x212884e] (??:0)
[13] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x21376e9] (??:0)
[14] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x420ac0e] (??:0)
[15] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x493d3f] (??:0)
[16] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x3963f82] (??:0)
[17] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x396575f] (??:0)
[18] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x497bfd] (??:0)
[19] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x41e8a6] (??:0)
[20] /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7fbfbac8724a] (??:0)
[21] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7fbfbac87305] (??:0)
[22] /home/marty/Schreibtisch/Godot_v4.2.2-stable_linux.x86_64() [0x42a59a] (??:0)
-- END OF BACKTRACE --
================================================================

I can also share the project files if that would be useful (I plan on open-sourcing it either way). I am using Debain 12 (GNU/Linux) using Gnome. In the backtrace I used Godot 4.2.2, but until just now where the crashes set in, I was using the latest Godot 4.3 dev6 build. So these crashes don't occur because of the dev builds.

view more: next ›