Jump to content

===[COMMITTED]=== Order move indicator[Visual]


Lion.Kanzen
 Share

Recommended Posts

Fix your editor (take a look at the diff if you want to know why); handle interpolation (mostly just needed for the current (or first) line, unless some waypoint is actually another unit that is moving); figure out in what ways the code for UnitAI is broken now (there are some 5 years of changes to account for), figure out in what ways it was broken back then (though just figuring out in what ways it is broken now should suffice); remove that ugly duplication with the RallyPointRenderer; reconsider using std::list there (as in not using it); think about formations again (just because they are somewhat broken doesn't mean we should break them even more); possibly some more, also read the ticket that might have some insight.

  • Like 1
Link to comment
Share on other sites

@Lion.Kanzen I'm somewhat on it. 

See #657 and D557

I mostly fixed the duplicate code. @vladislavbelov raised concerns about STD deque and STD lists though Im not sure performance is would be really different.

About unitai Im not sure what is broken. About formations I think I will get the center of it and draw a line to the target no formation either multiple lines or no lines at all over three units. Still remains the question of the animated arrows. I need to make them disappear with no hack at the end of the anim and clearly have no idea on how to do that.

And last but not least I think it could be done for A23 But I clearly will need some help :/

  • Like 2
Link to comment
Share on other sites

Personally I'd rather have a move order visual indicator as you proposed at the beginning of the thread than waypoint flags. It looks cleaner to me (and it would certainly be easier to implement, as the pathfinder or interpolation wouldn't be involved in any way).

Link to comment
Share on other sites

1 hour ago, stanislas69 said:

@Itms If someone tells me how I can make object appear and disappear in unit action.js could be done quickly.

Well that's the code you need to write actually :) The job is figuring out how to implement that. But if you don't know, you can create a ticket describing the feature, explaining that it's different from the waypoint flags thing, and attaching your art to it. Then you push a contributor into writing the code while the team members are busy with the release :P

  • Like 1
Link to comment
Share on other sites

5 hours ago, Itms said:

Personally I'd rather have a move order visual indicator as you proposed at the beginning of the thread than waypoint flags. It looks cleaner to me (and it would certainly be easier to implement, as the pathfinder or interpolation wouldn't be involved in any way).

Sure, it's easier to implement, but imho waypoints for units are also an important feature, especially for queued orders.

Link to comment
Share on other sites

4 hours ago, Imarok said:

Sure, it's easier to implement, but imho waypoints for units are also an important feature, especially for queued orders.

Surely nice to have. Usefulness could be questionable if one considers all the lines crossing all over if you give more queued orders for multiple units|groups. ;)

6 hours ago, stanislas69 said:

@Itms If someone tells me how I can make object appear and disappear in unit action.js could be done quickly.

Stan, you are in the GUI, this means you have to use GuiInterface to interact with the simulation (if you want to add a simulation entity). There are other graphics only ways of course but I'm of no help as I am overwhelmed with thousands of code issues myself. That's the thing with virtual world - it adds to the real world issues. haha. Which is why I wish to reward all those altruistic open source contributors.

Link to comment
Share on other sites

OK. IMO duplicate waypoint (rally point) XML. Allows to create variants as needed e.g. when interacting with the mouse with walls or if supplement info like context (e.g. rotating exclamation|question mark 3D model should be shown [as prop to be explicit as we both like :)]).

This then'd only be a matter of selecting the correct variant using a GuiInterface call.

It may be wise to allow more such graphical-only (unselectable, non-interactive) quasi entities per player at the same time for the case that the animation has not finished playing all frames when the knightly player already clicked other units to its target positions|interaction points.
Else one could simply add one such entity per faction,player with position set to -1 by default and on demand moving it to the correct place, showing it via GuiInterface call, selecting the correct variant depending on GUI interaction context. (Maybe my friend to make it easier this single entity approach is a good start?)

Edit: May be even better to always keep the quasi entities ingame, but the non-looping (!) animation's rest position being far below ground level. This way no timeout is required to hide the entity|move out of world. Neither is moving into world required then (saves 2 of 3 engine calls, good for performance). So no show,hide and instead:

  1. Move to cmd.target coordinates.
  2. Select animation which triggers it to play once (making it show and disappear like in your great model and animation, @stanislas69. High quality works. Thanks man!)
Spoiler

If this is overkill, then simply exchange cursor to an animated one on successful click event. Should provide the same desired feedback, i.e. that the click was successful. (But I think the discussion already settled on the 3D model because it does not move with the mouse and prolongs the time the event's target position can be seen - though that's subjective and depends on the animation duration.)

If the purpose were to show that the order was received well, then this is way trickier and it'd no longer be a GUI thing, but directly in the simulation. More complicated because there is no way to ensure the order will really be executed. Should be enough to know the order is queued though.

 

Edited by Radagast.
  • Like 1
Link to comment
Share on other sites

4 hours ago, Radagast. said:

Stan, you are in the GUI, this means you have to use GuiInterface to interact with the simulation (if you want to add a simulation entity). There are other graphics only ways of course but I'm of no help as I am overwhelmed with thousands of code issues myself. That's the thing with virtual world - it adds to the real world issues. haha. Which is why I wish to reward all those altruistic open source contributors.

@stanislas69 Please excuse the wording which sounds little friendly! I am aware of the fact you know GuiInterface as shown in the Diff you took over. My proposal serves to show that no hide,show is required and targets specially the target click thingy as "project leader" now prefers - which is different to waypoint of your https://code.wildfiregames.com/D557.

  • Like 1
Link to comment
Share on other sites

7 hours ago, Radagast. said:

OK. IMO duplicate waypoint (rally point) XML. Allows to create variants as needed e.g. when interacting with the mouse with walls or if supplement info like context (e.g. rotating exclamation|question mark 3D model should be shown [as prop to be explicit as we both like :)]).

This then'd only be a matter of selecting the correct variant using a GuiInterface call.

It may be wise to allow more such graphical-only (unselectable, non-interactive) quasi entities per player at the same time for the case that the animation has not finished playing all frames when the knightly player already clicked other units to its target positions|interaction points.
Else one could simply add one such entity per faction,player with position set to -1 by default and on demand moving it to the correct place, showing it via GuiInterface call, selecting the correct variant depending on GUI interaction context. (Maybe my friend to make it easier this single entity approach is a good start?)

Edit: May be even better to always keep the quasi entities ingame, but the non-looping (!) animation's rest position being far below ground level. This way no timeout is required to hide the entity|move out of world. Neither is moving into world required then (saves 2 of 3 engine calls, good for performance). So no show,hide and instead:

  1. Move to cmd.target coordinates.
  2. Select animation which triggers it to play once (making it show and disappear like in your great model and animation, @stanislas69. High quality works. Thanks man!)
  Hide contents

If this is overkill, then simply exchange cursor to an animated one on successful click event. Should provide the same desired feedback, i.e. that the click was successful. (But I think the discussion already settled on the 3D model because it does not move with the mouse and prolongs the time the event's target position can be seen - though that's subjective and depends on the animation duration.)

If the purpose were to show that the order was received well, then this is way trickier and it'd no longer be a GUI thing, but directly in the simulation. More complicated because there is no way to ensure the order will really be executed. Should be enough to know the order is queued though.

 

Yeah but the issue is the number of entitites that would represent at the end of the game. I'm pretty sure 5000 per person clicks is not a big number for a game.

5 hours ago, Radagast. said:

@stanislas69 Please excuse the wording which sounds little friendly! I am aware of the fact you know GuiInterface as shown in the Diff you took over. My proposal serves to show that no hide,show is required and targets specially the target click thingy as "project leader" now prefers - which is different to waypoint of your https://code.wildfiregames.com/D557.

Different yes, unrelated not so much, If I can do D557 arrow thing should be piece of cake, at least so I hope.

 

Quote

Stan, you are in the GUI, this means you have to use GuiInterface to interact with the simulation (if you want to add a simulation entity). There are other graphics only ways of course but I'm of no help as I am overwhelmed with thousands of code issues myself. That's the thing with virtual world - it adds to the real world issues. haha. Which is why I wish to reward all those altruistic open source contributors.

I just don't know how to get the component manager to add an entity.

10 hours ago, Imarok said:

Sure, it's easier to implement, but imho waypoints for units are also an important feature, especially for queued orders.

Not giving up. Got interpolation working rest is on ticket.

 

 

11 hours ago, Itms said:

Well that's the code you need to write actually :) The job is figuring out how to implement that. But if you don't know, you can create a ticket describing the feature, explaining that it's different from the waypoint flags thing, and attaching your art to it. Then you push a contributor into writing the code while the team members are busy with the release :P

Yeah will do. Well that could be a solution, but the only way I found in the past to get stuff I wanted done was to learn it and do it myself eventually ^^

 

I noticed I get warnings popups when using atlas in debug mode, and AFAICS click selection is still broken in atlas, making it really annoying to select a single unit. Maybe that something that should be fixed in FF ? Or @vladislavbelov may have an idea for this kind of bugs

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...