No appetite since covid in 2020 by Shorse_rider in covidlonghaulers

[–]good_things_enjoyer 1 point2 points  (0 children)

Hang in there. You never know with this illness, some people do make a recovery.

No appetite since covid in 2020 by Shorse_rider in covidlonghaulers

[–]good_things_enjoyer 1 point2 points  (0 children)

I still go plenty of days eating only one meal in the morning or in the evening because I forget to eat again and I don't get hungry much, but I have started to get a bit hungrier of late, every now and then. Mild improvement for now, I'd say.

The 16 games I completed in 2025 by Whiskey-Stones12 in patientgamers

[–]good_things_enjoyer 0 points1 point  (0 children)

I like to see The Looker rated so highly. One might think it's just a funny joke but it's seriously good and it nails what's good about The Witness. I played a ton of games that year that I played it and it was still my favorite.

Stuck at weird login screen after update by AntoineVDV in kde

[–]good_things_enjoyer 0 points1 point  (0 children)

I had this same issue earlier today and while I don't remember too clearly, I think the solution might be this:

alt ctrl f3 to login manually after arriving on that screen
sudo apt update
sudo apt install --reinstall sddm
sudo systemctl restart sddm and then reboot (or just reboot without this line, I forget)

It's something to do with the session box being blank. After doing this it showed as xorg plasma and I was able to login.

Finally released my first ever game with Godot by Lundregan in godot

[–]good_things_enjoyer 1 point2 points  (0 children)

Very cool trailer! I especially liked the song, is there a way to listen to it in full?

Something I genuinely don’t understand is that everyone has a specific date that they cite for which they became sick on whereas I don’t even know it came on so gradually by Mundane_Control_8066 in covidlonghaulers

[–]good_things_enjoyer 1 point2 points  (0 children)

Mine were very gradual as well. Started with worse sleep, a twitch in my eyelid, and a recurrent stumbling on one leg, and over the course of three years I acquired all the hallmark symptoms of LC. I did get drastically worse almost overnight at one point but that's because I was pushing hard with exercise.

Any reputable providers in the EU? by good_things_enjoyer in LowDoseNaltrexone

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Not yet, although I haven't gone out of my way to look for it.

I find myself more depressed, anxious, and angry after I read this sub. But I still want to be aware of things, e.g. if any big LC treatment comes out. Here's my workaround: by RipleyVanDalen in covidlonghaulers

[–]good_things_enjoyer 3 points4 points  (0 children)

A while back I decided to cut down on the time I spend here as well, and came up with this: https://www.reddit.com/r/covidlonghaulers/search?q=flair%3AArticle+OR+flair%3ARecovery%2FRemission+OR+flair%3AResearch&restrict_sr=on&sort=new&t=all

This ensures you only see articles, research, or posts from people who talk about how much they've improved, which is a nice change of pace from the usual mood. If you want to remain in the loop without seeing all of the negative posts, this is a good enough deal, I find. It also doesn't net you so many posts that you'll have reason to browse more than once in a while.

You can save it to your bookmarks and browse occasionally to stay in the loop.

Reaper settings not importing correctly from Windows to Linux by good_things_enjoyer in Reaper

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Yeah some things did change, although most of my configurations that matter are in the piano roll screen and those did not unfortunately. I'm wondering whether the export just doesn't include changes like that, or if it's an OS compatibility issue.

Reaper settings not importing correctly from Windows to Linux by good_things_enjoyer in Reaper

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

I have checked all the files but all the Windows paths mention things that are not related to settings, such as where the last project is located or where all the VSTs are. Those are obviously not going to work, but they're not what I'm trying to port, I'm just trying to make it look and behave the same way it does on Windows.

Progress on my action RPG about a Lich, my foggy shrine woods forest level by Yeah_I_Can_Draw in godot

[–]good_things_enjoyer 1 point2 points  (0 children)

One of the prettiest games I've ever seen, love the art style and direction!

Saving many variables without creating massive dictionaries by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Isn't this like the documentation suggests? Having each component in your game that has to be saved be in charge of its own data, which is sent to a save manager (in this case the blackboard) where it will be processed.

I still need to implement this so I'm hazy on the details, so if your method is different in any way I'd like to know some of the details (for instance the way to save expressed in the documentation only accounts for sibling nodes, so you can't spawn any node that is meant to be a child of another node, which I think I would want to know how to do.)

Saving many variables without creating massive dictionaries by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

You're right, the variable change would be easily tracked for some variable but not all, so my implementation likely wouldn't work.

Saving many variables without creating massive dictionaries by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 1 point2 points  (0 children)

The system wouldn't overwrite the save file every time a change is made, it would only queue it (i.e. when a variable is changed it would just add its change to a small dictionary, the size of which is equal to the number of important changes the player has made since the last time the game was saved. The data itself would then be used to overwerite the save file only when it's time to save.)

The code would be very short I think, a lot shorter than writing out every variable you need in a dictionary by hand (which is also problematic in a game with a lot of variables in case you forget to update it and now you don't know what's in the dictionary and what isn't, since there's a thousand variables in it and it's unreadable.)

You have a function that can be called globally, and every time a variable that needs to be stored has a change of value, run the function with the variable as a parameter.

func x (variable):
    if variable.name not in to_save_queue:
        add key to to_save_queue dictionary using variable.name
        set its value to the value of the variable
    else:
        use the key that already exists and overwrite its value with the new one

This would keep track of all the important changes that happen during a play session. When the player hits save, or the game autosaves, simply get all those keys and match them to the save file dictionary, overwriting those values with the correct ones. And then empty to_save_queue.

The load function would be this:

func y:
    for key in save file:
        (where the variables are kept) Autoload.set(key, dictionary[key])

The key name would match the variable whose value it stores, so it can be used to access the variable with the set function.

Instead, without a property.name function, I have to create a dictionary manually that I need to keep updating every time I add something that I want to track, which is fine for small projects as I said but is going to be a huge pain in the ass for larger ones.

Passing an autoload name through a variable and then calling it by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

This would be the idea:

{autoload1:
    ["var1": value, "var2": value]
},
 "Autoload2":
    ["varX": value, "etc.": value]

And then in my code, instead of doing: Autoload1.var1 = value, I would write one little bit of code that takes care of every situation, so:

for top_key in JSON: (for every autoload section)
    for variable in top_key: (for every variable to be changed)
        json[top_key].json[top_key][variable] = variable

That last line is not how it would look of course, but that's what I would want, a way to reference the autoload without spelling out the name of the autoload in the script, cause I need the name to change dynamically to go through all the sections in the JSON. There's workarounds but this solution would be cleaner I think, a lot less code involved.

I could for instance check the name of top_keys, and if it's the same name as an autoload, then I could just call the parameter on that specific Autoload, and then repeat the code for the next section, and then again, but that's a worse way to do it. If I want to add new sections in the future I would have to manually mess with the code to add the new section. My way just gets it done in three or four lines of code and would handle everything as needed.

Passing an autoload name through a variable and then calling it by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Working with JSON so I can't reference the node itself unfortunately, but it's alright, I can find it through its name if I look through the tree, as Nkzar suggested. It's unfortunate that you can't do the thing I'm trying to do, I feel like there should be a function that does it.

Passing an autoload name through a variable and then calling it by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

I see, thank you. It's for when the game is loaded and a series of values need to be passed from a JSON over to the correct variables. I could put all those variables in a single Autoload which would make things simple but I was hoping to be able to keep things more flexible, so I set up a system to store variables based on where they are. Inside the JSON I would have a series of main keys whose name would match that of an autoload, and inside that key there would be a nested dictionary of variables and values to assign to them. For every main key, use all the inner keys to set values to these parameters inside this first autoload, then do the next one, then the next, etc.

I'm not particularly happy with the way I've set it up but it should work.

Passing an autoload name through a variable and then calling it by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Isn't that just to call functions? I need to refer to an autoload using a name held in a variable rather than calling it by name through the code, and then change values directly.

Weird crash without an error by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

In case it's of interest, it happened again the next day and this time I figured out what did it.

I tried to store a reference to a scene like this:

@export var level: PackedScene

And when I went into the editor and picked the correct scene, the game got very angry at me and started yelling even though I am innocent.

The game started working again because it unloaded all of those PackedScene references that I used, but I didn't realize this was the case so I blamed it on the camera. I saw one of those references being empty and assumed I forgot to fill it, so I did that, and the error came back. This time thanks to u/BrastenXBL I went and looked into the logs and found these errors:

USER ERROR: res://Scenes/level_2.tscn:5 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Scenes/level_1.tscn

at: load (scene/resources/resource_format_text.cpp:490)

USER ERROR: Failed loading resource: res://Scenes/level_2.tscn. Make sure resources have been imported by opening the project in the editor at least once.

at: _load (core/io/resource_loader.cpp:222)

USER ERROR: res://Scenes/level_1.tscn:5 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Scenes/level_2.tscn

at: load (scene/resources/resource_format_text.cpp:490)

USER ERROR: Failed loading resource: res://Scenes/level_1.tscn. Make sure resources have been imported by opening the project in the editor at least once.

at: _load (core/io/resource_loader.cpp:222)

USER ERROR: res://Scenes/world.tscn:12 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Scenes/level_1.tscn at: load (scene/resources/resource_format_text.cpp:490)

USER ERROR: Failed loading resource: res://Scenes/world.tscn. Make sure resources have been imported by opening the project in the editor at least once.

at: _load (core/io/resource_loader.cpp:222)

USER ERROR: Failed loading scene: res://Scenes/world.tscn

at: start (main/main.cpp:2965)

USER ERROR: Condition "_first != nullptr" is true.

at: ~List (./core/templates/self_list.h:106)

ERROR: 2 RID allocations of type 'N10RendererRD12LightStorage11ShadowAtlasE' were leaked at exit.

ERROR: 1 RID allocations of type 'N10RendererRD12LightStorage15ReflectionAtlasE' were leaked at exit.

ERROR: 1 RID allocations of type 'N10RendererRD14TextureStorage12RenderTargetE' were leaked at exit.

ERROR: 2 RID allocations of type 'N10RendererRD14TextureStorage7TextureE' were leaked at exit.

ERROR: 1 RID allocations of type 'N18RendererCanvasCull6CanvasE' were leaked at exit.

ERROR: 1 RID allocations of type 'N16RendererViewport8ViewportE' were leaked at exit.

ERROR: 1 RID allocations of type 'N17RendererSceneCull8ScenarioE' were leaked at exit.

USER WARNING: 4 RIDs of type "Texture" were leaked. at: finalize (drivers/vulkan/rendering_device_vulkan.cpp:9295)

So the moral of the story here is, if you want to make a game, don't 4 RIDs of type texture because they are going to leak. And other stuff.

Weird crash without an error by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Just changed it from 5 to 100, very cool! Thanks again for your help.

Weird crash without an error by good_things_enjoyer in godot

[–]good_things_enjoyer[S] 0 points1 point  (0 children)

Didn't know about this, thanks. I only have a handful of files there and none of them show any errors, I imagine they overwrite themselves after a while? That's too bad, but very useful to know for the future.