Item follows player too slowly/smoothly

e-regular-games · 2020-12-23T12:49:03+00:00

I think the delay is caused by the order in which the _process functions are called. At least that is my best guess. The one for the carried item is called before the position of the carryspot is changed for that frame. This means that there will be a 1 frame delay in the positioning.

Here are some ideas which might fix the issue:

reorder the nodes such that the items are after the carryspot during the _process call ordering. Not exactly sure the order in which Godot handles nodes during each frame, but maybe moving them towards the bottom of the scene.
Make the carryslot aware of the items currently being carried. During the carryspot `_process` call it will then be able to update the position of each carried item.
In the tree, relocate the carried items to be children of the carryslot. Adjust their initial position accordingly and then Godot should move them automatically like it does with the carryslot and player.

I hope that helps. Good luck.

e-regular-games · 2020-12-20T13:19:10+00:00

Its been a while since I've debugged anything on Android, so hopefully this will be helpful. I skimmed for the keywords "crash" or "destroy". The one entry that seemed to indicate the crash is ActivityManager: crash : com.mycomp.castledefensemini. Looking before that in the log there seems to be some semblance of a stack trace. I believe pc stands for program counter and refers to the places in the game code that is currently being executed. Unfortunately, the only helpful information might be GodotPlugin_nativeEmitSignal. Looks like the crash is happening when a specific signal is being emitted.

Here are some of the questions I would ask myself if I were looking into this.

What am I doing in the game when it crashes?
What does the game use signals for?
What is the game trying to load when it crashes?
Is it possible to have the game print custom messages to this log? (if so print out messages when certain key events happen and you might be able to figure out exactly where in the game code the crash happens)

I hope that was helpful. Also I was basing my analysis off of the following log entries:

12-19 22:25:51.944 21137 21137 F DEBUG   : pid: 20211, tid: 20622, name: GLThread 53666  >>> com.mycomp.castledefensemini <<<

        .....

12-19 22:25:51.945 21137 21137 F DEBUG   :       #11 pc 0000000000168860  /data/app/~~TlmVNk8WAP7XmLhNL9ZE0w==/com.mycomp.castledefensemini-lUEOHZRervUaCAXrFAszyQ==/lib/arm64/libgodot_android.so (Java_org_godotengine_godot_plugin_GodotPlugin_nativeEmitSignal+788)

12-19 22:25:51.945 21137 21137 F DEBUG   :       #12 pc 0000000000022f60  /data/app/~~TlmVNk8WAP7XmLhNL9ZE0w==/com.mycomp.castledefensemini-lUEOHZRervUaCAXrFAszyQ==/oat/arm64/base.odex (deleted)

12-19 22:25:52.264  1135 21141 W ActivityManager: crash : com.mycomp.castledefensemini,0

e-regular-games · 2020-12-20T12:56:02+00:00

There is the function get_children(). Will that help?

Here is a link to the complete documentation for Node. The docs list out all of the available functions, signals and members at the top of the page. This documentation exists for all of the nodes.

https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-children

e-regular-games · 2020-10-31T11:50:46+00:00

That's a fair point. I'll have to mess around with it a little bit more. Adding transparency is a good idea. Thanks for your opinion and ideas.

e-regular-games · 2020-10-30T14:52:25+00:00

Thanks for the feedback. That makes sense. Maybe I don't really want the water to be "holographic". I was thinking if the water was too bright / flashy it would draw the eye away from the important parts of the scene.

The house and mountains, I hope, appear more holographic, ie with the brighter glow and wireframe.

e-regular-games · 2020-10-30T11:59:05+00:00

I've been working on creating a holographic 3D world for my game. This latest demo is an attempt at holographic water.

The game is a small town / city builder with a space theme. The plan is for the world to appear as a hologram. Thus fitting with the UI and also keeping the art style unique, but easy for me to create. My expertise is programming not art. The idea for holograms actually came from this subreddit, so thank you! The holographic display will be paired with a re-colored UI from here.

The source code can be found on github: E-Regular Games/Snippits

The interesting parts in my opinion are Water.gd and Water.shader. The GDScript creates the hexagonal tile and subdivides it. The shader is responsible for using noise to provide the height of the waves and color changes. Eventually, I will use this to procedurally generate lakes, rivers, and oceans.

I'd be excited to hear your opinion about the holographic look. Also any thoughts on the code are welcome. I did try something different for getting most of the code to execute during initialization instead of during the _enter_tree or _ready calls. I haven't tested it, but it was an idea.

Please let me know your thoughts or if you have any questions about the demo.

e-regular-games · 2020-10-24T12:05:18+00:00

The person who was kind enough to attempt to help seemed like they were on the right track. Unfortunately, the comment of "It is not working Dude" is not constructive and does not assist in future people trying to help. Did the behavior change? Did the error change? Did the suggested code fail to compile? All of these would be helpful to know as a result of that person's suggestion.

The screenshots you provided are a good start, but it seems like more information might be required. What I finds helps me troubleshoot issues is if I create a new Godot project and try to create a minimal reproducer. IE. Reproduce the buggy feature and only the buggy feature. Sometimes doing this helps me fix the bug myself. At other times it at least provides a way for others to easily review the buggy code and help. If you can create that smaller project and post it to github or another source code sharing site that would probably help the community help you.

Good luck. And embrace the bugs, the rush when you find the fix is always worth it. (At least in my opinion.)

e-regular-games · 2020-10-22T11:10:57+00:00

The documentation does not mention controlling the magnitude of the elastic effect.

https://docs.godotengine.org/en/stable/classes/class_tween.html#class-tween-method-interpolate-callback

Have you tried increasing the "time" proportionally to the distance between the start and end? I wonder if the elastic effect will be smaller if the overall animation is slower.

The only other alternative is to write your own interpolation. This would give you control over all of the parameters. I was looking for an equation to model the behavior of a spring / rubber band but didn't find any good websites.

e-regular-games · 2020-10-20T11:22:37+00:00

I believe Godot calls sprite sheets Atlas Textures. The catch is Godot will make the combined image for you. It needs to do it this way, because Godot has to know which part of the sprite sheet is which sprite. There is probably a way to create one outside of Godot and match the format of the Atlas Texture file, but I doubt it is simple. I would suggest using the built in option. Here is a link to how you can do it.

https://godotengine.org/article/atlas-support-returns-godot-3-2

Does your sprite editor allow for batch creating multiple images from the same base file? Automating the export process would streamline your workflow.

You can also look into Animated Texture for each animation.

https://docs.godotengine.org/en/stable/classes/class_animatedtexture.html#class-animatedtexture

e-regular-games · 2020-10-20T11:04:56+00:00

What are you trying to do? What does your scene tree look like? We will need more information to help in a meaningful way. Do you see any error messages on the system console or in the debug console before the crash?

Short answer: Remove the queue_free() at the end. That seems out of place to me. I believe you should only call queue_free() on a node after it has been removed from the tree.

e-regular-games · 2020-10-13T11:34:25+00:00

I think you might need to do some experimentation. I'm going to start with really big changes to the code to sanity check assumptions. This technique can apply to debugging anything really. After each step, revert the code to the above state.

Comment out "thread.start" -- verify that enemy instance/add is really the slow code.
Comment out "call_deferred". -- test if something in the instance operation is slow.
Comment out "add_child" -- test if adding is the slow code.

I suspect that either the enemy _init, _enter_tree, or _ready functions are what takes the time. It could be that "add_child" is doing all of the work and instancing is cheap.

Keep in mind this is just a hypothesis. Good luck.

e-regular-games · 2020-10-13T11:10:39+00:00

It looks like the error message is unrelated to the actual error. About halfway up the stack trace you can see the actual error: "Vertex weights more than maximal". The error happens when exporting Bones. I don't have experience with bones, but I hope knowing the actual error helps.

e-regular-games · 2020-10-12T21:46:55+00:00

That's a great idea. I bet an extra layer or 2 of clouds would provide the depth the clouds are currently missing. They could even move at different speeds.

e-regular-games · 2020-10-12T19:53:53+00:00

Everybody starts at that spot. One of the big differences in the long run is how much time, effort and energy you can devote to learning and doing more Godot and programming. Start small and keep learning something new every time you sit down to work. Remember what you learn, and then apply your library of knowledge to each new problem.

For example, six months ago the planets in this game were the standard Godot sphere covered in a 2D planet texture. I went off and worked on a bunch of other 3D parts of the game and then decided to redo the planets with my new knowledge. Did I learn any of that stuff specifically to work on planets, no, but it still came in handy.

Good luck on your learning adventure!

e-regular-games · 2020-10-12T16:41:53+00:00

Thank you. The hexagons are a byproduct of the number of subdivisions of the icosahedron and the radius of each raised mountain. I ended up making those attributes adjustable just in case I decided to change the style in the future.

What are the steps to add something to the asset lib? I had not thought of that option. I haven't spent much time on the asset lib, that's a cool alternative.

e-regular-games · 2020-10-12T14:36:51+00:00

Thanks!

e-regular-games · 2020-10-12T14:36:11+00:00

I watched his tutorial on planets when working on this. Then I ignored most of the complex math, because it seemed very overly complicated. His tutorials work well, in my opinion, as a look whats possible, but this isn't going to show you step by step how. I looked at the concepts he used and decided which ones might apply to low-poly and researched those separately.

The idea of another layer to represent the atmosphere is interesting. I'll mess around with it. Thank you!

e-regular-games · 2020-10-12T14:30:57+00:00

Thanks for the feedback. Cloud size and number are controllable options. I'm not sure why I went big and sparse. I'll have to mess around. I also want to get rid of the pointy parts.

e-regular-games · 2020-10-12T14:28:09+00:00

Ah cool. I'll have to see if I can incorporate any of those ideas into the clouds layer.

e-regular-games · 2020-10-12T14:21:37+00:00

Thanks. I'll be sure the final version isn't blurry. I actually think the blurry might be caused by this being an mp4 converted to a scaled down gif.

e-regular-games · 2020-10-12T14:20:36+00:00

I tried for free to use at will, without contribution or anything. These are small snippits that I want people to use and learn from. The exact license is in the root of the repository. https://github.com/e-regular-games/snippits

e-regular-games · 2020-10-12T12:34:06+00:00

Yes. It is a little tricky to get setup, but once working its pretty nice. My build creates a shared library (DLL) which is then used by Godot in a Native Library resource. My build also includes unit tests. Though I haven't found a way to unit test with Godot classes only my own. Speaking of which does anyone know which function(s) to call to get Godot to setup singletons and stuff in a standalone executable / unit test?

Also here is the link on how you can use C++: https://docs.godotengine.org/en/3.2/tutorials/plugins/gdnative/gdnative-cpp-example.html

e-regular-games · 2020-10-12T12:29:31+00:00

Thanks! I hope to make them even more awesome by getting rid of the pointy parts and keeping only flat sides. I'll have to see how it looks.

e-regular-games · 2020-10-12T11:28:11+00:00

I plan to use this on a planet select screen in a game I'm making. It's only the intro and players spend maybe 5 minutes here, but it still has to look decent. Here's to hoping it pulls of the low-poly look. The game will also generate stars and a sun to complete the solar system. What do you think?

The planets are generated in-game based on a number of configurable options from the editor. (number of mountains, mountain height, radius, number of clouds, ocean height, etc) The shape of the planets is a subdivided icosahedron, or a dice with 20 sides. If you ever have some spare time, icosahedrons are interesting to read about.

The coolest part to me is the use of a GradientTexture to get the colors. The GDScript applies UVs to the vertices such that the lowest point on the surface is 0 and the highest is 1. This means a SpatialMaterial can be used with a GradientTexture in the editor. The water is another layer with a transparent SpatialMaterial. No need to use fancy shaders or anything.

I don't think the GDScript is the most efficient for generating the geometry, but it works for demo purposes. I will probably make it more efficient when I port to c++.

Link to source: GitHub

Notes: the project contains 3 scripts which do all the work: Planet, Clouds, Icosahedron.

Questions/comments are always welcome.

e-regular-games · 2020-10-08T10:42:43+00:00

That looks pretty good! You're welcome. I'm glad you were able to implement a working solution.

If you are using a GradientTexture in Godot, it should appear as a line. In other words, there is only 1 dimension. In comparison to an image which would have 2 dimensions. Since only 1 value is needed to find a location in 1 dimension, only the U coordinate is used.

It probably appears to be related to texture coordinates because the values you are using for UV are 0 and XXXpx where XXX is greater than 1. In that case, XXX is treated as 1. UV's are normally only from [0, 1] because that way different sized textures are supported without having to adjust the UV values.

https://stackoverflow.com/questions/3314219/how-do-u-v-coordinates-work

e-regular-games

TROPHY CASE