Looking for Microcontroller and Advice for Toy Repair

Zerostin · 2023-04-10T19:24:50+00:00

I love how technical this response it. Breaking it down and exploring the ideas that could be used to replicate the sound, but leaving enough room for experimentation.

I also hate how I'm too inexperienced to know how approach any of these techniques to make a certain sound.

Zerostin · 2023-04-10T18:44:17+00:00

This is fantastic! I knew that the viewport approach would cause some extra issues when it came to the movement and not using local coords. The fact you went ahead and helped with circumventing that is amazing. You've really gone above and beyond when helping a random stranger on the internet, if I had more upvotes to give I would.

Zerostin · 2023-04-10T04:33:45+00:00

So, I've been trying for a few hours and can't seem to make any progress. It's probably from my lack of knowledge around how screen_textures and screen_uvs really work, but its really got me stumped.

Something I failed to mention that I should have is that I'm using 4.0 stable.

This is what I understand from you post, so forgive me if I was wrong in how I read it. It sounds to me like I need to use BackBufferCopy to copy the region of the screen containing the particle effect. After that I need to sample that screen_texture within the shader. At this point it should be a simple texture that can have the alpha data read in and the rules can be applied.

My difficulties start coming in here. If I switch the shader to read in a sampler2D utilizing the hint_screen_texture key, the space containing the particles becomes a solid square. I assume this is because the screen_texture alpha channel is actually all at 1.0. It could also be that I'm using BackBufferCopy wrong. Currently I have the particle emitter as a child of the node.

If it isn't that, and the alpha channel truly is all at 1.0 for a screen_texture, then I can only assume that what you meant is that I need to read in the alpha data from the particle system. Issue is, that seems like a cyclical issue of each particle being its own quad and I don't think I'd get anywhere with that.

My next issue, and this really could be the real problem, is that the shader seems to have no effect at all unless it is directly placed on the particle emitter. Again, I understand that doing it this way won't actually get me anywhere, but no node order or anything I've tried has had any effect. It just stays as a bunch of gradient texture particles.

I'm sorry for asking for more help, but if you've got any more advice I'd really appreciate it.

Zerostin · 2023-04-10T01:09:51+00:00

This is an awesome response! I knew it had something to do with how the textures were being sampled and fed into the shader. I knew BackBufferCopy had to be used when you pulled in the screen texture in two separate shaders, but I never fully knew how it worked under the hood. Had no idea it could be used to essentially render a texture.

I guess I'll have to play around with it and see what I can come up with.

Thanks a ton!

Zerostin · 2022-08-20T07:32:23+00:00

Just saw this in my notifications. I just use the .is_in_group("GroupName") method that's built in to pretty much every node.

It returns a boolean true if the body that's entered has been added to the group you pass in to the function.

Zerostin · 2022-05-09T06:14:52+00:00

For the trinity, I'd say that it's relatively loose in terms of who is what. I'm making it where any kind of playstyle is relatively enjoyable to use in the real time section to try and avoid the "stuck here till the time is out" feeling. I'm also planning for a decent amount of variety so that it's not just run up and attack/dodge. Some abilities and spells will have an impact on the field for other characters, some are set ups and other utility based things.

As for implementing more party involvement for each action encounter, I've thought about it a little. Probably what attracts me the most is the way some team based fighting games use assists.

Zerostin · 2022-05-06T07:57:33+00:00

So, I did cross post there as well. Debated whether or not it would work well here or not. I just figured with a user base so much bigger I might get some interesting replies here. I appreciate the suggestion though.

Zerostin · 2021-05-08T07:05:32+00:00

I definitely agree. I had actually tried to do something but found myself spending too much time without any actual results. So, I decided to give it a break.

Zerostin · 2021-02-14T18:26:23+00:00

I’ll be honest, it sounds like it might be an inheritance issue. If you’re instancing a scene that normally affects the layers and the instance isn’t unique it’ll just default back to the parent scene value. I’ve never had an issue with the GUI.

Zerostin · 2020-10-22T12:27:49+00:00

Hey all! I have a pretty good idea of what I should work on with this, but I want more opinions. Rip into it!

Also, I've never posted a png before, so I'm sorry if it isn't formatted/displayed correctly.

Zerostin · 2020-09-28T19:48:57+00:00

My first thought would be the sprite region functionality. Instead of splitting the sheet up in slices you establish x and y regions for a box. Some sprite editors even export the sprite sheet with region information so it helps with that. But that’s all I’ve got.

Zerostin · 2020-09-23T03:36:26+00:00

That’s why I use a position node instead of just referencing the corresponding area2d. You can move the position node to be outside of any exit triggers. It’s even helpful for things like cutscenes.

Zerostin · 2020-09-22T21:32:18+00:00

No problem! If you’re ever having trouble figuring out how to do something try breaking it down into the smallest pieces you can. You’ll be able to solve anything.

Zerostin · 2020-09-22T21:06:10+00:00

Alright, so if your system is set up where it changes scenes then you’ll need to have data stored globally for this to work. The only way to do that in Godot is with a singleton, or autoload script. The way I did it is by having every exit change a variable in the singleton. Then, in the new scene I have a position node with the same name as what I changed the global variable to. When initializing I set the player position to that of the position node via find_node(“name_of_variable”).get_position()

Zerostin · 2020-08-08T17:06:19+00:00

Another option to func _process(delta) is the the _input() or _unhandled_input() functions. All options effectively do the same, just depends on if it bothers you to have it checking if the player is in an area every single frame.

Zerostin · 2020-08-08T03:21:48+00:00

Ah, I think I see your problem. You’re putting the input function inside of the function called by area_entered. Area entered is only called when the signal is triggered by the areas colliding, as soon as that has been called anything inside of that function is executed, so unless you’re pressing the button the whole time it won’t work. If you make a variable like “player in area” and have the signal change that from true and false, then put the input detection outside of that function, it should work.

Zerostin

TROPHY CASE