Hm, you've asked variations on this same question more than once now...

Quick answer: unless there's a compare after the instructions you've added or based on the value that you're changing (possibly due to it being copied elsewhere), it's not going to effect other stuff. Side effects for a single instruction tend to be pretty short lived and obviously checked. Also, unless you've written several lines of code to achieve your goal there probably isn't any "better" or "more right" way to do anything, simply other ways that achieve the same effect. So xorps is fine.

If there was another register that always held 0 then you could probably avoid having to allocate memory by changing the bytes of the movss instruction so that it uses that register instead of xmm5 but... I don't know that that's really "better". I've had dozens of scripts that each allocate 1000 memory before and never seen any issues with it, and why should I? After all, games tend to use several gigabytes of memory and are running on processors designed to execute billions of instructions...the relatively infinitesimal modifications scripts make seem very unlikely to cause any performance issues (there are exceptions like in often run loops but in general).

Long Answer:

What have you googled or watched to help figure it out on your own? And yes, I see that you've shown a solution with xorps but...

For an instruction that changes the typical flags like add you can usually google something like "assembly flags add" and find a reference page that mentions what flags it changes (and thus could affect other stuff if there's a compare after your injection) like http://x86.renejeschke.de/html/file_mod ... _id_5.html
I haven't really found that to be the case with SSE instructions however, the compares do tend to be simpler with them in my (somewhat limited) experience though.

I know it can be annoying to have people ask "well what have you done yourself already?" but there are 2 main reasons for it:

A) you really _can_ learn more by figuring it out yourself (though not necessarily as quickly). It's more likely to "click" for you if you have to go through the process of encountering the problem, looking up information, testing, looking up more if it didn't work, and finally getting a working solution. And you're more likely to remember the work you did to find the solution the next time you need to do something similar, compared to simply asking and having the answer given to you.

B) By asking you are essentially asking people to spend their finding or writing the answer for you, often with relatively little proof that you've spent much of _your_ time trying to figure it out, which can be annoying

Yeah, you use byte ptr to tell the assembler to check 1 byte rather than the default 4 bytes. 107 however is not a valid 1 byte value, FF is the largest 1 byte value in hexadecimal (each hex digit represents 4 bits, sometimes called a nibble, so 2 represents 1 byte), or 255 in decimal ((int)255 or #255) and remember that the default is hexadecimal...

The values are assuming that it's unsigned, FF/255 is -1 if it's signed, which makes the largest value 7F or 127.