Slime Detail UI, Or not.

Today I am going to be working on the rest of the slime detail UI, hopefully I will finish it so I can start tweaking and tuning the care numbers.

Or not, looks like I spent the day fixing bugs, mostly.

As I recall I got the initial window for care set up and then had a bug with the detail sprite display claiming files did not exist even though they very clearly were right they should have been, even copying the path given by the error and pasting it into my file browser led me right to the file supposedly not there.

It isn't to do with the order things are downloaded and displayed, the image should not even be getting loaded unless we got a 200 response along with the image itself in the download. I honestly have no idea where to begin with debugging this one, I will have to try some experimentation I guess.

The strangest part is this same exact code is working for loading the sprites into the world. The only difference is they are pulling from the Detail sprite download and storing the files in the Detail folder. Both of which I have checked multiple times to ensure I am reading things correctly. I do know the part that throws the error seems to be the rear body sprite so that's where I will focus my attention.

The hands for the detail sprite need to be placed properly, just a matter of changed a couple values in calculations. The issue with the body part sprites not being found has not presented itself yet so I may have a bug with some strange conditions I need to keep an eye out for.

There is another bug of course, regarding the client side scrip loading. I think I may have either overwritten the client side script for the face here or the particle emitter is not being attached for some reason. I will look at the remote and see.

Yeah, looks like the particle emitter is not being attached and we're getting a none value as the script. Interesting. Perhaps I changed the script or how it loads... somehow? I don't recall working in that area of the code at all but maybe I had something highlighted and a key was pressed accidentally? Who knows.

As it turns out the script has been overwritten somehow. Maybe I was tired and uploaded the template script to overwrite it? Let's see what happens when I upload the proper script.

So the emitter loading from the top-left has been a bit of a headache from the start, I should have predicted this problem. Now I need to re-align the emitter for the detail sprite. It should be loading at sprite height and width divided by 2.

Okay, now, why does it seem to be loading the emitter in the center here?

It should be centered based on the math I had for getting it centered on the world sprite, but looking at the world sprite's emitter in the remote it says it's at 0,0 while the actual scene has it placed at -16.-16. Peculiar.

If I just set the position to 0,0 will it load fine for both? Probably not.

Let's restart the client and reload the slimes...

God dammit why does it keep rescaling the detail view? I have all the scaling set to 1x.

Alright, it seems that the emitter is now starting from the center position. Huh. Did they change that in the last update?

I don't see anything about it... strange. Well, setting the position to 0,0 seems to be fine... for now?

I can't find anywhere in the code or in the scene inspector where the scale is being set to 2 on the detail sprite. It's very strange. Lots of strange bugs I can't account for the past couple days.

Ooookay then, the bug seems to be in Godot, it seems. I have the scaling set to 1 on the thing being instanced here

And I have set it to 1 here as well, then saving it, closing it and reopening it I find it set back to 2.

The scale is set to 1 in the scene being instanced here but it thinks it is 2.

Yeah, same thing happens on the referenced scene. The game isn't running or anything so it's not that. There's no code to change the scale in the scripts.... maybe I will try restarting Godot?

Nope. Well, shit.

Okay, thinking about what could cause this... there are 2 things that come to mind.

One is permissions, I don't think it's a permissions issue. That could cause the file to not be saved on disk and reset back to the previous state.

The other which also is a stretch is that the original scene that I copied this scene from was scaled 2X so I can see the slimes better while I am working on things and for some reason this is inheriting the scene properties from the original.

Well, I tried setting the scaling in the original to 1x and closing and reopening it, no dice. It reset to 2x. This does in fact appear to be a bug in Godot.

Well, I am stumped.

I can not effectively change the scale of either of these 2 things from the scene properties. Changing them at runtime would be more work the client has to do on start up and would be dumb. There must be something I am overlooking causing the scale to be changed back.

It's stuck as 2,2 in the file. I will try and change it externally, here.

Yep, Godot is setting it back. I will close Godot and try again.

Well, it looked like it worked. Started it back up, opened the compositor and it said 1,1. Started the client and BAMF

Hmmmmm...

Well, this wasn't the plan today. Welcome to game development.

So, what can cause properties to revert in Godot? My searches turn up nothing. Hmm...

It's the editor doing it, not some permissions issue with the file or anything like that. Somewhere in the editor it is deciding that the scale must be 2x. Even if I change it completely in the files while Godot is not running it will be set back. It has to be getting that scale from somewhere but I have no idea where.

The detail and the world sprite compositor are completely different scenes with completely different scripts.

Oh boy, it would appear it's all the properties, not just the scale. This bodes not at all well.

It is only the compositor scenes having this problem. I don't think an instance of a scene being modified can change the base scene for any reason in the editor. I don't think there's any issues with permissions as I was able to write to the files fine outside of Godot with the same userspace that Godot is running in.

Nothing is locked...

Now, I have spent about an hour working on trying to fix this scaling issue. I can not track it down to anything, I can not find any reference to it anywhere on the internet, I can not figure out what in Godot is causing this at all. I know that the editor is doing it but not where in it the problem is happening.

I could set about debugging Godot itself, but that would take all day. I suppose I should just make an issue to solve this later if I can't sort it by lunch and set the scale at runtime for now.

I am going to try closing all instances of Godot and setting the scale externally once more.

Wait. No.

I know now.

I think.

It's the animation player.

The animation player messes with the scale for the squash and stretch animation. Why didn't I think of it sooner?

No bug in Godot, just the damn animation player node running frame one of it's animation even when it is set to disabled. Dammit.

I know why the client script wasn't loading correctly. The server script was overwriting it. Man, just really batting 1000 lately. Really need all this stressful stuff to be over so I can focus properly on working on this game and stop making stupid mistakes.

Welp, over to the API's slime model to rewrite how the object store handles the scripts.

Just gotta change these server paths to reflect they are server scripts and re-upload the scripts and that should fix that problem at least.

Now the slimes are not spawning in the apartment. It's one of THOSE days.

The thick plottens.

I deleted the wrong animator. Fixed it.

Felt weird all morning, now it's after lunch and I feel a little better. I suppose now that I sorted all that out I can move on to the UI.

Fixed several more bugs on my way to the UI. Mostly having to do with loading the city as parallax layers. It's going to be more static now but that's fine I think. Not that high up really.

I need to display the slime's illness information since that's the next tab on the UI, if a slime is ill, we should pull the illness data from the API via the slime itself if possible.

Been feeling off all day, now I am exhausted. Could be the weather.

Going to look into nesting the illness into the slime data.

The client side will get this data. I may also nest all important data in the slimes themselves where appropriate.

For now though, I should get the illness when the slime is loaded.

So there we go, actual progress on today's goal.

I am starting to feel a little better now, though it is about 3pm. It seems from noon to 3 the last several days I feel like crap. That happened last year around this time too, in fact it seems to be from around the middle of fall until the middle of spring where I have this afternoon lethargy. I think it still may be somewhat related to what I eat.

Anyway, the illness tab is working fine. I just need to reload the client to pull the slime data and show me the one sick slime's data. I will also need to make a few sprites to show sickness or health here instead of the Godot logo.

Of course, I should probably set the slime to be sick while the server doesn't have it loaded. Good job brain. Really just on a roll today.

Of course the slime data the UI is working with is not the client data from the slime, it is the data sent from the server. I would need the client data as that is the endpoint with information regarding the illness, not just the ID.

Or I could use a local cache of the slime DB which might be smarter in the long run.

So to that end I should probably just get on to the database versioning system overhaul. Both for the client and server side to load data quicker and hit the endpoints for data less often.

Nothing is ever straight-forward.

I think it's going to be a couple half-days for today and tomorrow, maybe a longer period. I seem to be sick and there's a lot going on regarding the move and whether or not it is happening.

I'll start on the DB versioning system overhaul tomorrow.