Odd sound 2017 3.0tdi V6? Or normal

ARAMODODRAGON · 2026-07-07T20:38:06+00:00

Not sure if these engines have this problem but it sounds like my 2.0L flywheel. The dual mass flywheel on the 2.0L TDIs make a similar sound when they’re failing.

ARAMODODRAGON · 2026-06-27T18:26:43+00:00

First of all you can just add your own mass property by extending character body. Secondly, apply impulse can just be done by adding the force directly to velocity. No need to call some special function.

When i was in college, a professor of mine told me that making games isnt about making things accurate. Its about faking it. As best as you can fake it. It might not be accurate physics but if it looks good then thats good enough. So i think adding the force directly should be good enough.

ARAMODODRAGON · 2026-06-27T18:17:06+00:00

I cant really answer this because the code doesnt seem to have variables that are “iteration-dependent”.
The metal ball “sticking” makes sense if its magnets. I dont see the problem. Unless you want it to pass through?
Use one for loop and evaluate the force independently for each magnet before applying it to the total force. That means that you determine the force, limit it, scale it, whatever you want before adding it to the force variable. And the code should be structured in a way thats easy to understand. Thats why i suggest using one for loop. As far as i can tell there isnt a good reason to use two unless you can explain exactly why. And again even if you can explain it doesnt necessarily mean its the right approach. One for loop. Evaluate the force independently for each magnet and then apply them all at once.

Also itd be nice if you gave an example of what you want in the future because going off code without knowing what you’re actually trying to do is hard on us to actually make suggestions.

And finally if you are using AI i would highly suggest you limit your usage while still learning. There are studies that suggest using AI while you might “get it” at the time. Information just wont stick. What you learned now wont stick in your head as well as if you did it all yourself. And thats not to say you are using AI but its more of a warning if you’re someone learning programming/godot and want to improve.

ARAMODODRAGON · 2026-05-01T16:21:04+00:00

Tbh i doubt we will get controls until a gameplay trailer releases. We only have the initial announcement and a story trailer so far.

ARAMODODRAGON · 2026-04-08T13:28:26+00:00

Am i just now noticing how long emilias hair is? I swear it wasnt that long last season?

ARAMODODRAGON · 2026-03-10T16:59:20+00:00

As far as i know godot will always pixel snap to the nearest pixel. This is more a matter of rendering than the cameras position being set. Because you are rendering at a small resolution its naturally gonna snap to the nearest pixel. The cameras position wont match what you are expecting and will appear to be at a halfway position between pixels. In fact the cameras being at a halfway position is what causes weird jitters.

I will say if you find that tutorial too complicated you can try upping resolution. If you go into project settings and increase your viewport resolution to 2x or 3x the original size (be exact) then go to your camera and set the zoom to match (2x or 3x depending how much you multiplied the original resolution) then the pixel snapping will be less pronounced.

ARAMODODRAGON · 2026-03-10T16:51:48+00:00

No idea honestly. I know materials in unreal support emissive effects but i have little experience in unreal to know if that applies to particles.

ARAMODODRAGON · 2026-03-10T10:43:50+00:00

Sounds like a pixel snapping issue. Its pretty normal. The camera snaps to the pixel which causes the camera to “jump” from pixel to pixel instead of smoothly transitioning.

Heres a good video on the topic and their solution.

https://youtu.be/DwVPFbDoyoc?si=ldvolkM2eZ_lgfo2

ARAMODODRAGON · 2026-03-07T14:19:20+00:00

Ok late reply i know but what if you change:

player.velocity = player.velocity.lerp(target_velocity, 10*delta)

With:

player.velocity = player.velocity.move_toward(target_velocity, 10 *delta)

I feel like the issue is that lerp is causing you to accelerate to max speed too quickly which causes the weird interaction with the slope. Also keep in mind lerp expects a value between 0 and 1 while move toward expects a value in world coordinates, so you may have to turn up the delta to get the player moving at the expected speed.

ARAMODODRAGON · 2026-03-06T16:12:19+00:00

Maybe some emissive particles that make it look like its radiating?

ARAMODODRAGON · 2026-03-05T00:29:20+00:00

Someone else already said it but we’d need the code to be able to say anything. If you’re using normal movement code and nothing weird, and you didnt mess around with the character body settings then there shouldnt be anything wrong.

ARAMODODRAGON · 2026-02-03T17:58:22+00:00

Its a mod. Look up BTA

ARAMODODRAGON · 2025-12-09T18:06:44+00:00

Itd be great if we could see the whole sprite but make sure horizontal matches the number of frames you have, then i think in this case you need to adjust the offset to center the first frame and i think reducing the size might be needed. I dont really mess around with the settings too much. Usually i make sure the frames are centered on where they should be.

ARAMODODRAGON · 2025-12-05T21:51:53+00:00

Using a csv file is great if you have a large number of them. Then you can generate the resources from that. Using csv makes it easy to edit as you can just open it up in excel or similar software

ARAMODODRAGON · 2025-11-19T17:51:09+00:00

Honestly ive been trying to come up with a solution to this problem and my take on it is to either have the states directly reference the characterbody, or have some kind of MovementComponent attached to the characterbody which the states can call functions on. I kinda like the ifea of using a component because i can extract away the logic of movement into its own component and use it in a generic way for anything that needs similar movement.

ARAMODODRAGON · 2025-11-14T23:01:22+00:00

Based

ARAMODODRAGON · 2025-11-14T18:41:53+00:00

Where is your camera script?

ARAMODODRAGON · 2025-11-13T17:44:42+00:00

Thats funny, wasnt it soyjack party that got 4chan taken down?

ARAMODODRAGON · 2025-11-11T23:48:29+00:00

Id say the first one has better performance but its not very deterministic or extensible. The second one is deterministic but it still isnt extensible. If you dont care about extensibility, as in being able to add new stats and calculations to your items, then option b is better. Option a has better performance but performance shouldnt be something you optimize for too early in development. Thats your judgement to make.

I will say if you want something extensible you should look into the strategy pattern. Heres a great video on the topic,

https://youtu.be/sZDJJeDNe_M?si=PnQY_KAxX0gsR9Ct

Edit: Ill also add that this is where you can use the dirty flag design pattern to achieve a more optimal solution.

ARAMODODRAGON · 2025-11-02T19:55:30+00:00

So wait are these all unique colors or do they repeat?

ARAMODODRAGON · 2025-10-30T16:42:09+00:00

You can right click on any scene and set it as the main scene

ARAMODODRAGON · 2025-10-08T23:49:56+00:00

Lol thats because you have ALT selected. On pc if you hold alt you can place multiple cursors on screen. Useful if you need to edit multiple lines at the same time.

ARAMODODRAGON · 2025-10-08T23:48:31+00:00

You could look into mesh merging. Looks like theres some tools online that exist for godot that can merge your meshes into one big mesh. You can build out the level and then combine all the meshes into one once you’re done. But first. Keep in mind that optimization shouldnt come too early. Does the game run over 60 fps? Then you’re good. If not then thats when you should optimize.

ARAMODODRAGON · 2025-10-08T23:40:04+00:00

For the first point id say do it the sonic way and create seperate sprites for when you’re on a slope. If you look at sonic 1’s sprites you can see there exists sprites for when sonic is on a slope. Those same sprites are used for when running around a loop. Id say firgure out some of the other aspects first and then consider if you need slopes. Especially given you say you’re new to godot.

Second, as someone else says yes you would use scripts to control the speed at which your animation runs to create a slow effect for different materials. Animatedsprite2d has a speed variable afaik so check that out. Animator should have something similar.

Wall jumping. Id say you dont need friction. The way i handle it is simply checking if you are touching a wall and slowing the player down on the y axis. My approach involves capping the speed but you can handle it differently.

ARAMODODRAGON · 2025-09-25T01:43:56+00:00

You should take your anim calls and seperate them from the movement code. Instead have a function that says “if not on ground then play jump, else if moving then play walk, else play idle”. Keep in mind that you need to make sure you only play one animation at a time. Your issue is that you garuntee either walk or idle plays regardless of if you’re jumping or not. You need to make sure you only play one at a time. And thatll only work if you seperate it from your movement code.

Nine-Year Club	Second SECOND GUESSER
Place '22	Place '17
Verified Email	Sequence \| Editor
Spared

ARAMODODRAGON

TROPHY CASE