Scripting commands I wish existed

[annikk.exe]

This is a command wishlist.  These commands do not work and should not be used in level design.

I'm just sort of making up the syntax as I go along, based on conventions I've seen in existing commands.
Feel free to add your own.  :>


VariableName = GetAsteroid(ID):AddFlower(Empire ID)
VariableName = GetAsteroid(ID):AddMine(Empire ID)

Add a named flower/mine to the given asteroid's orbit, belonging to the given empire.  This is so I don't have to faff about swapping the asteroid to the right player, insta-growing a "flower" on a defense tree and plucking it, then switching the asteroid back again.


VariableName:SendFlowerToAsteroid(ID)

To send a named flower (or mine) to the given asteroid.  Come on, srsly, I need to make a mine invasion level!!


GetAsteroid(ID):SetAsteroidAttribs(x,y,en,st,sp)

Alter the basic attributes of a given asteroid.  This command would let us make some really awesome things, like asteroids whose energy, strength and speed improves over time, or decreases over time - the much talked about "aging and dying trees" idea.  It would also allow us to create moving asteroids...  currently we can change the radius in our scripts (like my pulsar :>) but not the position of them.  Moving asteroids would open up a huge number of level-making possibilities.  Imagine a level with small asteroids orbiting a giant central asteroid!  Like moving planets orbiting in a solar system!  It would be incredible.  :>


GetAsteroid(ID):Remove()

Removes the given asteroid from the game completely.  Any seeds travelling to it turn around and go to the last asteroid they were at (or if that one was removed too, the nearest asteroid that still exists).  Seeds cannot travel to the removed asteroid location anymore, the trees on the asteroid disappear along with it, and any seeds that happen to have been orbiting the asteroid at the time automatically travel to the nearest asteroid, unless they have already been ordered (eg by a script) to travel somewhere.

This command would be an alternative to the Die() and Hide() commands that I use at the moment.  "Return To Fluffy Land" illustrates this problem well.

[evoke]

I would recommend breaking up the feature request for setting asteroid attributes to two methods.

GetAsteroid(ID):ModifyAsteroidAttribs(en,st,sp)
GetAsteroid(ID):MoveAsteroid(xpos,ypos)

Primarily as the modification of non-positional attributes is much easier to define crisply, and likelier therefore to be granted implementation.
The first ability, to mod attributes, would just of itself give custom boards a lot of new options.

Whereas moving an asteroid raises several handling questions about what to do with asteriods that would overlap or collide in the same 2D space, or inadvertently wander way off the map, so to speak.  Though imho, the easiest solution is to simply say, if they do collide, or stray xyz far away, the asteroid(s) involved are destroyed.  I think that could be coded relatively simply by the author, and being (relatively) simple solve most or all the handling questions movement raises, allowing for opening up the API therein.  (Though it might also depend on whether moving asteriods requires code to move seedlings / tree / flowers, or flows naturally from the existing engine's codebase.)

-evoke

[njursten]

I'd like a RemoveSeedlings(int num) function added to the Asteroid class.

Also, it'd be nice if you could assign a group to seedlings you add, maybe to asteroids also, so you could later on give orders to that group, regardless of which asteroid they are on or if they're in transit.

[Alex]

Great stuff, thanks for making this thread - I will try to get these done.

[annikk.exe]

I would recommend breaking up the feature request for setting asteroid attributes to two methods.

GetAsteroid(ID):ModifyAsteroidAttribs(en,st,sp)
GetAsteroid(ID):MoveAsteroid(xpos,ypos)

This seems like a good idea.  :>

Whereas moving an asteroid raises several handling questions about what to do with asteriods that would overlap or collide in the same 2D space,

The current behaviour is that asteroids may created such that they overlap, although this is not recommended.

or inadvertently wander way off the map, so to speak.

The current behaviour is for the map to not load if an asteroid is off the allowed play area.  Presumably therefore an asteroid wandering off the play area would cause a crash.
Increasing the size of the play area to be substantially bigger would be awesome :>

Though imho, the easiest solution is to simply say, if they do collide, or stray xyz far away, the asteroid(s) involved are destroyed.

That wouldn't be my preferred behaviour - instead I would like a play area of unlimited size and no restrictions about colliding asteroids, and the ability to destroy asteroids with a seperate command as posited in my original post.  :>
I think that would give us maximum flexibility in level design, and also I think this approach is more intuitive - you don't exactly expect that there is an "allowed play area" (i will have to do some testing to find exactly what the play area is sometime) and this can and did trip people like me up when learning, mainly because the error message doesn't really explain what has happened.

I think that could be coded relatively simply by the author, and being (relatively) simple solve most or all the handling questions movement raises, allowing for opening up the API therein.  (Though it might also depend on whether moving asteriods requires code to move seedlings / tree / flowers, or flows naturally from the existing engine's codebase.)

The choice of how exactly everything is implemented at the end of the day is up to Alex and Rudolph.  They made a great game, I am sure we can trust them to figure out the best solution for these decisions also.  :>  I don't think the changes are going to be small, though.... and you know how it goes, all programmers are optimists..  :p