Reply to Re: Some self-indulgence
If you don't have an account, just leave the password field blank.
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.
Wow, you didn't even credit him? ...Yeah, giving credit can often be seen as a sign of disrespect.
and hence I say you don't respect scripts as a product and a property.
I think I'm just going to take your idea of respect with a grain of salt after reading the first quote.
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.
I didn't actually find the actual calculations before; sorry, that's my bad, I can see they are essentially the same. (WHY are these calculations in scripts called globals.c? I understand its shorthand for "global functions" or something, but that's the least intuitive label imaginable.)
All other differences are superficial differences in the implementation.
Yeah, the nudgy movement. Because it uses this I jumped to the conclusion it calculates it differently too... I still assume the calculations don't work if you use move_x and move_y normally (wouldn't make sense to nudgify otherwise). EDIT: I see you mentioned this in the OP. It's not imperceivable.
Do you not think it would be 10x easier to make a mouse controlled game with a fake Dink now then before MouseDink?
I didn't quote that part because it's the only part that wasn't BS; I said as much in the review. It's primarily easier because 1) MouseDink serves as an inspiration, and 2) you can borrow/check out some of the problem solutions from MouseDink when you get stumped (which doesn't include most of MouseDink).
It's not an important point, but for the record, Dink moves by sp_target'ing the beacon. 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].
He does? He moves with the code in c-dms.c as best as I can tell. I admit I have a hard time reading these scripts though: I can understand individual patches of code just fine, but finding what I'm looking for and keeping up with how related functions run all over the place is really painful. (Hence why I came to the conclusion it's needlessly difficult to decipher.)
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.
Such as implementing nudgy movement. I didn't mention things like this in the review because I figured picking everything apart in detail would be truly unfair, but it's a clearly visible difference from how projectiles move in OD. Under no circumstances would I want to use this kind of projectile movement over traditional use of move_x and move_y.
If they don't care to shoot in any direction, ok. If they shoot in any direction, they are using my code.
You mean they would be using Paul's code which you made superficial changes to. ;/
As an aside, I can't accept that if hell is the best method. Even a supersimple calculation like deducting the source X and Y from the target X and Y (then using move_x and move_y) gets the right direction, there has to be a better way.
Wow, you didn't even credit him? ...Yeah, giving credit can often be seen as a sign of disrespect.
and hence I say you don't respect scripts as a product and a property.
I think I'm just going to take your idea of respect with a grain of salt after reading the first quote.
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.
I didn't actually find the actual calculations before; sorry, that's my bad, I can see they are essentially the same. (WHY are these calculations in scripts called globals.c? I understand its shorthand for "global functions" or something, but that's the least intuitive label imaginable.)
All other differences are superficial differences in the implementation.
Yeah, the nudgy movement. Because it uses this I jumped to the conclusion it calculates it differently too... I still assume the calculations don't work if you use move_x and move_y normally (wouldn't make sense to nudgify otherwise). EDIT: I see you mentioned this in the OP. It's not imperceivable.
Do you not think it would be 10x easier to make a mouse controlled game with a fake Dink now then before MouseDink?
I didn't quote that part because it's the only part that wasn't BS; I said as much in the review. It's primarily easier because 1) MouseDink serves as an inspiration, and 2) you can borrow/check out some of the problem solutions from MouseDink when you get stumped (which doesn't include most of MouseDink).
It's not an important point, but for the record, Dink moves by sp_target'ing the beacon. 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].
He does? He moves with the code in c-dms.c as best as I can tell. I admit I have a hard time reading these scripts though: I can understand individual patches of code just fine, but finding what I'm looking for and keeping up with how related functions run all over the place is really painful. (Hence why I came to the conclusion it's needlessly difficult to decipher.)
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.
Such as implementing nudgy movement. I didn't mention things like this in the review because I figured picking everything apart in detail would be truly unfair, but it's a clearly visible difference from how projectiles move in OD. Under no circumstances would I want to use this kind of projectile movement over traditional use of move_x and move_y.
If they don't care to shoot in any direction, ok. If they shoot in any direction, they are using my code.
You mean they would be using Paul's code which you made superficial changes to. ;/
As an aside, I can't accept that if hell is the best method. Even a supersimple calculation like deducting the source X and Y from the target X and Y (then using move_x and move_y) gets the right direction, there has to be a better way.
