Spring RTS Engine

Google_Frog wrote:Spring.SetActiveCommand sets the command on the mouse cursor iirc.

I think what you want is Spring.GetOrderToUnit(unitID, cmdID, params, opts). This executes any command.

Although I don't quite understand the question.

JButton button = new JButton("uncloacked")
button.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
				textField.setText("cloaked");				
			}});

function drawPanel(unitSelection)
	RemoveChildren(window0)
	if (#unitSelection ~= 0)then
		local commands = findUniqueCommandsFromSelection(unitSelection)
		table.sort(commands,function(x,y) return x.action < y.action end)
		local rowcount = 1
		local step = 1
		for cmdid, cmd in pairs(commands) do
			rowcount = createMyButton(window0, commands[cmdid], step, rowcount) 
			step = step + 1
		end
	end
end

function widget:CommandsChanged()
	Spring.Echo("commandChanged called")
	local selection = spGetSelectedUnits()
	drawPanel(selection)
end

SpikedHelmet wrote:This is similar in concept to BT I am working on, in that it is based on multiple CTF with ticket drain to determine winner, no base mechanics (we use a single permanent indestructible building), revolving around tactical play and using various forms of "special bonus features" for flag capture points (some have guns, some unlock units, some unlock abilities etc).

Check out Battletech Legacy subforum in one of the feature threads and you can see if there's anything you'd like to use.

Sharing is, after all, caring.

- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)

sunspot wrote:Things to do
- balance units
- implement a real map with a config file
- find a name for the game

Google_Frog wrote:

- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)

Are you sure this step works for state toggle commands?

Aside from that why do you need to use unitCommandDone? You should know what the new state of the button should be when the button is pressed.

knorke wrote:Are you going to use the TA unit models or make/get new ones? It would seem like a waste to use TA models after all the custom stuff you did.
If you chose a theme there it would help also with finding a name. (do insects fighting over picknick food!)

If you want your game to be played (and not just a techdemo) it might also be helpfull to make sure that it can be played with odd player numbers in FFA fashion. Realisticly, players will mostly be BA players who just check out new stuff between matches. (at least for start. maybe your game gets lolfamous, who knows)
So if ie 3 players can nicely play 1v1v1 instead of having to wait for a fourth player that helps to start games quicker.

sunspot wrote:

Google_Frog wrote:

- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)

Are you sure this step works for state toggle commands?

Aside from that why do you need to use unitCommandDone? You should know what the new state of the button should be when the button is pressed.

I've tested it extensivly with state commands , cause those where the once giving me headaches. It does work , but indeed I would have expected to know what the next state was after pressing the button. But if I query the new state of the cmd at the location of pressing the button, the state didn't change. Maybe I was doing something wrong or some other voodoo was going on. I noticed that on the next frame after the setActiveCommand was over, the state was actually different. I've tried several approaches, but in the end calling CommandsChanged seemed the better sollution to me. There is one thing I don't like though, you trigger that method twice after issuing a command. So it's certainly not perfect ! If you see an improvement here I'm all ears. I've spent about a day or two on this problem.

local updateRequired = true

function widget:CommandsChanged()
    updateRequired = true
end

function widget:DrawScreen()
    if updateRequired then
        updateRequired = false
        ... Update buttons etc ...
    end
    ... Normal :DrawScreen code ...
end

Niobium wrote:

Code: Select all

local updateRequired = true

function widget:CommandsChanged()
    updateRequired = true
end

function widget:DrawScreen()
    if updateRequired then
        updateRequired = false
        ... Update buttons etc ...
    end
    ... Normal :DrawScreen code ...
end

This is the pattern to use, especially for when commands are changing many times in a single drawframe (could be many commands, could be low FPS). Note that this will fix your state problems, and there's no need for any additional command related callins. Also you should be caching buttons where possible, i.e. the build unit buttons which never change.

Google_Frog wrote:Be aware that assuming the state of a command will change one frame after it is toggled will not work due to the way multiplayer is synchronised. The gamestate is synchronised by computers sending all commands to each other and executing them within the same frame. This means the commands you give to your units cannot be applied instantly even locally. So the old command state is still active in the frame which you give the change state command and the state will only change a frame later if you have no latency which makes things that depend on fast command changing poor solutions for real games.

sunspot wrote:But this design pattern Niobium just wrote , will solve that problem won't it ?

smoth wrote:Check the wiki docu on unit tag I think we have a way to disable that on a per unit basis