Page 3 of 6
Re: Gameplay concept : Objective based skirmish
Posted: 15 Jun 2011, 00:02
by sunspot
PicassoCT wrote:Hi, my name is Picasso, and im suffering from inferiority after reading this list.
The Selfhelpgroupchorus: "Hi Picasso"
You are fast. Why not make two mods, after all, you have two weeks.

Hehe don't worry about it , programming experience comes with the years, and after all I'm doing a very very limited and easy mod it seems. The only thing that is still mindboggeling to me is ChilUi and how commands and build options work. Not much documented and the few examples out there ... auch my head, obscurify much would ya :D
btw my vacation doesn't start until the 27th, this was supposed to be my preliminary work studying the engine and asking lots of questions :)
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 08:07
by sunspot
Small WIP update,
I finally succeeded in getting a command in a ChiliUI window , yay me ... K it looks like crap, it's only the move command, and it's more or less hard coded. But at least I have a prototype to go further with. Once I got some decent code and something that looks good , I'm writing a tutorial for future generations, so people don't have to look for 3 days straight how to do this.
btw many thanks to "Licho, KingRaptor, Google Frog" for writing gui_chili_integral_menu.lua. It helped me a lot and was my basic tour guide on how to get it working. It was well documented, k it could still be a bit better, like some explaination on how their cmd data structure works but no complaints other then that.
*begin rant*
Also I came to the conclusion that lua is a very frustrating language with bad error reporting, somethimes I just don't have a clue how stuff can't work, take this for example.
Code: Select all
overrides = {[CMD.MOVE] = { texture = imageDir .. 'Bold/move.png', text= '\255\0\255\0M'}}
Spring.Echo("total elements " .. table.getn(overrides)
this little bit of code always returns 0, how the hell can it return 0 , I just put an element in there at index CMD.MOVE, I'm pretty sure I've put one in there so ... no lua ... bad lua ... there is one element. K I agree I have no idea at what numeral index, haven't really printed out the int value of CMD.MOVE yet but still ! The more frustrating part is that this seems to work in other peoples code... So I must be doing something wrong in the language ... but then agian this is so basic ! *end rant*
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 08:49
by CarRepairer
Don't get mad at lua just because you don't know what you're doing yet. The size of a table is not the total number of elements in it but rather the index n where the table has elements indexed by the continuous sequence of 1 to n. Any element with an index outside this sequence is not counted and you must either keep track of the table yourself or run a pairs() on it and tally the elements. Learn the significance between pairs and ipairs. Also look up the pound sign (#).
Also I can objectively state without hyperbole that lua is the greatest programming language ever invented.
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 09:03
by sunspot
CarRepairer wrote:Don't get mad at lua just because you don't know what you're doing yet. The size of a table is not the total number of elements in it but rather the index n where the table has elements indexed by the continuous sequence of 1 to n. Any element with an index outside this sequence is not counted and you must either keep track of the table yourself or run a pairs() on it and tally the elements. Learn the significance between pairs and ipairs. Also look up the pound sign (#).
Also I can objectively state without hyperbole that lua is the greatest programming language ever invented.
Well thnx for the info about table.getn() I indeed didn't know that was his intended behavoiur. I'm still out on judging lua completly, but compared with groovy (other modern script language) it has some strange behaviours that I find mindboggeling it works that way. I've tried some stuff with the # operator ... it works ... but feels weird using it instead of my trusty foreach approach. Sofar I always used ipairs because having the index is handy, but I indeed haven't looked up yet what the significant difference is between ipairs and pairs
hmmm according to
http://trac.caspring.org/wiki/LuaPerformance
ipair or pair should never be used , since it's a performance eater, same goes for table.insert ... I'll have some rewriting to do once I get home

Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 11:34
by PicassoCT
if the game is slow, and the lagspike shows, then rewrites your only friend.
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 13:31
by sunspot
PicassoCT wrote:if the game is slow, and the lagspike shows, then rewrites your only friend.
Well I refactored my code during my lunchbreak at work, it's all to the guidelines of that performance page. It's better to think of performance in advance then after you've written 500k lines of code !
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 13:40
by FLOZi
The way you write is often more important than what syntax you use.
e.g. with your game ending code, you loop over all teams every time the check is run, when you could just check each time you give a team additional tickets if they have reached the winning cap.
Hence the disclaimer when I ported that CA wiki article to Spring Wiki:
http://springrts.com/wiki/Lua_Performan ... iderations
I've been subject to this myself, when TFC pointed out that two S44 gadgets, the ammo gadgets, were especially slow I rewrote the loops with counters instead of pairs and implemented a load sharing system so that each teams calculations were performed on different frames... Only to realise at the end of all this that when the gadget looked for an ammo supplier it found
*the closest* rather than
*any that is within range*. There was a far greater improvement in performance from a simple algorithmic change than scores of rewriting and clever schemes.
(And as a 1st class BSc Comp Sci I really should have seen it earlier) 
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 13:53
by sunspot
FLOZi wrote:e.g. with your game ending code, you loop over all teams every time the check is run, when you could just check each time you give a team additional tickets if they have reached the winning cap.
I'm not yet sure on my game ending decission cause what happens if you got a 4 team game and team 2 and 4 reach the point cap at the same frame check. This is perfectly possible, who would win then ? I would say both of them. And if all teams own a structure that means on that same frame they all get a point, so I'll have to send all teams to the win check method anyhow. I could send an array with only teams that have gotten a point as you said.
FLOZi wrote:
(And as a 1st class BSc Comp Sci I really should have seen it earlier) 
Yes you should have

Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 16:06
by CarRepairer
sunspot wrote:CarRepairer wrote:Don't get mad at lua just because you don't know what you're doing yet. The size of a table is not the total number of elements in it but rather the index n where the table has elements indexed by the continuous sequence of 1 to n. Any element with an index outside this sequence is not counted and you must either keep track of the table yourself or run a pairs() on it and tally the elements. Learn the significance between pairs and ipairs. Also look up the pound sign (#).
Also I can objectively state without hyperbole that lua is the greatest programming language ever invented.
Well thnx for the info about table.getn() I indeed didn't know that was his intended behavoiur. I'm still out on judging lua completly, but compared with groovy (other modern script language) it has some strange behaviours that I find mindboggeling it works that way. I've tried some stuff with the # operator ... it works ... but feels weird using it instead of my trusty foreach approach. Sofar I always used ipairs because having the index is handy, but I indeed haven't looked up yet what the significant difference is between ipairs and pairs
hmmm according to
http://trac.caspring.org/wiki/LuaPerformance
ipair or pair should never be used , since it's a performance eater, same goes for table.insert ... I'll have some rewriting to do once I get home

Make it work first, optimize later. Lua is easy to work with. You'll find that you only need to be concerned with performance when you're working in large loops and oft-occuring game events. That widget Integral menu (to which I've contributed some code as well) is not a performance hog, except maybe the part where it indicates factory queues.
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 17:10
by Google_Frog
sunspot wrote:ipair or pair should never be used , since it's a performance eater, same goes for table.insert ... I'll have some rewriting to do once I get home

The "no-pairs challenge" can become complicated, I would not recommend it if you are unfamiliar with the language. The difficulty mostly occurs when you have a list of units you want to iterate over as well as index by unitID. In this situation you need 2 tables with indexes to each other and any little mistake in updating these indexes will make the whole thing crash eventually but not necessarily at the time the bug occurred.
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 18:47
by sunspot
CarRepairer wrote:That widget Integral menu (to which I've contributed some code as well)
You where not in the authors otherwhise I would have thanked you as well
Google_Frog wrote:The "no-pairs challenge" can become complicated, I would not recommend it if you are unfamiliar with the language. The difficulty mostly occurs when you have a list of units you want to iterate over as well as index by unitID. In this situation you need 2 tables with indexes to each other and any little mistake in updating these indexes will make the whole thing crash eventually but not necessarily at the time the bug occurred.
K gotcha optimize but be very carefull. Is there some kind of general debug snippet people use for debugging arrays ? In php you have print_r, in java I just look at the toString(). Do I just have to loop over everything ?
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 19:00
by smoth
Spring.Echo(string)
+ for concatenate but you can use , instead which will insulate from null errors
Treat it like cout>>
This is just output
for the loop do a for each in pairs to itterate the table there are many examples in lua
P.S since you don't know yet, most of the time I post from my phone so forgive the brief reply
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 21:20
by sunspot
smoth wrote:Spring.Echo(string)
P.S since you don't know yet, most of the time I post from my phone so forgive the brief reply
hehe np smoth , the effort is appreciated but, I knew about regular Echo outputting, thing is for tables it just prints table, or it seems in most cases just nil
Other then that here is my progress
edit: forget my earlier code snippet, was just a typo !
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 21:32
by smoth
Your values that are returning table can be checked go if (type table). Kinda thing If it is do another pairs walk through(if it goes deeper do a recursive walk through your table...
Cannot help much beyond that right now
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 21:37
by sunspot
Thnx smoth I'll go the recursive way then, hoped to avoid that for performance ofcourse. I'll get there ... just gonna take me a while to understand those lua finepoints. Keep in mind I started with lua well last friday ...
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 21:50
by smoth
To be honest I don't expect you to complete this in 2 weeks so don't feel pressured. It'd be cool if I'm wrong though :)
Don't worry too much about efficiency, it isn't THAT bad
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 22:09
by PicassoCT
This is will be a new Thumbscrew in our arsenal of nub torturing.
"But sunspot had his game completed after two weeks, why isnt yours?"
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 22:29
by sunspot
PicassoCT wrote:This is will be a new Thumbscrew in our arsenal of nub torturing.
"But sunspot had his game completed after two weeks, why isnt yours?"
lol, you drama queen :)
first of all I'm raping cavedog's IP by using their units and animations, second this is not my first endeavour in learning something new and third I have to debug and read other peoples code all frigging day long. I'm used to figuring things out :). However I couldn't do it without all you guys help. The fine points of the engine and lua would have taken me quite a bit longer without your input
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 23:01
by CarRepairer
Look in this file for a function called to_string. I got it from the web somewhere and modified it slightly. It will output a table's contents.
http://code.google.com/p/zero-k/source/ ... icmenu.lua#
Re: Gameplay concept : Objective based skirmish
Posted: 16 Jun 2011, 23:26
by sunspot
Nice thnx CarRepairer, that is gonna help me out. Anyhow I'm calling it for today. My progress has been great on UI side today. I've finally have all the commands of one selected unit in a chiliUi window. I'm stuck on something else now though, the state change commands should update their text once pressed. I've tried a few approaches but they all failed. This was my last approach.
Code: Select all
local function ClickFunc(button)
local _,_,left,_,right = Spring.GetMouseState()
local alt,ctrl,meta,shift = Spring.GetModKeyState()
local index = Spring.GetCmdDescIndex(button.cmdid)
if (left) then
Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift)
end
if (right) then
Spring.SetActiveCommand(index,3,left,right,alt,ctrl,meta,shift)
end
local unit = button.unit
local index = Spring.FindUnitCmdDesc(unit, button.cmdid)
local unitcommands = Spring.GetUnitCmdDescs(unit)
local cmd = unitcommands[index]
Spring.Echo("unit command is now at ", cmd.params[1])
local buttontext = findButtonText(cmd)
if(buttontext ~= button.caption)then
button.caption = buttontext
local parent = button.parent
parent:RemoveChild(button)
parent:AddChild(button)
end
end
as you can see I use this function as the actionPerformed for my buttons, and I've put my origin unit on the button ... but thats a bad idea, certainly when more units will be selected. Then I activated the pressed command with SetActiveCommand and I tried refreshing the text by getting the commands from the unit again and then check if the buttontext would be different from the existing caption. But for some reason the first time I press the button the text is the same. However every next try , the text is not the same and it does chance, however the unit is then in the wrong state since the first click did execute his command but not the textchange. It's a bitch to debug. I'm thinking it takes some time for SetActiveCommand to kick in but then again ... why do the cosecutive tries DO WORK ? So in short
todo
- figure out what to do with multiple units selected
- find a way to make the buttons update right , especially state commands