It sounds to me like your problem is the code in VS, not what you've found through reversing. The beginning of the function there doesn't seem to matter in accordance to what you're trying to do. Correct me if I'm wrong, but it sounds to me like you're thinking you have to find your way to the beginning of the function so that you can then figure out how far into the function you need to go to change what you want to change.
That's an understandable train of thought given your level of experience. (If that's what you're thinking, that is; I'm making an assumption to craft a reply based on.)
First of all, what you want to do is luckily very easy (relatively speaking) since all you want to do is directly change bytes. Given that, what you generally need to do is find a direct reference to the memory address that the bytes/instructions of interest are stored in. Let's break down what that means for you.
Look at the line you have highlighted in the screenshot:
00463716 75 09 JNZ SHORT ac_clien.00463721
00463716: This is a memory address. It's where your bytes of interest are stored. This is where you'll want to find your way to in your program.
75 09 JNZ SHORT ac_clien.00463721: 75 09 and JNZ SHORT ac_clien.00463721 are the same thing. The bytes, 75 09, are hexadecimal. They are a concise representation of binary sequences that the CPU understands. Why not just show the binary numbers directly instead of in hexadecimal? Well, let's look at what 75 09 is in binary: 111010100001001.
Now imagine seeing all binary in that column in OllyDbg, as opposed to hexadecimal. Not only is it unwieldy, but with some instructions, the numbers would take up a ridiculous amount of space in the row. Also, it's much easier for you, the human reader, to know what byte 75 means as opposed to bits 1110101, which is what the CPU ultimately understands.
The assembly instruction that you see in English (JNZ SHORT ac_clien.00463721) is an even further distillation for us to be able to easily read the instruction. You see that and you know it says "jump a short distance to memory address ac_clien.00463721 if the zero flag is not set".
So, in the case of the instruction we're working with here, bits 1110101 is the same value as hex 75 is the same thing as JNZ. They're just different ways of representing the same thing, mostly for our sake so we don't have to try to read a bunch of 1s and 0s.
Bearing that in mind, you know that changing JNZ to JMP gives you automatic weapon fire. Thus, your program needs to find the memory address that byte is stored in (which, per the screenshot, is 463716, but may change upon restart). Then your program needs to write a new byte that you want. The byte you want for JMP in this case is EB.
Now you have everything you need for coding up an application. This is where my help stops and your external research begins, because now you're in the territory of forward engineering (the reverse engineering process is completed). Are you trying to code your hack in C, C++, Visual C++, C#, or otherwise? Your choice of language will directly inform the approach you take for programmatically finding the game's process, opening it, finding its base address, then writing your byte to the correct offset therefrom.
Where 'X' is your programming language of choice, questions like, "How do I find the base address of a game or program in X"; "How do I find the process ID of a game or program in X"; "How do I write bytes to a memory address in X", and so forth should lead you down the right path.
Finally, since you're hacking Assault Cube, I recommend signing up over on the Guided Hacking forum and inquiring there. They've used that game specifically as a target for countless tutorials of theirs over the years, and there are a lot of very experienced programmers who can help you through the basics, including learning about all the things you don't even know to ask about right now.
Hope that helps!
