Do you guys like “being dragged through the mud”? That is where I create issues to show you how to solve them, rather than providing a sterile learning journey?
I really appreciate this approach!
Learning is all about making errors. The best skills are the ones who help you to fix your bugs.
Opening the TankPlayerController Blueprint crashed my engine. Thanks to the lesson about attaching a debugger to the process, I was able to find the nullptr while using GetPawn. Fixed, everything works!
Next lesson: you explain exactly this crash and I was thinking: “Hey cool, I fixed it myself already. Thanks for teaching me to help myself, Ben!”
You’re welcome, well done being such a great student
I think it’s really important to learn, especially since, just because the code compiles, doesn’t mean it will work . They only thing I wish you would change is to warn us when you are purposely creating a bug. Several times I stopped a video because I noticed the problem, and spent hours trying to fix the problem, then I give up and keep going on the video and you fix the problem sometimes in the same video and if not the same video the next video. In fact you did an entire video on my last major bug when the tank was shaking all over the place and shooting off sometimes into the air. I spent a few days trying to fix it before i gave up.
And sometimes I am yelling at the screen: “whhhhyyyy? don’t you see?” ^^;
@Ben All of the above.
In addition you may remember me stating on some occasions about playing with mud code. If i was being taught in a sterile enviroment i would still look at those types of errors, (If you have seen mud code after 10 different coders went though it you would get an idea :D). The method of being taught the messing dirty way and then cleaning up and doing it the correct way is the best way to learn as it shows how you got into that state (or a previous coder did) and how to fix it as well.
Its also fantastic method for us visual learners as well to see the errors by going the wrong way we can recognise them when we encounter our own ones too!
I’d prefer not to have the warnings of deliberate bug creation, If i missed it then i didnt learn enough yet, If i caught it then yay i probably learnt the right amount or more. The learning is in the journey and that includes the wrong roads too!
Yes, it’s been great learning how to resolve issues… but maybe more warning next time you start one of these adventures, because that was a rough rough challenge for me.
“I can get it to compile, but it BROKE EVERYTHING! WHAAAAAAAAA.”
spends the next couple of hours trying to figure out what went wrong.
eventually gives up (not before actually identifying many of the issues that are brought up in later lectures) and goes back to the video - watches Ben break everything in exactly the same way.
‘oh… he meant to do that.’
Which lecture is this so I can add a public health warning.
Can’t remember the exact lecture number, but it was the one where you challenged us to add the tank aiming component as a blueprint spawnable item, similar to the movement class.
i.e. the one that kicked off the great refactoring of the architecture of the entire project. I was happily playing around with the firing code and lost that functionality for the better part of a couple days