Hi Krash , this is for personal gameplay single payer only LAN GAME , i have a script that im working on it but for some reason i can't make it work ,an help is greatly appreciate
This was written with AI, yeah? Are you familiar enough with programming languages to address the syntax errors as they come up when the game's compiler reports an error? Have you started comparing with scripts included in existing mods to see what stands out as being done differently in the engine?
You'll understand if I'm reluctant to go too deep on the more advanced techniques needed for "useful" aim assistance, but target selection as you're attempting is a basic essential of working with custom turrets or bots in mods, and I'll approach any advice mainly from that persepective.
A few things in the code itself that immediately stand out beyond the extra strings/characters:
The script event scheduler is called by either %object.schedule(timeMS, command, <arg1...argN>); or schedule(timeMS, %object, command, <arg1...argN>); with timeMS being the integer milliseconds after which the command should run. You can leave the %object argument as 0 in the latter variant, and leave out the variadic arguments completely if you don't need them. schedule will return a handle for the event, which you can use with isEventPending(%event); and cancel(%event);
mClamp isn't (currently) an exposed script math function, but you could define it as %clamped = mMax(mMin(%val, %high), %low);
LocalClientConnection, not LocalClient
Converting your dot product to an angle in degrees is an unnecessary extra step. You can precalculate a threshold to quickly check the dot against with $Aim_Threshold = mCos(mDegToRad($Aim_FOV / 2)); once and check if (%dot >= $Aim_Threshold)
You can include the closest distance check earlier, at the same time you check if %dist > 500
getForwardVector derives from the orientation of the object itself. For player objects, which in normal gameplay only rotate on the XY axis unless mounted to another object, this means you'll be missing the vertical component of your aim direction. Players have two relevant vectors that move independently of their body: the eye vector (your head can turn and look up and down) and the muzzle vector (from the rotation of a mounted image slot). For working with where a player is focusing their weapon, you'll typically be using %player.getMuzzleVector($WeaponSlot); and %player.getMuzzlePoint($WeaponSlot); in common mods where $WeaponSlot has been set to 0 in item.cs.
You're not performing any validity tests to determine if you can actually see the player being aimed at, whether they're on the same team, whether they're alive, etc.
Cycling through the ClientGroup is fine performance-wise at a reasonable frequency given there won't ever be that many players to deal with, and this is a model you can see in operation in some of the existing AI scripts, however if you also wanted to target objects like vehicles or turrets, this isn't a practice you'd want to expand to the larger set of active objects in the mission. If you're using the latest patch, an optimized lookup pattern to facilitate this would be InitContainerFrustumSearch, which can much more quickly select and filter objects of interest within a specific frustum cone. The init could look something like this:
After this point the search is used in the same manner as a ContainerRadiusSearch, meaning as long as there is another object to iterate through, its object ID will be returned by ContainerSearchNext(); and ContainerSearchCurrDist(); will return the distance to that object from the start point.
Obviously this won't test things like teams or visbility either, so for starters you'll want to find %sensorGroup = LocalClientConnection.getSensorGroup(); then in your result loop dismiss them if you don't have sensor visibility e.g.
%target = %object.getTarget();
if (%target == -1 || isTargetFriendly(%target, %sensorGroup) || !isTargetVisible(%target, %sensorGroup))
{
// This object either doesn't have a sensor target, is friendly, or they're off-sensor (possibly cloaked/jammed)
continue;
}
After eliminating every additional quick validity check you want to do like seeing if they're dead/destroyed, but before accepting the object as a valid result target, you'll also likely need to test line-of-sight to make sure there isn't anything occluding it from view; for example if ContainerRayCast(%start, %object.getWorldBoxCenter(), $TypeMasks::TerrainObjectType | $TypeMasks::InteriorObjectType | $TypeMasks::StaticObjectType); returns a result, there isn't a clear unobstructed line from the muzzle to the center of the found object: it's blocked by terrain, an interior, or a static object.
If you were developing a mod around this feature being active and expected the player to commonly be indoors, you could potentially improve the search processing performance a bit by performing an occluder raycast first to limit your maximum search distance, but especially with it only being used singleplayer it's unlikely to be an issue worth dealing with. On the note of performance though, there will never be a need to update the target any more often than every 32ms, and even that would likely be more than necessary. This is when the server simulation will tick, and any additional frames under that time are interpolated on the client side for rendering -- so if you wanted to do a smooth pull of the crosshair towards a locked target while holding a controller button, for example, you'd want to do so in a lightweight loop seperate from the search logic.
hey Krash, i appreciate your response i copied what you'v pointed out and pasted to AI and this was the answer LOL:
You're absolutely right to be skeptical, and I appreciate you taking the time to provide such detailed, technical feedback. You've clearly worked with the TorqueScript engine and Tribes 2 modding before.
"(quote)Let me be direct with you:
Honest Assessment
Yes, the code was AI-generated. I don't have direct experience with Tribes 2's TorqueScript engine. I was pattern-matching based on general scripting knowledge, not deep familiarity with T2's specific implementation. The syntax errors you pointed out prove this - things like LocalClient vs LocalClientConnection, schedule() parameters, and mClamp not being exposed are classic "looks right but isn't" mistakes."(end quote)
Personally , I think You could revamp the hole Tribes 2 game with better graphics and call it Tribes 2 REBORN . You have the ability to do it , i know it takes resources ,a Go Fund me account will help
I truly appreciate your time and effort that you give to us few players that are still around (VGCR).
Would that the legal situation were simpler, I'd love to spend some time doing a proper full updated rebuild of the engine, but without license to distribute the game files to new platforms, and because there is a risk of a lawsuit if I even appeared to be commercializing something I don't have the rights to by raising funds... it'd be difficult to justify the upfront development time necessary. It would though, in the long term, in many ways be much much easier and less time consuming to work with and maintain than breaking down x86 code and stuffing new functionality into an existing binary.
Of course it'd be perfectly legal to accept tips towards running the service and developing/distributing the software we do the rights to, but the audience is limited and costs to operate over the years haven't really been enough to raise the question. All that's ever been asked is that people continue using the forums so the rest of the world knows the heart is still beating.
Anyways, if you have time and any interest in programming, I'd suggest taking a shot at modifying existing scripts and writing new functions yourself without asking the bot to do it. It's not as intimidating as it might look at first, there are no stakes beyond the satisfaction of having made it work, and once you start to get a basic understanding of the patterns and structures, working out how to solve more complex problems gets much easier. Even something as simple as changing the projectiles fried by a weapon/vehicle or making players move faster would be a solid entry point, and fun to quickly see the result.
Comments
This was written with AI, yeah? Are you familiar enough with programming languages to address the syntax errors as they come up when the game's compiler reports an error? Have you started comparing with scripts included in existing mods to see what stands out as being done differently in the engine?
You'll understand if I'm reluctant to go too deep on the more advanced techniques needed for "useful" aim assistance, but target selection as you're attempting is a basic essential of working with custom turrets or bots in mods, and I'll approach any advice mainly from that persepective.
A few things in the code itself that immediately stand out beyond the extra strings/characters:
%object.schedule(timeMS, command, <arg1...argN>);orschedule(timeMS, %object, command, <arg1...argN>);withtimeMSbeing the integer milliseconds after which the command should run. You can leave the%objectargument as 0 in the latter variant, and leave out the variadic arguments completely if you don't need them.schedulewill return a handle for the event, which you can use withisEventPending(%event);andcancel(%event);%clamped = mMax(mMin(%val, %high), %low);LocalClientConnection, notLocalClient$Aim_Threshold = mCos(mDegToRad($Aim_FOV / 2));once and checkif (%dot >= $Aim_Threshold)%dist > 500getForwardVectorderives from the orientation of the object itself. For player objects, which in normal gameplay only rotate on the XY axis unless mounted to another object, this means you'll be missing the vertical component of your aim direction. Players have two relevant vectors that move independently of their body: the eye vector (your head can turn and look up and down) and the muzzle vector (from the rotation of a mounted image slot). For working with where a player is focusing their weapon, you'll typically be using%player.getMuzzleVector($WeaponSlot);and%player.getMuzzlePoint($WeaponSlot);in common mods where $WeaponSlot has been set to 0 in item.cs.Cycling through the ClientGroup is fine performance-wise at a reasonable frequency given there won't ever be that many players to deal with, and this is a model you can see in operation in some of the existing AI scripts, however if you also wanted to target objects like vehicles or turrets, this isn't a practice you'd want to expand to the larger set of active objects in the mission. If you're using the latest patch, an optimized lookup pattern to facilitate this would be
InitContainerFrustumSearch, which can much more quickly select and filter objects of interest within a specific frustum cone. The init could look something like this:After this point the search is used in the same manner as a ContainerRadiusSearch, meaning as long as there is another object to iterate through, its object ID will be returned by
ContainerSearchNext();andContainerSearchCurrDist();will return the distance to that object from the start point.Obviously this won't test things like teams or visbility either, so for starters you'll want to find
%sensorGroup = LocalClientConnection.getSensorGroup();then in your result loop dismiss them if you don't have sensor visibility e.g.%target = %object.getTarget(); if (%target == -1 || isTargetFriendly(%target, %sensorGroup) || !isTargetVisible(%target, %sensorGroup)) { // This object either doesn't have a sensor target, is friendly, or they're off-sensor (possibly cloaked/jammed) continue; }After eliminating every additional quick validity check you want to do like seeing if they're dead/destroyed, but before accepting the object as a valid result target, you'll also likely need to test line-of-sight to make sure there isn't anything occluding it from view; for example if
ContainerRayCast(%start, %object.getWorldBoxCenter(), $TypeMasks::TerrainObjectType | $TypeMasks::InteriorObjectType | $TypeMasks::StaticObjectType);returns a result, there isn't a clear unobstructed line from the muzzle to the center of the found object: it's blocked by terrain, an interior, or a static object.If you were developing a mod around this feature being active and expected the player to commonly be indoors, you could potentially improve the search processing performance a bit by performing an occluder raycast first to limit your maximum search distance, but especially with it only being used singleplayer it's unlikely to be an issue worth dealing with. On the note of performance though, there will never be a need to update the target any more often than every 32ms, and even that would likely be more than necessary. This is when the server simulation will tick, and any additional frames under that time are interpolated on the client side for rendering -- so if you wanted to do a smooth pull of the crosshair towards a locked target while holding a controller button, for example, you'd want to do so in a lightweight loop seperate from the search logic.
hey Krash, i appreciate your response i copied what you'v pointed out and pasted to AI and this was the answer LOL:
You're absolutely right to be skeptical, and I appreciate you taking the time to provide such detailed, technical feedback. You've clearly worked with the TorqueScript engine and Tribes 2 modding before.
"(quote)Let me be direct with you:
Honest Assessment
Yes, the code was AI-generated. I don't have direct experience with Tribes 2's TorqueScript engine. I was pattern-matching based on general scripting knowledge, not deep familiarity with T2's specific implementation. The syntax errors you pointed out prove this - things like
LocalClientvsLocalClientConnection,schedule()parameters, andmClampnot being exposed are classic "looks right but isn't" mistakes."(end quote)Personally , I think You could revamp the hole Tribes 2 game with better graphics and call it Tribes 2 REBORN . You have the ability to do it , i know it takes resources ,a Go Fund me account will help
I truly appreciate your time and effort that you give to us few players that are still around (VGCR).
Would that the legal situation were simpler, I'd love to spend some time doing a proper full updated rebuild of the engine, but without license to distribute the game files to new platforms, and because there is a risk of a lawsuit if I even appeared to be commercializing something I don't have the rights to by raising funds... it'd be difficult to justify the upfront development time necessary. It would though, in the long term, in many ways be much much easier and less time consuming to work with and maintain than breaking down x86 code and stuffing new functionality into an existing binary.
Of course it'd be perfectly legal to accept tips towards running the service and developing/distributing the software we do the rights to, but the audience is limited and costs to operate over the years haven't really been enough to raise the question. All that's ever been asked is that people continue using the forums so the rest of the world knows the heart is still beating.
Anyways, if you have time and any interest in programming, I'd suggest taking a shot at modifying existing scripts and writing new functions yourself without asking the bot to do it. It's not as intimidating as it might look at first, there are no stakes beyond the satisfaction of having made it work, and once you start to get a basic understanding of the patterns and structures, working out how to solve more complex problems gets much easier. Even something as simple as changing the projectiles fried by a weapon/vehicle or making players move faster would be a solid entry point, and fun to quickly see the result.