I love that you made everything PascalCase 
That’s how you recognize a programmer.
1 Like
And we must not forget the other big bosses - DirtBoy’s arch nemises WaterWoman (she washes him away) and PlantGirl’s antagonist SenorSunshine (she shrivels at his prolonged touch)
EpicSleeper, you’re the one who started pascal case with DirtBody. Although maybe technically I did, haha with ArmLeft etc.
MrMen, it’s a really good story, I’m kicking (scratching?) myself that I didn’t think of the Bugs and the Diggers. And by WaterWoman, you mean like Rain? Although it could be from a watering can or hose too.
I envisaged WaterWoman as one giant drop, but maybe she regenerated by raindrops, a dripping hose or watering can. Destroy those before you can eradicate her (or in the case of rain, get an umbrella up)
Yes, but like SeñorSun, WaterWoman is a double edged sword, although in a different way. She has the potential to be destructive and wash DirtBoy away but she’s also what gives life to PlantGirl. Without the contact of the watered PlantBoy, she cannot live.
And think how good it would look when DirtBoy has to leave PlantGirl: he slithers out through the drainage holes of her PlantPot home.
I added a few things and got it working correctly. If I interrupt the cycle it doesn’t do any craziness. The main thing I added from yesterday was the highlighted line.
Update. And I’ve now added a remove Reset tween to the StartSwitch is true event. Although there didn’t seem to be any problems without it.
Oh, and thank you MrMen for putting me on the right path.
Eventually there will be other things going on like changing the y movement up just a little bit rather than resetting it. This gif shows it sinking for 2 seconds. The actual duration though will be a variable ranging in time, much longer than 2 seconds. And yes that is a wooden doll that’s drowning but it all works out in the end. The reason why the gif shows a jump in the x direction between the start position and reset position is because the doll has a horizontal and vertical sine movement.
Mods, please don’t close this thread.
When I put much longer times in, like five minutes, it’s once again taking too long. Will see what I can discover from troubleshooting.
I didn’t like the idea of manually sending the player to y300 to stop the player rising up after the tween and turns out the player does stay put at the bottom of the y tween if it has no vertical component to its sine behavior. That’s fine with me.
The other thing is the timing. I just don’t get it. My simple version works perfectly. But my proper version works like this:
For a 3 minute tween from 300y to 175y, it should be at 217y after 1 minute, at 258y after 2 mins before arriving at 300y at 3 mins.
I timed it four or five times and these are the results.
From 175y to 217 y, it’s spot on a minute every time.
From 217y to 258 y, it was 1:06 to 1:10
From 258y to 300y, it was about 1:40 each time.
So the three minute tween takes about 3:50 to 4:00.
For two min tests, the first ‘lap’ would be perfectly one min and the second ‘lap’ would take about 1:15 to 1:17.
I’ve disabled everything and deleted things that were no longer relevant so that the proper version and the simple version would be as close as possible. They have the same behaviors, same horizontal sine movement, I even disabled the wave sine behavior in the proper version. I also made the tween y travel distance the same in the simple version.
I just don’t know what else to try.
Proper version:
I experimented with and without the highlighted parts as the simple version doesn’t have these.
Simple version:
I’m ready to concede defeat on this.
Things I tried: deleting the objects and putting them back again, re-doing behaviors, reducing the file size and dimensions of the body/parts (that did help for shorter times such as 3 mins but not for longer times such as 10 mins, (the original pics were way too big btw)) substituting simple block images, putting things on separate layers, other stuff I can’t remember.
I also expanded on my test game and put the proper pics in that. Nothng I did to to the proper game fixed the problem and nothing I did to the test game caused the problem. The wooden artist’s mannequin parts pics now are 20kb or less each and the biggest one is 110 x 442px.
So in a complete surrender, I just added the things from the proper game to the test game. No copy and paste, all hand done. Events related to other things, behaviors, scene variables, text boxes, sliders, backgrounds etc. And tested a 10 minute tween each time I added something significant. It kept working properly.
As one final search for sanity, I ran two more 10 minute tests on the proper version, the first took 16 mins 45 seconds and the second one 16 mins 12 seconds.
This story is finally over. The slow down came back in the newer version. I kept working on it anyway and adding things.
I wanted a countdown timer that ran the same time as the tween and noticed that it too was running slowly which meant it wasn’t a problem with the tween. The tween was taking the correct amount of time on the countdown timer but the timer was running slowly.
So the problem was with time itself. After getting some advice in another thread about the nature of GD time, I ran the debugger and found that the physics revolute joint that was joining each arm to the body was using up 99% of resources and meant that my game was slowing down time as it tried to cope with two tweened revolute physics joints. My laptop fan was also running like crazy.
I deleted the physics behaviours and positioned each arm with the action ‘put the object around another’. The connection between arms and body worked just as well, the fps was stable, no craziness in the debug profiler, the timer was accurate and it was all quiet on the fan front.
Here is the other thread where Silver-Streak and MrMen helped me.
https://forum.gdevelop.io/t/timers-are-affected-by-processor-speed/39097/8
1 Like