Reply to Re: Some self-indulgence
If you don't have an account, just leave the password field blank.
Do you consider your enemy shoot to be a modified version of Paul's enemy shoot?
Yes. Paul's enemy shoot was limited to simple gradients since he didn't know about the 'divide with integer' trick. My enemy shoot script is Paul's enemy shoot script with divide with integer. I had a bit of a dilemma on whether to mention this in the scripts or readme, because Paul used the wrong gradients in his file. I have functions like his to determine the crude direction between two points [globals4.c.. compare to my enemy shoot in globals3.c] and I didn't want to have to point out why they differed. It seemed like mentioning it might degrade respect in an otherwise great file and I'm sorry to have to mention it now. I certainly would have credited Paul if I released my enemy shoot separately though.
I gave credit for building off magicman and rabidwolf's health bar and Ted Shutes' hit code examples, even though both are so heavily modified I could have written them from scratch. See the comments at the top of hbar.c to see how much I changed, and compare hitcalc.c and hitcalcf.c to Ted Shutes' example in the help file [Ted Shutes' original code didn't even work but I still gave him credit].
If there is any other code in MouseDink based on other authors that I have neglected to credit then I would like to know and correct it. As far as I know, all the other code are my tricks or just using functions in the standard ways they were designed for by Seth.
Because I don't, they barely resemble each other.
and hence I say you don't respect scripts as a product and a property. Maybe now you can understand why it bothers me that there is a comment that promotes this disrespect on the page for my file. The enemy shoot scripts are identical except Paul had to avoid divisions that produced remainders, and I didn't. All other differences are superficial differences in the implementation. The logic is in common.
[What a great example to make my point, thanks.]
This is just bullshoot.
Do you not think it would be 10x easier to make a mouse controlled game with a fake Dink now then before MouseDink?
authors would use self-made movement calculations for Dink
It's not an important point, but for the record, Dink moves by sp_target'ing the beacon, not self-made movements. It is better to use dink.exe/internal functions where possible because they are more efficient than with DinkC [but the other side of the coin is that recoding in DinkC gives you more power over the process]. Part of the reason why it would be much easier to make a mouse controlled game now is because I've already considered many design decisions like that, selecting what to rewrite in DinkC and where I can use internal code functions [like sp_target], saving another developer from having to take the time to consider those decisions.
same manner of shoot calculation
If they don't care to shoot in any direction, ok. If they shoot in any direction, they are using my code.
Yes. Paul's enemy shoot was limited to simple gradients since he didn't know about the 'divide with integer' trick. My enemy shoot script is Paul's enemy shoot script with divide with integer. I had a bit of a dilemma on whether to mention this in the scripts or readme, because Paul used the wrong gradients in his file. I have functions like his to determine the crude direction between two points [globals4.c.. compare to my enemy shoot in globals3.c] and I didn't want to have to point out why they differed. It seemed like mentioning it might degrade respect in an otherwise great file and I'm sorry to have to mention it now. I certainly would have credited Paul if I released my enemy shoot separately though.
I gave credit for building off magicman and rabidwolf's health bar and Ted Shutes' hit code examples, even though both are so heavily modified I could have written them from scratch. See the comments at the top of hbar.c to see how much I changed, and compare hitcalc.c and hitcalcf.c to Ted Shutes' example in the help file [Ted Shutes' original code didn't even work but I still gave him credit].
If there is any other code in MouseDink based on other authors that I have neglected to credit then I would like to know and correct it. As far as I know, all the other code are my tricks or just using functions in the standard ways they were designed for by Seth.
Because I don't, they barely resemble each other.
and hence I say you don't respect scripts as a product and a property. Maybe now you can understand why it bothers me that there is a comment that promotes this disrespect on the page for my file. The enemy shoot scripts are identical except Paul had to avoid divisions that produced remainders, and I didn't. All other differences are superficial differences in the implementation. The logic is in common.
[What a great example to make my point, thanks.]
This is just bullshoot.
Do you not think it would be 10x easier to make a mouse controlled game with a fake Dink now then before MouseDink?
authors would use self-made movement calculations for Dink
It's not an important point, but for the record, Dink moves by sp_target'ing the beacon, not self-made movements. It is better to use dink.exe/internal functions where possible because they are more efficient than with DinkC [but the other side of the coin is that recoding in DinkC gives you more power over the process]. Part of the reason why it would be much easier to make a mouse controlled game now is because I've already considered many design decisions like that, selecting what to rewrite in DinkC and where I can use internal code functions [like sp_target], saving another developer from having to take the time to consider those decisions.
same manner of shoot calculation
If they don't care to shoot in any direction, ok. If they shoot in any direction, they are using my code.
