You are not logged in.
Pages: 1
First post on this forum. Nice place you got yourself here, xot.
Now I'll get my guns out. See the current turn_toward_direction(direction,turnspeed) script.
For starters, I propose we use towards in the script command name. I don't know why, it just sounds better. To me. Second, the script has an error. The variable turnspeed
referenced in the script doesn't exist, it should be spd
. Third, I propose an alternate version - either coexisting peacefully with the one above, or replacing it. I suggest that rather than a direction, an object or instance is used as the target. I also think the script should incorporate image_angle
, because I can hardly think of circumstances where you would not want the sprite of the instance to turn visibly towards the new direction.
Here is the alternative:
/*
** Usage:
** turn_towards_instance(instance,turnrate);
**
** Arguments:
** instance An object or instance ID to turn to (argument0)
** step Step size or 'turn 'speed', degrees (argument1)
**
** Notes:
** Use in a step event. Sprite origins should be centered for best result.
**
*/
{
if instance_exists(argument0) {
var da;
da=point_direction(x,y,argument0.x,argument0.y)-direction;
if abs(da)>180 da=-da;
if abs(da)>argument1 direction+=argument1*sign(da);
image_angle=direction;
}
}
A check for instance existance may be removed if one is sure the instance is always around. I also have the nagging feeling the script could be optimised even a little more, but my logic is failing me there.
Last edited by Smarty (2008-01-23 13:37:56)
Offline
Hi Smarty, welcome to the forums.
I think I'll keep this as a separate script since it really is quite different in intent than turn_toward_direction(). I'll give some consideration to renaming it using "towards" as you suggest, I'm not entirely sure which, if either, is grammatically correct. I also think I'm going to make the image_angle bit optional. While I agree that most of the time you would want to rotate the sprite, it's a little presumptuous and may cause headaches in rare cases where the user wants to preserve existing image_angle.
The original script could definitely use some optimization (and bug squashing apparently). I will probably apply your optimizations to it and credit you as a contributor.
Thanks for the new script, I'll be including it in the next update.
Abusing forum power since 1986.
Offline
Great initiatives deserve support.
I've considered making image_angle
optional as well, but decided not to include it for reasons of performance.
On retrospect, checking whether or not the instance exists should probably be removed from the script. This makes Game Maker error out upon calling it when the target instance does not exist, which is probably preferable over the script not doing what it is expected to do.
Offline
On retrospect, checking whether or not the instance exists should probably be removed from the script. This makes Game Maker error out upon calling it when the target instance does not exist, which is probably preferable over the script not doing what it is expected to do.
I agree 100%.
Abusing forum power since 1986.
Offline
In a top-down shooter, for example, the player could be set to face the mouse and still not go in that particular direction (he could be walking backwards). But in general, I agree that the image_angle = direction; part is useful. You almost expect the script to do it for you just by looking at its name.
While Game Maker uses "toward" at some places in the help file, it seems that all functions or actions use the form with a S. For example, move_towards_point() comes to mind. For more clarification, here's a quote from The Free Dictionary:
Some critics have tried to discern a semantic distinction between toward and towards, but the difference is entirely dialectal. Toward is more common in American English; towards is the predominant form in British English.
Since we're on the subject, you may want to fix the second argument on Smarty's code. Whether it really is 'turnrate' or 'step', there is an extra apostrophe in the description of that argument :
** turn_towards_instance(instance,turnrate);
**
** Arguments:
** instance An object or instance ID to turn to (argument0)
** step Step size or 'turn 'speed', degrees (argument1)
- Quimp
Last edited by Quimp (2008-01-24 23:08:01)
Offline
Thanks Quimp, I'll correct that and implement xot's remarks.
I just thought of a few other reasons why you would not want to adjust the image angle automatically: for one, you might not be registered. (speaking of which, the gmlscripts are not marked as such). Second, the fans of rendered images would rather use a number of correctly shaded subimages for the sprite and adjust the image index to the new direction themselves.
And I guess that's why I have a tendecy towards towards (sorry, couldn't help myself). My English teacher back in those days was an apostle of British English versus American English. The latter he merely considered a contamination.
The revised script:
/*
** Usage:
** turn_towards_instance(instance,step,imagerotate);
**
** Arguments:
** instance An object or instance ID to turn to (argument0)
** step Step size or 'turn speed', degrees (argument1)
** imagerotate Whether to adjust the image angle to the direction, boolean (argument2)
**
** Notes:
** Use in a step event. Sprite origins should be centered for best result.
**
*/
{
var da;
da=point_direction(x,y,argument0.x,argument0.y)-direction;
if abs(da)>180 da=-da;
if abs(da)>argument1 direction+=argument1*sign(da);
if argument2 image_angle=direction;
}
Last edited by Smarty (2008-01-25 04:09:49)
Offline
While Game Maker uses "toward" at some places in the help file, it seems that all functions or actions use the form with a S. For example, move_towards_point() comes to mind.
Well that settles it for me, I generally attempt to follow the standard set by the help file.
I just thought of a few other reasons why you would not want to adjust the image angle automatically: for one, you might not be registered. hmm (speaking of which, the gmlscripts are not marked as such).
I usually don't go out of my way to make scripts work for unregistered users (I'd rather they register), but I think this is another good reason to make image_angle optional. I'm really not sure what happens when an unregistered user makes a call to a registered function. Does is fail to build the executable, or does it throw an error on loading, or does it fail at run-time? And what about object properties like image_angle, do they simply get ignored?
As to your other point, I really should start tagging scripts for compatibility with Lite/Pro and GM5/6/7. A major overhaul of GMLscripts.com is in progress for it's one year anniversary, that gives me a good excuse to add those features to the script presentation.
Abusing forum power since 1986.
Offline
I usually don't go out of my way to make scripts work for unregistered users (I'd rather they register), but I think this is another good reason to make image_angle optional. I'm really not sure what happens when an unregistered user makes a call to a registered function. Does is fail to build the executable, or does it throw an error on loading, or does it fail at run-time? And what about object properties like image_angle, do they simply get ignored?
The executable builds without problem (a nag screen shows up at startup of course, just to remind everyone you've been using the freebie version).
On Game Maker 7 (and as far as I remember the previous as well) unregistered functions are considered errors. The Errors tab in the Global Game Settings decides what to do with those errors, so you can choose to abort on all errors, let the user decide this or not make them appear at all.
Two errors associated with using registered features on Game Maker 7:
[variable name]: This variable is only available in the Pro Edition.
Error in code at line [line]:
[script snippet]
at position [pos]: This function is only available in the Pro Edition.
The error messages are different in Game Maker 6.1 but I don't have an unregistered version of that. Oddly, the line, position and script snippet are reported for function calls but not for variable declarations.
By the way, the unregistered edition alllows reading registered variables.
Last edited by Smarty (2008-01-25 06:07:41)
Offline
Ahhh, thanks, very helpful information.
Abusing forum power since 1986.
Offline
Pages: 1