Does this cycle make sense to you? What do you understand by it?
Red = broken / assert test failing / project not compiling
Green = have something running / working somehow before starting to refactor
Blue = refactoring phase
In UnitTest coding I just know red/green, where āblueā would be the next red test before the refactoring iteration is finished 
I actually understand less after trying to set this up due to confusion from a slew of problems it caused trying to add the tank aiming compnent back in as a non-inherited object which caused crashing for me in prior lectures. Now it doesnt cause crashing when its grabbed on begin play for some reason (it used to crash no matter what), however the tank controller fails to find an aiming component reference to draw a crosshair with, since the controllerās begin play is called before the tankās, negating the function that tells it to report it has a aiming component, and the function is never called thus never creating the widget that can draw the crosshair. And when I try to grab the aiming component for the tank it itās constructor, unreal crashes with no dialogue box, Iām guessing because its trying to grab a component that hasnt been created yet. But i cant attach the debugger to ue4 because it always gets stuck at loading symbols.
I also was thinking the architecture seemed a little strange or sloppy in early videos, but refactoring it now is just causing a mess. Weāve gone from spaghetti to fried rice.
Also doesnāt making the aiming component not inherited add a level of dependence that isnāt needed? Since we donāt plan on having differnt aiming components especailly being this is for an example game where the our āaimingā class is always the same
omg i just put my code back to normal and the crosshair isnt being draw wtf?
great it turns out my prior commit doesnt have a crosshair either wtf happenedā¦
The only thing I changed I just realized was the movement component ben had me think I could remove but when i put it back in my program crashes despite never referencing the movement component that worked fine before. Oh it didnt crash this time but still not working what a mess. I knew this would happen i called it out many lectures back. Nice visual studio is frozen now for the win. and my computer is overheated
shop vacs and fans later, I discovered when I use the regular method in blueprints of fetching the tank aiming component in blueprints it works, but the blueprint implemented event does not fetch the aiming controller accordingly, even tho they do a near identical thing. Im 90 percent sure it was working before though which is strange.
^version that works
^and here you can see the blueprint implementable event doing the near same thing its begin play does
I guess I will have to continue on using this method while trying not to change the way aiming component is referenced to save my precious brain cells and hair on my head for learning more important things
Omg i dont belive it. No wonder my last commit didnt work. The very last thing i must have did was added an āensureā tag to the aiming component check. Somehow i missed that i wrote the opposite logic, and wrote a ā!ā.
All this confusion and stress over a fk*ing excamation point! can u believe it? i wasnt used to that ensure tag so somehow this whole time i didnt see it.
Well actually, the crashes I was getting are still kinda wierd, Iām a little afraid to edit it now.
Brace yourself @Steve1222, small missing character like a ! in your code (well at least mine) are easy to miss. Youāll learn with experience to figure out mishap you do coding faster.
1 Like
yes well i mean i saw the ensure but somehow i didnāt acknowledge that it was interfering with the call to the blueprint implimentable event, probably since I added it randomly. I had been sorting through so many other problems and I thought something else was wrong and it kept getting messier.
I would hope that i would get better with experience but for how it seems like problems with every other video. Its a shame how easy it is to become incongruent with something as simple as a learning tutorial. Theres alot of chinks in the unreal engine that can be unaccounted for. It is also is harder to keep track with someone elseās code; since this is not really my game from scratch but following his convoluted architecture and ways of doing things. When he starts reformatting the working code without a clear reason besides that he mislead you before, your motive to do so yourself lowers especially when all u wanna do next is see how he determines the logic for the next step in this case changing the enum color of the crosshair accordingly.
Yeah, I have to say, I got some frustration myself about the misleading and refactoring. But then Benās tells us why he does that (at the end of Battle Tank section I think) and it makes more sense then.
As a middle range coder, Iām not sure I like that way of teaching, and I know it will be confusing for beginers. At the same time though, it shows you what a developper goes through when desining. I mean itās easy to paint yourself into a corner. But Benās says, well, if you find that you did something wrong, fix it and then continue on.
The lesson here, is really that refactoring is a big part of conding. Donāt expect to do everything right the first time, you always have the chance to fix everything.