script request
Moderator: Moderators
script request
#1:allow to disable auto radar dot targeting.
#2:allow to disable area attack for specific units or all units.
#2:allow to disable area attack for specific units or all units.
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: script request
You missed ...
#3: allow auto radar dot targetting when a specific building is built and online
... to get your OTA gameplay.
#3: allow auto radar dot targetting when a specific building is built and online
... to get your OTA gameplay.

Re: script request
In case someone implements this I have a request too: make a widget that performs auto radar dot targetting for those games that disable it.
Re: script request
Gota, the easiest way to do this would be to get rid of traditional Radar entirely, and build a custom Radar application, to decide when things are in radar range, and handle them appropriately. That should be possible to do, in a reasonably non-clunky way.
That said, this isn't exactly a newbie project, nor a really quick one, so you're probably SOL unless somebody's really bored and needs a challenge.
That said, this isn't exactly a newbie project, nor a really quick one, so you're probably SOL unless somebody's really bored and needs a challenge.
Re: script request
If it gets to the point that you can't do it via normal lua, I think I'll take a crack at a screen-scraping widget.Tobi wrote:In case someone implements this I have a request too: make a widget that performs auto radar dot targetting for those games that disable it.
Re: script request
Oh, sure, you can always auto-target anything you want to, with a Widget.
But making it all that effective, vs. spoofing? Kinda hard. For example, if the algorithm targets nearest, I will happily send flying units ahead of ground waves, and nullify Bert/Tim auto-aimers. The method I'm talking about would not send any unitIDs across the sync barrier, so your algorithm would be foxed.
Here's pseudocode. I'm this bored, but no further. I have to get back to finishing all the stuff I left unfinished on Friday.
SYNC
1. For each radar object, do a cylindrical search around its XYZ.
2. For each table of UnitIDs returned, check if visible. If no, check if Stealth or Cloaked. If no and no, then add the location XYZ (with offsets, duplicates, or other obfuscation) to the blip table, along with the detecting Team.
3. Send blip table to unsynced.
UNSYNC
4. Initialize the draw table.
5. For each entry in blip table, if Team == LocalTeam, then enter into draw table.
6. Draw the blips. This would be a good use for P.O.P.S. btw.
The only really serious hole in this is if Widgets can access the sync-->unsync communications, even if they're addressed to a function in the unsync portion of a Gadget.
If that's true, then you can have a radar hack of everybody's radar pretty easily. I'd have to vote that if that's true, it is not a feature of Spring, and should get fixed. We do not want Widgets reading unsynced Gadget data, unless it's been put into a global table specifically for that purpose.
Otherwise, the data's all in the Gadget, involves no true UnitIDs on the unsync side, nor any exact locations. You could intercept the drawing process and see the blips, and then auto-aim, but it won't work very well at all.
But making it all that effective, vs. spoofing? Kinda hard. For example, if the algorithm targets nearest, I will happily send flying units ahead of ground waves, and nullify Bert/Tim auto-aimers. The method I'm talking about would not send any unitIDs across the sync barrier, so your algorithm would be foxed.
Here's pseudocode. I'm this bored, but no further. I have to get back to finishing all the stuff I left unfinished on Friday.
SYNC
1. For each radar object, do a cylindrical search around its XYZ.
2. For each table of UnitIDs returned, check if visible. If no, check if Stealth or Cloaked. If no and no, then add the location XYZ (with offsets, duplicates, or other obfuscation) to the blip table, along with the detecting Team.
3. Send blip table to unsynced.
UNSYNC
4. Initialize the draw table.
5. For each entry in blip table, if Team == LocalTeam, then enter into draw table.
6. Draw the blips. This would be a good use for P.O.P.S. btw.
The only really serious hole in this is if Widgets can access the sync-->unsync communications, even if they're addressed to a function in the unsync portion of a Gadget.
If that's true, then you can have a radar hack of everybody's radar pretty easily. I'd have to vote that if that's true, it is not a feature of Spring, and should get fixed. We do not want Widgets reading unsynced Gadget data, unless it's been put into a global table specifically for that purpose.
Otherwise, the data's all in the Gadget, involves no true UnitIDs on the unsync side, nor any exact locations. You could intercept the drawing process and see the blips, and then auto-aim, but it won't work very well at all.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: script request
Why do you want it if a widget can override it? Will there be a benefit to not auto targetting radar blips?Gota wrote:Someone implement this?
Re: script request
Not if it is being overriden.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: script request
Not if he blocks widgets.neddiedrow wrote:Not if it is being overriden.
Re: script request
But that description is for NO aiming at radar blips, not just auto. And I agree that doing that shuts out firing on mobile targets pretty effectively.
Re: script request
Well, you can have follow-the-dot behavior in an all-manual context, that's not really difficult:
AllowCommand()-->CMD.ATTACK-->
if attackTable[attackerID] == nil then
if dot position +/- XZ
then enter into an attack table (attackerID, targetID).
Every a few dozen frames, run through the attackTable's contents, issuing CMD.ATTACK from the attackerID to the targetID... rinse and repeat until unitID is dead or is out of range.
That'd make it ever-so-slightly more annoying to code / manage, maybe 50 more lines of code, but whatever.
And if you wanted to allow for auto-target Widgets in that context, then just pass the dot locations out of the Gadget, voila. It will never work as well as Spring's default behavior, but it can be done.
this is assuming that that security hole I mentioned doesn't exist- haven't tested it yet, I am assuming no, Widgets may not read *anything* coming from SendToUnsynced() by pretending to be unsynced Gadget code, they may only read Messages
As for area-attack, I am confused about why Gota wants this. Area-attack is usually less effective than spec-firing manually at the most likely locations anyhow.
That said, removing area-attack is the easiest thing of them all. Just remove the commandID from all Units when Created, and if something else tries to pass it, kill it in AllowCommand().
AllowCommand()-->CMD.ATTACK-->
if attackTable[attackerID] == nil then
if dot position +/- XZ
then enter into an attack table (attackerID, targetID).
Every a few dozen frames, run through the attackTable's contents, issuing CMD.ATTACK from the attackerID to the targetID... rinse and repeat until unitID is dead or is out of range.
That'd make it ever-so-slightly more annoying to code / manage, maybe 50 more lines of code, but whatever.
And if you wanted to allow for auto-target Widgets in that context, then just pass the dot locations out of the Gadget, voila. It will never work as well as Spring's default behavior, but it can be done.
this is assuming that that security hole I mentioned doesn't exist- haven't tested it yet, I am assuming no, Widgets may not read *anything* coming from SendToUnsynced() by pretending to be unsynced Gadget code, they may only read Messages
As for area-attack, I am confused about why Gota wants this. Area-attack is usually less effective than spec-firing manually at the most likely locations anyhow.
That said, removing area-attack is the easiest thing of them all. Just remove the commandID from all Units when Created, and if something else tries to pass it, kill it in AllowCommand().
Re: script request
No security issues there, unsynced is well separated.
I don't think we understand each other. If you detect commands issued next to dots and turn them into attacks on dots, then I refer back to my first post, about a screen-scraping widget.
I don't think we understand each other. If you detect commands issued next to dots and turn them into attacks on dots, then I refer back to my first post, about a screen-scraping widget.
Re: script request
If they're well-seperated, then we're cool.
I think we mis-communicated when I went into speculative mode (big surprise, I started thinking out loud, sorry, I always like looking at the other things that a basic concept can be used for).
That second part's just about how it could be more than either / or like Gota wanted.
I mean, with a custom "radar", you can make it do a lot of things, so long as you don't care about terrain. It could be realistic radar, with burn-through, focus, obfuscation, chaff, etc., allow or not allow auto-aim depending on the type of Unit, etc.- there are a lot of applications, once you go outside the engine's default mask behaviors. I don't plan on doing anything with that, though, it's the kind've thing that guy who wanted to do a Harpoon clone would have liked.
I think we mis-communicated when I went into speculative mode (big surprise, I started thinking out loud, sorry, I always like looking at the other things that a basic concept can be used for).
That second part's just about how it could be more than either / or like Gota wanted.
I mean, with a custom "radar", you can make it do a lot of things, so long as you don't care about terrain. It could be realistic radar, with burn-through, focus, obfuscation, chaff, etc., allow or not allow auto-aim depending on the type of Unit, etc.- there are a lot of applications, once you go outside the engine's default mask behaviors. I don't plan on doing anything with that, though, it's the kind've thing that guy who wanted to do a Harpoon clone would have liked.
Re: script request
A radar system would be great....I guess..
This way area attack would be possible on units in los but not on radar blips which is even better.
This way area attack would be possible on units in los but not on radar blips which is even better.
- 1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
Re: script request
my oppinion exactly.Tobi wrote:In case someone implements this I have a request too: make a widget that performs auto radar dot targetting for those games that disable it.
Re: script request
um what? you contradict yourself so much yan.1v0ry_k1ng wrote:my oppinion exactly.Tobi wrote:In case someone implements this I have a request too: make a widget that performs auto radar dot targetting for those games that disable it.
Also i did both. If you are interested and have substantial sums of money pm me.
Re: script request
Ood_b wrote:um what? you contradict yourself so much yan.1v0ry_k1ng wrote:my oppinion exactly.Tobi wrote:In case someone implements this I have a request too: make a widget that performs auto radar dot targetting for those games that disable it.
Also i did both. If you are interested and have substantial sums of money pm me.
Im not Tobi nor am i Ivory king.
WTF are you talking about?
Re: script request
quoted wrong person lolz