K I believe I know what I was doing wrong

Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift)

doesn't execute a command or so , it just says , the next active Command is said command. But I don't get it then, who actually executes the command ? I suppose in the case of move and attack it's an onMouseClick() or onMouseRelease(), but what about state commands like Cloak ? Who executes those commands , and how do I intercept the call there ? Any info you can give me on this ?

Bleh I don''t get it agian this was my latest attempt

K I believe I know what I was doing wrong

Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift)

doesn't execute a command or so , it just says , the next active Command is said command. But I don't get it then, who actually executes the command ? I suppose in the case of move and attack it's an onMouseClick() or onMouseRelease(), but what about state commands like Cloak ? Who executes those commands , and how do I intercept the call there ? Any info you can give me on this ?

Bleh I don''t get it agian this was my latest attempt



The idea was to use the unitCmdDone method to find the new text of the cmd and then put it on the chilibutton. However it failed miserably this is my output of the echo statements



in one frame change my active command is bye bye , oh and the unit command activated is said to be 70 ... WTF I asked for command 95 !

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.

Well my problem is the following. I have put all commands of a selection of units in a chili window as chili buttons. Commands like attack, stop, move work as they should. Then you got the commands like cloak and fire state. If I press those buttons, the commands gets executed as it should, but the button doesn't change name. It should go from uncloacked to cloaked for instance. I understand this is the programmers responsability to let this happen. But I don't get how to do it in the spring lua structure.

In java I would have done something like this


What happens is that , when I press this button the eventthread gets an event, it finds this actionlistener, triggers the actionperformed and changes the text on the button redraws the button. From what I understand I'll have to do this all manually in Lua. So far I understand a few things

- you create a ChiliUi control and with OnMouseDown = {ClickFunc} you specify the function ClickFunc needs to be triggered (in analogy with java actionperformed).
- 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)
- Some post action commands run to clean stuff up , I found this one widget:UnitCmdDone(unitID, unitDefID, unitTeam, cmdID, cmdTag)

Well in the unitCmdDone I'm trying to find out what the new text of my button will be, by fetching the last active command and getting it's desc, update the caption of the button, redraw the button (aka take from window , put back on window). But it seems unitCmdDone gets another command , then the command I asked to execute.

My question is now why is that a different command, and am I right to try and do my text change at this location ?

==============

Well I got a sollution now but I'm afraid I picked a rather expensive one



each time a command changes it redraws my entire command panel... it works , but ... how often will widget:CommandsChanged be called ? I allready noticed once I deselect a unit , it gets called twice for some reason ...

ok little progress update on this WIP

http://www.gravegast.be/~sunspot/temp/test.png

as you can see the ui is comming along. There are a few things I still like to do, a status bar below , that shows unit info when you hover over a unit

Things done
- commands seperated in 3 windows
- build commands became image buttons
- score and unit limit now in teamcolour
- implemented chili chat but with a twist, you open the chat window with enter and it stays unless you press the X button in the top right. I made this as an option so the old functionality still works if you want it to. Config is in the script though not a config file as it should be
- implemented chili resource bars but I removed energy since I don't plan on using energy

Things to do
- balance units
- implement a real map with a config file for my gametype
- find a name for the game
- implement a statusbar for hovering over units

Little WIP update,

Accomplished
- Implemented a status bar when hovering over units showing hp, and weapons damage, range
- Wrote 2 tutorials for chili

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

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.

Well seems we had the same idea. In the long run , I'de like to have aircraft factories as objectives to give air units, or some kind of first aid station that will give repair bots. Those units would give another advantages to the player at the cost of more unit limit. But that is still in concept phase. My first priority is getting my 3 types of units working. I'll take a look at the code for your flag capturing to see if I missed a use case. But to be hounest I'm wrapping up my code work atm. It seems to be working now and is ready to be tested. However I need to find a fitting map to implement my system on. I was thinking some kind of "tug of war" type , with the objectives in a more or less straight line towards eachother. Dunno I'll see whata I'll do with it

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.

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!)

For the maps, you can probally find something suitable on http://springfiles.com/spring/spring-maps
There are literally tons of maps, most not really well known, so they would still appear "fresh" and unique.

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.

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.



Well tbh when I first started this I had a mechwarrior 4 theme in mind. But someone is allready doing a BT style game (SpikedHelmet) so that would not be that nice to do. Then again I'm no artist, let alone modeller. K I might still be able to get away with the modelling, I modelled some mean looking "shadow cat" (untextured) in Rhino back when I was still making units for TA. So if I'm to use different models I would have to find an above average modeller (wouldn't settle for less hehehe) and texturer. For the first testing TA models won't be that bad.

The idea is that you can play it with as much allied teams as the engine allows and as many players as well. Each player is limited to a unit limit of 20 with some units costing more then one unit limit (well one for now the artillery unit). Each team will have a counter that needs to reach x (have 500 in mind). If the engine allows it, drop in and drop out functionality would be nice. It's real intended purpose is to have at least 2 teams of 5-8 players fighting eachother. But I'm not dellusional , I know it will be hard to get even 4 players playing it. Unless I get really really lucky and people will enjoy this type of game a lot :)

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.

Thanks for this one, I'll implemented it in the next update. I've had a talk with JK about caching the buttons. If I understood him correctly , it seemed it wasn't to big a deal , to let the control instantiate itself each time. My first idea was to make some kind of Cache class that would hold several caches by id/name that lives somewhere globally and could be called in every script. But that might be a bit overkill. So caching the buttons on script level might not be a bad idea.

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.

I see so whats for me a one frame update now, in a real game can be several frames later , untill all players have recieved the message and ack they are ready to update. But this design pattern Niobium just wrote , will solve that problem won't it ?

Yes.

(:CommandsChanged fires when commands change, not when they are sent, so latency etc isn't an issue. The problem is that :CommandsChanged is fired just before spring decides to update the command descriptions, so the best you can do is flag it, then check the flag on the next callin into the widget, for what you're doing :DrawScreen works fine)

Small WIP update, I roughly implemented a real size map, pathway_v2. Next up was balancing the units.

But tbh I have no clue what I'm doing with it. How do I decide how much armor I will give it, how does one value of damage relate to one real ingame value of damage. How big are ranges actually etc... So it' not really that easy.

I realised there is still one case I have to prevent. The objective structures can be captured and then self-destructed... this should be prevented somehow. After that I believe I can wrap up the big programming and just do tweaks for bugs.

Next I'll probably gonna need some testing. I'm also looking at the challenge of writing an AI that can play the gametype ... and tbh that seems to be the hardest thing to do of all.

ok well carrying on ... 2 more days of work and then 2 weeks vacation ... can't wait

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

Idd , there is , thnx that saves me some code :)

You could deactivate selfdestruction? Its just a tag..

Oh, and game names... make something with A at the start so its top of the list

you probally also want to disallow transfering ownership of the captured unit: (h key ingame, if you didnt know)