Mouse - group selection bug - maybe

#1

Quote:I wanted to have another building (Barracks)

Sounds like you caught everything to me--does it work? :)

#2 Yep it does,
My only problems is that when I ran it as a client - hosted game then used another machine to connect, which didn't have the new Barracks code, the client didn't download the new Barracks code, images etc, maybe download from server to client is off for network bandwidth optimisation, something in my todo list
Following on from the new Barracks button -
the only thing I realy need to figure out is that I would rather click on the Build button and get another menu popup with various buildings that I can then click on to place on the map(terrain, mission - you know what I mean), thats dependant upon weather I have enough credits, or certain other variables eg, can't build barracks if I dont have a construction yard (type of thing), then once I have a Barracks I then get a new menu for creating people.

Hopefully I can get this sorted out soon

#3 As a general rule, TGE isn't going to send new script files to clients automatically. You have to put together a distribution process that makes sure any clients have the current executable and added script files.

So, the fact that you didn't get the files isn't something you "missed" in the changes, it's just not part of what TGE does. I know that at least a couple of people are looking at some form of process for this, but it would be outside of TGE itself.

Good luck on how you set things up for your new buildings, will be interesting to see what you come up with!

#4 Chris, sounds like you got the building stuff working.

As for the selection / command problem, we'll try to take a look at it soon and see if it's a bug or what. Thanks for the detailed report.

#5 Josh yep I did - I think,
this is what I did
open
client\script\inputHandler.cs
and in the function GuiRTSTSCtrl::onMouseDownBuilding(%this, %building)
add this simple bit of code - twice

%this.setCommandState("None");

so it looks similer to the code below

function GuiRTSTSCtrl::onMouseDownBuilding(%this, %building)
{
   switch$($CommandMenu::CurrentCommand)
   {
      case "Attack":
         if(%this.selectionIncludesTeam)
            commandToServer('IssueAttack', %building.getGhostID());
	    // add this line below
	    %this.setCommandState("None");
      case "Move":
         if(%this.selectionIncludesTeam)
         {
            %destination = %unit.getPosition();
            commandToServer('IssueMove',
                              getWord(%destination, 0),
                              getWord(%destination, 1),
                              getWord(%destination, 2));
	// and add this line below
	    %this.setCommandState("None");
         }
      case "None":
         if(%this.getSelectionSize())
            %this.selectBuilding(%building);
   }
}

If i'm wrong please don't shoot me, but from a few simple tests it seems to work fine

#6 @Chris: Taking a quick look at your script, what you've done there is basically said "if I have a building selected, and have issued either an Attack or a Move command for that building (or a combined selection group that includes that building), perform that command, but then change the command state to "None" immediately, instead of letting the scripting hooks handle it as appropriate. Since things happen so quickly per tick, I think you are actually doing one "tick's" worth of attack/move with the building, but then immediately cancelling it. (this might not be the exact case since I haven't tested your code directly). This obviously works for you, but it also puts you in the situation where you are (I think) removing the ability to do other things with your buildings besides select (and whatever selecting does to the building).

I've been looking at playing around with what you are doing as well, and what you probably really want to do is to take a look at the CommandMenu gui in playGui.gui, where the start pack implements the buttons you can press to give commands to units, like "hold", "attack", etc. If you search in this file for "CommandMenu::", you'll come across the first button that allows you to give a command, the CM_Move button, which, when clicked, gives the command

CommandMenu::onMoveClick()

that command is implemented at/near the bottom of the file, and as you can see it sets the playGui's CommandState to be correct for whatever button was pushed.

This command state is what appears in the switch statement in the code you have above: $CommandMenu::CurrentCommand, and then handles all the possibilities for the building.

If you mimic the way they did things, by creating new buttons that are specific for building actions, you can give yourself a much wider variety of building options, like "upgrade", "destroy", "unroot" (like the tree buildings in Warcraft 3", etc.

Long story short, your code works fine for what you want, but you may find in the future it limits something that you wanted to do otherwise.

On my todo list is an implementation of doubleClick event hooks so we can catch double as well as single clicks for more RTS style mouse interface stuff.

Hope this helps!

#7 @Stephen: I see what you are saying , and after reading your reply, I did a bit more investigation (if you can call it that)
and the only problem with what I did is to create this problem,
after ordering the selected units to attack the building, you have to re-order them to attack before clicking on the next building.
Apart from that problem it works fine well I can't find any other quirks, and fixes the problem with switching between groups or selecting other units and then commanding them to attack, runaway etc,
maybe the problem is that the input controls are not multi-threaded (getting into an area I'm scared to go ;-) )

As far as clicking on a building to

Quote:like "upgrade", "destroy", "unroot"

,
I found a function in client\scripts\selection.cs
function GuiRTSTSCtrl::selectBuilding(%this, %building)
which is seperate from the (and I believe a clone of the next function function GuiRTSTSCtrl::selectObject(%this,%obj) without the commandMenu stuff)
which will allow to code for the fire of a BuildingCommandMenu
well that was the way I was going to go and then follow on with similar to the CommandMenu::onMoveClick() as you mentioned

#8 Just keep in mind what I talked about is just one way of doing things (along the lines of how GG set up the rest of the examples I admit), nothing stops you from doing it however you want.

Added to that, my own plans for implementing the same thing are still in the very initial stages. If I come up with anything big that needs to be changed in my design I'll let you know!