Does the current modding API give access to a unit move function/command?

I have an idea for a mod that would need access to the following:

A unit's location
A unitMove() function or command of some sort

Is this currently possible? I want to use math to generate paths/patrol paths for a unit, such as a circle (flying around the perimeter instead of swarming in the area of a circle (a modifer for current area patrol would be nice for this).

EDIT: for the record I've spent the last half hour reading through posts on this forum, trying to find details of what i want, but to no avail. I've also exchanged a couple of messages with @garat

According to this https://github.com/Noah-Huppert/PA-Documentation/blob/master/creating-a-game.md, what I want is not currently available accessible. But I'm not sure if I'm missing something. Your help would be greatly appreciated!

The doc you linked is a partly outdated doc about the gamesetup code. Dunno why you would look for unit movement there. The API that PA itself uses currently is "holodeck.unitGo". The issue with this is that you only get to pass x/y and the game uses those coordinates as the screen location "clicked" (the default code puts in the cursor position). So you can have a unit move in a circle that is all on visible surface. In fact imba walls as well as trialQ wall writing mod work like that, but instead of unitGo they call the method to place buildings.
I don't know of any way to actually give commands that are directly in world coordinates.
Basically the default UI doesn't need that kind of access and for the most parts the API only strictly has what the default UI may need so far. :S

The only way I can think of right now to do what you want is to actually simulate mouse movement with an external script.

EDIT:
The best thing possible may be some hotkey to have a unit cycle on the currently visible side of the planet. So make a spiral on the currently visible side basically. Though you'd still need the player to give you a few points at least where the planet starts/ends.

So ideally what I need is a method to access gameworld coordinates of a unit (x,y,z) and a unitMove(x,y,z) function tocall. Raster coordinates are going to be basically useless without the corresponding function to convert from raster to vector/gameworld. I don't like the idea of simulating mouse movement... not sure what you mean in your edit @cola_colin - I guess the user could click a few times on the planet at certain points (e.g. the poles), and raster convert....?

Might I be so bold as to ask a developer to join in this discussion please, @garat - perhaps you could ask the right programmer to chip in? I would really love this kind of access to the underlying code in the modding API. I have all sorts of ideas! One of the reasons I backed this game was your stated goal of a brand new engine that would support modding, and you've really delivered on that so far; I hope you intend to further extend the modding capabilities

My edit basically suggest to only make a circle on the screen. So only on the visible part of the planet.
Getting this kind of access would be quite awesome and potentially allow for quite some powerful mods indeeds.
Yeah I hope as well that the gameplay scripting abilities will be as powerful as the UI scripting abilities right now.

As I understand it you want to:
Draw a circle using area command.
But let the unit only patrol along the border of the circle, rather then the in the entire surface area (default).

And you want do that by intercepting the "area patrol" order and (when a modifier key is pressed) replace it with a queue of patrol orders going along the circumfence.

Do I get that right?

Yeah you got it

Specifically, I want to write a mod that will be able to issue move commands to units based on game-world location. For instance, I want to be able to click on a unit, hold a modifier key, and do an area patrol over the whole planet. The mod then determines the location of the unit, and calculates a spiral path outward from the unit's location (scouting outwards in a spiral path is much better than scouting outwards randomly).

Another modifier key could be used for patrolling the border of the area defined by the area patrol command, as you say. Having units grouped together and patrolling around something is sometimes better than a random swarm over the area.

I'm sure I could come up with other patterns of movement, either for fun or ebcause they could be useful in game. Overall goal of the mod would just be to reduce micro (load a large planet and try and define a spiral path for a firefly!). Area commands in PA are frickin' great, and I'd love to be able to expand on them.

EDIT: The math looks.. sorta simple? http://mathworld.wolfram.com/SphericalSpiral.html starting point anyway!

We have had devs pretty active in here. I'll see if I can summon @jorgenpt to the discussion.

Thank you!

Hi there guys, I'm Jørgen, the most recent engineering hire here at Uber. It seems like I'll be spending time with the server side modding going forward, but I'd also be interested in what you guys feel like would be valuable additions to the client side modding.

I can't promise anything specifically about the unitMove() function, but I'll be keeping an eye on these threads to see what kind of functionality we should be implementing.

Is this because of the concerns about using that kind of api for cheating? You might want to take a look at this thread from before you started at Uber that had a pretty good discussion on the pros and cons of that kind of api. There were lots of good arguments on both sides.

Well, generally speaking it's because we need to make an internal decision about what kinds of things we want to expose to the client, but yes, what's considered "cheating" would be a part of that discussion, as would assignment of limited resources. Thanks for the link to that thread!

Looks like PA Client API Requests got stickied, so you've probably seen it already.

The biggest thing is the ability to operate in 3d coordinates, and translate between game and screen coordinates, which coincidently enough is what this thread is about.

Will you be helping with any server side things as well? There is also a server API request in which a couple things get requested.

Also a lot of UI mods would need access to a bit more information. Currently I don't think there is even a way to get the planet currently being played while ingame. Also it probably would be really helpful to be able to interact more with i.e. order queues, factories queues, unit command queues, etc.

The most important blocker for us right now as I see it is the dependence on single files that must be shadowed to change. Eg; unit_list.json & build.js. This stops the use of unit mods dead right now, as you can only have 1 unit-modifying mod active at a time. Changing these to be hookable would be great

As for other changes, see https://forums.uberent.com/threads/pa-client-api-requests.57785/ and https://forums.uberent.com/threads/pa-server-api-requests.61182/

As far as server side and unit move type mods go I'm really hoping we'll have enough hooks to be able to create a 'Art of defense' map where an ai basically sends generated units down a path and all must be destroyed before reaching their final waypoint.

Difference to the requested UI mod feature: Such an art of defence map can be a server mod. Server mods may "cheat" all they want.

While working on the minimap and dealing with cameras and holodecks I realized something...

Code:

moveSelectedUnit(-13.734070777893066, 512.0687866210938, -319.0382995605469, undefined, true);
moveSelectedUnit(-19.462081909179688, 505.6476745605469, -328.0572509765625, undefined, true);
moveSelectedUnit(-23.261962890625, 499.2575378417969, -336.5821228027344, undefined, true);
moveSelectedUnit(-28.225814819335938, 493.3883972167969, -344.3053894042969, undefined, true);
... char limit of the post exceed, there are 98 lines in total
moveSelectedUnit(145.70860290527344, 232.6815643310547, -535.573974609375, undefined, true);
moveSelectedUnit(165.987548828125, 233.50634765625, -527.7467651367188, undefined, true);
moveSelectedUnit(189.55514526367188, 223.9326171875, -522.7791748046875, undefined, true);
moveSelectedUnit(209.72442626953125, 206.51544189453125, -521.520263671875, undefined, true);
moveSelectedUnit(219.3948211669922, 190.6726837158203, -523.9412841796875, undefined, true);
moveSelectedUnit(224.83726501464844, 181.87899780273438, -525.004638671875, undefined, true);
moveSelectedUnit(227.19818115234375, 175.37974548339844, -526.5576782226562, undefined, true); 

watch magic happen, takes 25ms per command, it's race condition involved...

Spoiler: Can you guess how it works? Solution in here.

Code:

    var deck = $('<holodeck class="pip"></holodeck>');
// add a pip somewhere hidden from the player
    deck.attr('style', "top: -105px; left: -105px; width: 101px; height: 101px;z-index: -1;position:fixed;");
    deck.attr('id', 'cmd_hack_pip');
    $('body').append(deck);

    hdeck = new api.Holodeck($('#cmd_hack_pip'), {}, undefined);

// sets the camera to x/y/z on the pip we created
    var setHdeckCamera = function(x, y, z, planet) {
        planet = planet === undefined ? 0 : planet;
        var focusBefore = model.holodeck; // assumes we are in live_game directly
        hdeck.focus();
        api.camera.lookAt({planet_id: planet, location: {x: x, y: y, z: z}, zoom: 'air'});
        if (focusBefore) {
            focusBefore.focus();
        }
    };

    setTimeout(function() {
        // start at planet 1, see race condition comment a few lines below
        setHdeckCamera(1, 0, 0, 0);
    }, 1000);

// give command to selected unit "move to the middle of the hidden pip"
    var moveToHdeck = function(queue) {
        hdeck.unitGo(51, 51, queue);
    };

// commands queue, as we need to handle commands one at a time to deal with a race condition
    var commandsWaiting = [];
    var movingCamera = false;

    moveSelectedUnit = function(x, y, z, planet, queue) {
        if (!movingCamera) {
            movingCamera = true;
            setHdeckCamera(x, y, z, planet);
            setTimeout(function() {
                moveToHdeck(queue === undefined ? false : queue);
                movingCamera = false;
                var next = commandsWaiting.splice(0, 1);
                if (next && next[0]) {
                    next[0]();
                }
            }, 25); // race condition vs camera movement, noticeable effect especially if the camera has to move between planets. Maybe use 1pip per planet or a few more pips in general
        } else {
            commandsWaiting.push(function() {
                moveSelectedUnit(x, y, z, planet, queue);
            });
        }
    }

The concept can be applied to any sort of command that only accepts holodeck x/y coordinates. So you could place buildings as well. I guess one could update imbawalls to work at the hidden side of the planet, so you dont need to hold the camera still anymore, etc. Many possibilities I guess.

EDIT:
Random unverified though: If you want to have the current position of a selected unit you can maybe use the "move camera to selected unit" command and then do a ping command, both in the pip. Then capture the ping alert and read the coordinates. Might be annoying with all the pings though, dunno if we can prevent them from showing up.

I thought of using high-numbered anchors plus screen coords to make a sort of macro mode. Lookat+center is a nice hack.

Would a client mod be able to change the presentation? Prevent you from getting regular pings.

The anchors might work for that - jump to unit in a pip and take an anchor. Depends on whether you want to able to process the coordinates or just use it for commands.

macro mode?
Yeah I guess -without checking- it might be possible to remove the ping graphics and stuff, so the player cant see any pings at all, though that obviously destroys the ping feature. Well I could show the pings I _want_ to be shown on the minimap instead... Does ping even accept screen coordinates? I've not seen the call anywhere so far.

Actually yeah using anchors you can at least get a way to later give a command to go "back there". Doesn't actually give you coordinates to work with though.