LUA request
Moderator: Moderators
LUA request
A widget to help place metal extractors.
The widget should help you place mexes by moving your cursor upon them when ur trying to place a metal extractor on a metal spot.
The further away you are the more aggressive the widget will be,moving your curser more aggressivly and from further away to the metal spot.
Im not sure what mechanism would achieve that.
Maybe it can work at least on maps where the metal spots are smaller than the extraction radius and the widget would place your cursor in the middle of a metal spot so your mex would deffinatly cover it completly.
Where there are metal spots bigger than the extraction radius of the metal extractors the widget would shut off.
The widget should help you place mexes by moving your cursor upon them when ur trying to place a metal extractor on a metal spot.
The further away you are the more aggressive the widget will be,moving your curser more aggressivly and from further away to the metal spot.
Im not sure what mechanism would achieve that.
Maybe it can work at least on maps where the metal spots are smaller than the extraction radius and the widget would place your cursor in the middle of a metal spot so your mex would deffinatly cover it completly.
Where there are metal spots bigger than the extraction radius of the metal extractors the widget would shut off.
Re: LUA request
Doesn't that seem a little counter intuitive in that mexes will automatically jump to the ideal location then snap to the next one?
But I think another improvement on this is a widget that shows how much metal an extractor will give if its placed where it is, which si both informative and gives an intuitive gage of where the resources actually are.
I also think if Im placing a level 1 mex down, if it overlaps with another level 1 mexes radius then the two radii should glow and pulsate red with perhaps the candy bar animation with yellow so as to make it clear the two should not overlap
But I think another improvement on this is a widget that shows how much metal an extractor will give if its placed where it is, which si both informative and gives an intuitive gage of where the resources actually are.
I also think if Im placing a level 1 mex down, if it overlaps with another level 1 mexes radius then the two radii should glow and pulsate red with perhaps the candy bar animation with yellow so as to make it clear the two should not overlap
- TheFatController
- Balanced Annihilation Developer
- Posts: 1177
- Joined: 10 Dec 2006, 18:46
Re: LUA request
Building a list of best spots for mexs of various build sizes using a circular radius on the metal map would be a good few seconds of calculating at start up - not worth losing the chance to steal the best start point imo :p
-
- Posts: 196
- Joined: 25 Jan 2008, 20:04
Re: LUA request
Sometimes you want to tactically place mexes away from the enemy(but still getting the metal), or even a cloaked and non-cloaked ones. Or you want to leave space for a moho mex. Also, it might be confusing(inconsistent) to noobs. The micro of putting mexes to exact location is pretty minimal too(one aim per mex). But if you want the lua script for yourself, and not install it defaultly, feel free imo.
Re: LUA request
Sounds like win
if you play speedmetal the gravitational forces pulling your cursor towards the metal will make your pc explode
= less speedmetal
+1 well not really
if you play speedmetal the gravitational forces pulling your cursor towards the metal will make your pc explode
= less speedmetal
+1 well not really
Re: LUA request
It will not snap to the next one.It will only move ur cursor a bit when ur already near the metal spot and u have selected a mex to build.AF wrote:Doesn't that seem a little counter intuitive in that mexes will automatically jump to the ideal location then snap to the next one?
But I think another improvement on this is a widget that shows how much metal an extractor will give if its placed where it is, which si both informative and gives an intuitive gage of where the resources actually are.
I also think if Im placing a level 1 mex down, if it overlaps with another level 1 mexes radius then the two radii should glow and pulsate red with perhaps the candy bar animation with yellow so as to make it clear the two should not overlap
You place the mex than you need ot move the cursor to the next metal spot.
The only differance will be that when your very zoomed out youll still be bale to place your mex without zooming in.
When zoomed in however at a certian distacne the widget will no longer assist you and youll be able to palce the mex as you wish.
Otherside,do not comment if you havent read the massage your commenting about,And dont comment negativly just cause you have some personnal negative emotions associated with me.
As i have written the widget should only work when each of the metal spots on the map can be completly included within a mexe's extraction radius.
This is a tested concept it works great in Supcom and imo should exist in spring.
There are gems hiding in Supcom that ar emissed by Spring's community.
These are tools that were designed to help players cope with big and complex battles.
Like this concept i described above,poorly,like the waypoint dragger that is probably the single best thing about Supcom in general.
Its just ashame nobody seems to notice them.
Not even people who should supposedly be most interested in any innovations that alow more flexibilty sicne these allow a mod/game to scale itself and be playable in more situations .
-
- Posts: 196
- Joined: 25 Jan 2008, 20:04
Re: LUA request
Ok, snapping to metalspot makes sense when the player is zoomed out sufficiently, i guess. Alternatively the build order could be converted to 'build mexes where metal is around this area'. Also, people might not appreciate hijacking their mouse. (The latter is a solution to that.)
Spring probably could do waypoint draggers, but people do not give orders the same way in spring, as in supcom! Most(many) people use the custom command widget, so changing orders one by one would take too long. Sending a bunch of units to a sequence of single points would give each such an order individually. (So that you would still have to move them all.) Also how it works currently, the units move much more clumsily if you send them to single points one by one.
So the change to be able to use waypoint dragging would be to both have units share commands when they are the same and changing the pathfinding function so it can handle sending many units to a single point properly. Or maybe the area the move command is dismissed at should get larger when more units go to a single position, but this might cause problems with the area getting too big and including area behind a wall, which units which get behind that, will have to go round again.(Taking an entirely different road.)
Pathfinding is slightly hard, but at least you can prove it works. How units will actually move is much more complicated then pathfinding, units get in each other way and such, also pathfinding should not take too much cpu. Further how pathfinding works can have a strong influence in gameplay, and there are a lot of decisions that can be made at that point. In that sense a mod in spring is already somewhat glued at one manner of gameplay. Squad based gameplay for instance might be hard/impossible/slow to implement in lua. Cars that actually have to move forward to change direction (as in reality) might get stuck, etc. (Movement is not directly doable in lua afaik either)
Gota are you a dev? You should realize that volunteers make this game. They make it as they wish, if you do not like it, contribute to help improve or fork it. Things are not that easy. Now to be honest, i can be a couch critic myself. Maybe just because i like spring
. I am saying this just to be sure that you realize. Also check for typos and spelling a little.. please :) And what is the problem with otherside? AFAIK he just meant he did not like all-metal maps, and he noted that 'gravitating' to a metal spot is not the best way to implement your idea. I say these are good prerequisites: 1) do not hijack cursor 2) indicate with a symbol that it is snapping to metal spot. 3) Do not do it when zoomed in. 4) have an off button. Further, the thermal vents could use the same.
Wouldnt the number giving the amount mined already hint enough? Maybe it is a metal spot just too large to do with a single mex.AF wrote:I also think if Im placing a level 1 mex down, if it overlaps with another level 1 mexes radius then the two radii should glow and pulsate red with perhaps the candy bar animation with yellow so as to make it clear the two should not overlap
Spring probably could do waypoint draggers, but people do not give orders the same way in spring, as in supcom! Most(many) people use the custom command widget, so changing orders one by one would take too long. Sending a bunch of units to a sequence of single points would give each such an order individually. (So that you would still have to move them all.) Also how it works currently, the units move much more clumsily if you send them to single points one by one.
So the change to be able to use waypoint dragging would be to both have units share commands when they are the same and changing the pathfinding function so it can handle sending many units to a single point properly. Or maybe the area the move command is dismissed at should get larger when more units go to a single position, but this might cause problems with the area getting too big and including area behind a wall, which units which get behind that, will have to go round again.(Taking an entirely different road.)
Pathfinding is slightly hard, but at least you can prove it works. How units will actually move is much more complicated then pathfinding, units get in each other way and such, also pathfinding should not take too much cpu. Further how pathfinding works can have a strong influence in gameplay, and there are a lot of decisions that can be made at that point. In that sense a mod in spring is already somewhat glued at one manner of gameplay. Squad based gameplay for instance might be hard/impossible/slow to implement in lua. Cars that actually have to move forward to change direction (as in reality) might get stuck, etc. (Movement is not directly doable in lua afaik either)
Gota are you a dev? You should realize that volunteers make this game. They make it as they wish, if you do not like it, contribute to help improve or fork it. Things are not that easy. Now to be honest, i can be a couch critic myself. Maybe just because i like spring

Re: LUA request
Just go play supcom,see how good it is and u wont have to give any tips.
I might be just explaining this badly but i tihnk i got the point through now.
I might be just explaining this badly but i tihnk i got the point through now.
-
- Posts: 196
- Joined: 25 Jan 2008, 20:04
Re: LUA request
@gota, maybe you should read other people better
. I did not say it was not good, but that it might not be that easy to implement. I might have some ideas to do it, but i would have to find how it currently works, and then how to change it without introducing any bug. The solution should work with movement orders out of custom-formation(and such things), which might mean changing that too. (Maybe giving each order-set belonging together a number and replacing all the orders with matching numbers of the selected units with a new order matching the change. And with a new number.)
Then the UI would have to be changed to use this thing too, again without bugs and while remaining easy to use; integrated with the rest.

Then the UI would have to be changed to use this thing too, again without bugs and while remaining easy to use; integrated with the rest.
Re: LUA request
WEll if you actually want to work on a command dragging widget i have one working.
It works and does everything.
It has one problem though it slows down and becomes unplayable when things get busy.
im not sure which one of them is better :
It was made by ray and he based his work on kloots widget.
http://pastebin.com/m69771701
http://pastebin.com/m29464423
This post was about the mex placement assistor.
It works and does everything.
It has one problem though it slows down and becomes unplayable when things get busy.
im not sure which one of them is better :
It was made by ray and he based his work on kloots widget.
http://pastebin.com/m69771701
http://pastebin.com/m29464423
This post was about the mex placement assistor.
-
- Posts: 196
- Joined: 25 Jan 2008, 20:04
Re: LUA request
@gota: When multiple units are selected, do you need to alter each command separately? I guess it can be useful without that, but it is limiting.(That is after all, what my whining is about.)
As for the mex setter function, if it behaves somewhat like i said in my second post, i am all for it.
As for the mex setter function, if it behaves somewhat like i said in my second post, i am all for it.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: LUA request
Don't move the players cursor it's really annoying. Just make the mex blueprint snap to the nearest mex spot.
Also can you give topics a name that is more descriptive than LUA request? eg. LUA request: Mex placement helper.
Also can you give topics a name that is more descriptive than LUA request? eg. LUA request: Mex placement helper.
Re: LUA request
I second that moving mouse cursor itself is highly annoying, and only really acceptable when cursor is invisible and you're using mouse for something else (like aiming in a FPS game).
Re: LUA request
WEll i might have thought that myself if i didnt play supcom and saw it in action.
Would be nice if someone who also played supcom comment on this so it doesnt look im supporting it cause its MY suggestion and I cant be wrong.
Would be nice if someone who also played supcom comment on this so it doesnt look im supporting it cause its MY suggestion and I cant be wrong.
-
- Posts: 196
- Joined: 25 Jan 2008, 20:04
Re: LUA request
Why do I need to have played supcom? You have my support, if it is implemented well of course.
Sorry about the off-topic whining about problems regarding making a (good) supcom-style command-dragging widget. (Still wondering if you can drag commands from multiple units efficiently.)
Sorry about the off-topic whining about problems regarding making a (good) supcom-style command-dragging widget. (Still wondering if you can drag commands from multiple units efficiently.)
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: LUA request
God I would love to have this. Like a dream come true tbh.