Magic of Words And Color

And so it should have links to tags I used to sort through my posts. -Feature posts: #fp. -#photography. -#my art. -#writing. -#screenshot. Also here is the random link if none exists Random post

Others: Prepare their kill bases. Me: Get on my bike and drive to a random large structure to have a party in.

So this year I actually decided to harvest one of the plant experiments. It the second year I dedicated planting in these large pots outside. My previous experiment usually got murder no matter how well mark the area was. Now days I should be able to plant them on the surface since there not going to be anyone killing them anymore, but it really wet here so I'll stick to the pots for the plants that like well drain soil. So the harvest was a bunch of tiny potatoes and a few small ones for now. there still 5 potatoes still alive and one of them have a large one. I hid the tiny ones in the soil and move the small ones in the house for storage. The small ones I may try eating when there enough, but I also plan to replant them in the fall if the tiny ones disappear or fail to grow. One pot I just planted beans to try to grow in the summer. I need to try to check on it more often since it gets hot here and I may need to water it once or twice a week depending on how fast the soil dries out. I did grow beans before, but they were hidden a bit in the wood to protect them, but this means the pods only had one bean in it. These should do better as long as they do not get eaten or dug up before rooting. Depending on what happens will determine if I will spend more time pre-sprouting them inside. Truth is I have a few old bags of pinto beans that just is hard to cook well. It may be better to grow and then eat without drying. It will depend on how much work it will be to grow them.

I may end up feeling extra lonely since idk when I be able to talk to my favorite friend casually again. Being odd and old, meeting new people is difficult and stressful for me. I do have other friends, but it sometimes a chore to do thing with them and most of our similarities are gaming (I dislike having to play team-oriented games since I may have to drop out randomly to deal with life). Not sure if it will hurt my focus, but most likely will hurt my mood. Idk I say nonsense too much.

Part of me wants to mess with JS again. Build a basic framework for holding objects related to rendering and position. Ideally using the concepts I been enjoying to keep it isolated and simple. Probably a lot out there, but my own would follow my rules so no need to learn and hack someone else code. It should be pretty small. A scene that has scene objects and probably a few object that can be use to communicate to other systems (such as a scene event object). The scene object probably with have an object for rendering and maybe physics (not sure if that be over-scope) or maybe not if JS have some way to fake an interface. The most work is deciding and designing the scene to find and sort the objects in ways that make look up easier. I also would need to think what the base scene should include. things like chunking could be extended to it if I handle the logic flow correctly. Also I may need to refresh my memory on JS memory management. If I can, I would rather have a weak ref sent of the scene objects outside of the scene (unless requested) if there no way to destroy the object in such cases of misuse. Mostly overthinking at this point. It really should be short and simple for the bases and allow extension into a somewhat complex system. My pyscript fishing game test project kind of did this, but was a little dependent on the scene for directly modifying the DOM. I kind of want to abstract that so it could be used with other systems (even though I doubt I would be using JS outside of html base systems. I still could rebuild the design in other system if I ever feel like working with it). I am just a lazy cat and I can't really focus on anything more complex lately meow. I might not even do it and work on my main project when I am more focus.

Part of me would like to mess around with js again to make web base games and app, yet js kind of annoy me. I just like how most things made with js/html can be view on many modern platforms without a dedicated backend. I do admit having a server would allow more options without depending heavily on js. I did mess around a little with pyscript, but it felt like a bloaty way of making front end apps in python. Though when I feel better and more focus/free I should try to focus on my main project.

Just a random screenshot drop from random No Man Sky adventures.

Maybe oneday I will try to make a text front that uses an eight pointed star with each fill in point represnting a bit. Yeah I am being silly.

In Godot, there are serveral ways to communicate between nodes. Using an autoload as a handler for that data, using a resource tres file, and using groups are some of the ways. I tend to start out with a few autoloads for major roles such as GUI, fileacess(for saving/loading), and maybe some management. Truth is I've been using autoload less since I learn I can use resources in a similar way. I use a autoload to handle the GUI so I do not have to depend on one major scene to handle loading and unloading nodes of various types. The GUI handles control nodes for most menus and huds, while the main scene handles the games primary scene type(like scene 2d or scene 3d). Since it is an autoload, anything can access it. Lets say I want a basic dialog system. The GUI autoload exposes the dialog node on ready and anything that wants dialog display call the appropriate function to set the desired settings and trigger the dialog. Then the dialog will run until the end conditions are met. Now with Godot's resources, we can do something similar without needing the GUI as an autoload. We can create a dialog state resource that provided signals to notify both the dialog and the triggering node of changes. The resource should have a tres for itself and both the dialog node and triggering nodes should use that file when referencing the dialog state. It may be the better option, but one needs to make sure the dialog node loads and connects to it on ready before any of the dialog stuff is run. Note: a regular resource could be used and the data is added to the metadata, but this requires both the dialog and trigger to check the state often due to not having signals. This is for cases where one does not want to depend on the dialog state class. Then there are groups. It kind of like the autoload way, but it assumes there is a GUI in the GUI group that haves the functions it calls with the correct parameters. It does not require any hard dependencies, but it is harder to debug if something goes wrong.

Interfaces and inheriances are used to communicate. Any data that needs to be shared across systems use an object as a shared state. The main logic regulates this if needed and most of the variables would be fetched and set via functions. A (possibly bad) example would be a program where there is a GUI and UI(input) systems. They share an input state (in this case, UI handles it, but the main logic assigns it to the GUI to read) which stores what keys are pressed, was last pressed, and how long they have been pressed(as well as other things). The GUI display this as debug data on the screen either by getting the values from the input state each update or using a listening like logic(callback?) to update when a value in the state changes (note, but the handler and readers listen to the state. The state should not know about who uses it). This input state can be shared with other systems, but the signature either needs to be universally agreed on or unique per system and handled via interfaces. Truth is I assume software engineers may disagree on this approach and prefer more abstraction and independencies, but I find this way to be easy to read and navigate for solo dev. It is also simple enough that I would not need a map to navigate it since the main logic should be straightforward. Then all there is left to worry about is the content and adapters for any api.

I ended up living her because I was able to generate fuel to trade for stardust. Gold, silver, oil, fish, snow in the distance, and plenty of foliage made me get use to this place lol.

Some random screenshots from my adventure

yeah more of the fortress house in different places.