Section Production Progress

Fixed :slight_smile: Thanks again Dan

Not sure if this was supposed to be part of the challenge or if you were trying to get people to check against isHovered but OnClicked actually has the behaviour you described.

1 Like

You passed the extra points challenge :slight_smile:

We’re rolling, Physics Materials just shipped. Fly-by-wire control systems next.

3 new videos live yesterday, hoping for the same today

Thank you for mentioning my HoverTank project post in the end of lesson 147. Very honored! :smiley:

@ben, on lecture 149 the challenge resource links are not added to the course list yet.

1 Like

Thank you, I’ll get to those resources, I appreciate it.

I think I care too much sometimes. I spent the entire day refactoring the way we work with components because I was uncomfortable with the prototype even though it works (see the refactor branch on GitHub if you like)

I’ll get to recording tomorrow once the implications have sunk in, and it’s late here now.

In the meantime enjoy yesterday’s 3 videos and rest assured it’ll be worth it in terms of clarity.

I feel like the current implentation is seriously overcomplicating the problem of how to move the tank. Especially considering how it was previous version of this section and the Unreal’s training stream of creating a tank, which is similar to that.

link: https://www.youtube.com/watch?v=Oh7pDL8RFaI

I have seen that, we are making it more physical. It is complex but the idea is to learn as many re-usable tools as possible, and I think you will.

1 Like

Those resources against 149 are there now, thanks again

The UE4 stream uses a “simple move the object to another location” while @ben is showing us how to apply physical force to accelerate and turn our tanks. In the long run this physical movement will add to the overall feeling of the game :slight_smile:

Yes, and we will be forcing the AI to use the same controls as us. This will extendable to boats, hovercraft and much more

I kind of disagree, by the sounds of it we aren’t going for a simulation-esque game but a more arcade-esque version, so why have more complex, simulation style controls when the aim is for arcade? Doesn’t really make sense.

We’re going for the architecture that will teach the most general tools, and provide an interesting challenge - at least that’s my intention

Well couldn’t you use the AddForceAtLocation to something like speed/slow tracks within the level to push/slow down a tank. Whilst having more arcade like controls? Unless you planned on doing suspension also, but wouldn’t that require cutting the wheels from the body mesh?

uhm…sorry to ask: but have you seen the fly-by-wire lesson yet?
The tank gets a normal “arcade” steering as a control-layer, which translates to the track-physics.

The struggle I was having today was nothing really to do with the control system.

What I’m trying to achieve is a very well separated component system, where for example we don’t have to pass references to barrels and turrets down from the tank to the tank aiming component, and likewise for the tank movement components.

@sampattuzzi and I have worked it out now, and it makes the whole process of adding new components to the tank such as the movement and aiming components much easier. It also makes the public interface to the tank and all of the other classes much cleaner, which is very important as the project gets larger.

One reason for the previous confusion was that we were composing actors in two places. Firstly there is the composition in the blueprint, and then we are adding default subjects in C++. Whilst this is a noble exercise and can be useful in some instances, in this instance it is making my life more complicated. I have now found a better way that is 95% perfect, and about as good as possible with Unreal I believe.

I look forward to sharing it with you all tomorrow

1 Like

Yes I have. But that doesn’t change my opinion that creating your own physics based vehicle system seems like it would be out of the scope this course. Having a tank that has wheels and then deriving from AWheeledVehicle seems like it would be better suited for the course.

My feedback regarding lecture 150 is the same as a previous one I gave on Udemy to do checking for nullptr on functions designed to initialise values, and realised I never got a reply.

The “pointer protection” you added to the end of the video is entirely pointless as it’s most likely not “protecting” anything as they are initialised to nullptr so if nullptr is coming into the function nothing changes and code somewhere else still might call their functions. The only case that it would protect from is if for whatever reason you were to call that function again with a nullptr after you initially set it up correctly. I think an assertion would have been better as it must be called with something valid.

Edit: Lecture 136, you could have enabled the tracing of the SuggestProjectileVelocity instead of relying entirely on guess work too see reasonable launch speeds.

Thanks @dan , sorry your previous comment got lost. I will add this to my queue of tweaks to the code, thanks

Privacy & Terms