Spring RTS Engine

Posted: **16 Sep 2010, 14:00**

the wiki says:

wiki wrote: ( number teamID ) ->
nil | number teamID, (bug in pre 0.82)
number skirmishAIID,
string name,
number hostingPlayerID,
string shortName, (synced => "SYNCED_NOSHORTNAME"; non-local => "UNKNOWN")
string version, (synced => "SYNCED_NOVERSION"; non-local => "UNKNOWN")
table options (synced & non-local => empty-table)

but when I do:

Code: Select all

local teamID, skirmishAIID, name, hostingPlayerID, shortName, version = Spring.GetAIInfo(i)

skirmishAIID is not a number but instead the name of the AI ie "RAI" or "E323AI"
so it should say "string skirmishAILibaryName" or something?

also why do the return values have this strange formating in the wiki and what does the "nil |" mean? "nil is null/nothing/not defined" but why is that returned or whatever?

Posted: **16 Sep 2010, 14:34**

The arguments returned by GetAIInfo changed at least three times:

-- For 0.80.5.2:
local _,name,hostingPlayerID,_,shortName = Spring.GetAIInfo(teamID)

-- For 0.81.1.3:
local teamID,skirmishAIID,name,hostingPlayerID,shortName,version,options = GetAIInfo(teamID)

-- For 0.82.5:
local skirmishAIID,name,hostingPlayerID,shortName,version,options = GetAIInfo(teamID)

Posted: **16 Sep 2010, 14:37**

ah ok.
when new return values or arguments are added, why are they not just added at the back? wouldnt that be better and break less stuff each time.

Posted: **16 Sep 2010, 14:43**

the code:
http://github.com/spring/spring/blob/ma ... .cpp#L1380

the teamId is not returned, so if you remove that from the list of return values, it should be correct then.
now.. i do not know if we should add that as nil again, or keep it as it is.
i would guess the second (plus adjusting the wiki), but widget makers/mod owners will know better how many widgets use this as it works now, and how many as it is described in the wiki. which is what matters, i guess.

Posted: **16 Sep 2010, 14:48**

In the last change, no argument was added, but the first argument was removed. jK found it ugly to return a teamID that is already know. jK thought it would be much pretty to not return that extra useless info. That it would break every widget and gadget out there is not a problem at all for him, after all "it's just a one line fix in your Lua code!", and also "hey it's your fault you should have read the changelog!", not to mention "already updated in CA".

i do not know if we should add that as nil again

Oh yes break it a fifth time for the lulz! Make sure to not tell anyone though. We modders sooo enjoy to discover undocumented interface changes every release! It's like an easter egg hunt! The joy of surprise!

What fun would it be if a mod made yesterday still worked today? Modders who don't like spending half of their modding time investigating and workarounding all the freshly added new Spring bugs are just lazy and ungrateful.

Posted: **16 Sep 2010, 15:30**

Oh yes break it a fifth time for the lulz!

Damn, i do not envy mod devs.

Posted: **16 Sep 2010, 15:45**

so you want to tell me, all the mod devs did actualize to the new way (without the teamId returned) and none of them was able to fix the wiki?

i take your post as a confirmation that the majority of mods/gadgets use the new syntax already, and so we would not adjust engine code, but fix the wiki. please do that.

Posted: **16 Sep 2010, 18:24**

Honestly, I have no idea. I personnaly fixed GetAIInfo calls in GRTS, EvoRTS, and KP, but I did not check every mod.

Edited the wiki: http://springrts.com/wiki/Lua_SyncedRea ... sts.2FInfo

adjust engine code

jK purposefully, knowingly, removed the teamID argument. I believe he shouldn't have in the first place, but now it's done, commited, released, used. And then you're talking about adding it again! It drives me mad.

When making an interface, what's most important is not that it returns the Right Thing.
It's not even that it returns what the doc says.
What really matters is that it always returns the same thing!

Posted: **16 Sep 2010, 19:45**

you are acting like a teen girl or something.
guess why i asked for what i asked? cause if you are the only one that adjusted, changing it back would be the right thing to do, to keep the interface the same.
go shopping or something!

Posted: **16 Sep 2010, 21:51**

zwzsg wrote:In the last change, no argument was added, but the first argument was removed. jK found it ugly to return a teamID that is already know. jK thought it would be much pretty to not return that extra useless info. That it would break every widget and gadget out there is not a problem at all for him, after all "it's just a one line fix in your Lua code!", and also "hey it's your fault you should have read the changelog!", not to mention "already updated in CA".

Could you please stop to cast misinformations?
You know very well that it was a BUG and I FIXED a BUG!
And that you don't read any informations the devs publish is YOUR problem!

number teamID, (bug in pre 0.82)

Sorry, but that documented the interface change very well imo ...
(and yeah, it was red in the wiki, too)

Posted: **16 Sep 2010, 21:55**

knorke wrote:also why do the return values have this strange formating in the wiki and what does the "nil |" mean? "nil is null/nothing/not defined" but why is that returned or whatever?

The "|" is a standard notation for "either", so it returns either the value on the left or the right. So "nil |" mean that it is possible that the function doesn't return anything (e.g. on incorrect teamID).
So depending on the function you may need to check the returned values before using them (nils cause lua-`crashes` when they are used in arithmetic functions).

Posted: **17 Sep 2010, 14:14**

hoijui wrote:you are acting like a teen girl or something.
guess why i asked for what i asked? cause if you are the only one that adjusted, changing it back would be the right thing to do, to keep the interface the same.
go shopping or something!

Please don't it is difficult enough to chase down my own bugs let alone all the lua changes. It is exactly this sort of change that prompted my mod/deg communication thread. These things do cost us a lot of time.

For the record, I read jk's note in the wiki and found it ambiguous and thought it meant he fixed it. Q more clear entry would be something like " was not supposed to be there fixed by removal " instead as it was when I asked for clarification I was merely told to go read the wiki. Not good either, as the wiki was where I was confused by.

Posted: **17 Sep 2010, 14:24**

Posting from my iPhone and the browser is weird so I have to double post.

Anyway, fixing things is good, but these releases broke most mods and at the same time pathing and some lua changes which were ambiguous in the future please consider something small detailing the fix rather than just that it was fixed ESP in the case of parameter removal. At least 3 of us were confounded by it but when we asked were given terse response and left confused. This does cause us to lose a lot of time in already tedious and time consuming drudge work, like 90% of our games are not creative but instead mostly turning screws if you follow the analogy.

Fuckinh iPhone is being weird again, will have to wait and post later I hope I am helping with this communication between you guys

Posted: **17 Sep 2010, 15:22**

ok so its correct in the wiki now thanks :)
bla it would be cool if someone changes or adds something that this person could also update the wiki blabla yesiknowitsannoyingboringwork
for example i was looking for a LuaCallin for Added Mapmarkers but found nothing in wiki. Then I heard about it in the lobby and appearently it exits for quite a while.
So I added it (MapDrawCmd()) but it would probally be better if the dev would add those because they know best

jk wrote:So "nil |" mean that it is possible that the function doesn't return anything (e.g. on incorrect teamID).

ok ty. maybe "on error: nil" would be more clear.

Posted: **17 Sep 2010, 15:55**

No, the confusing thing is that it would only return the nil | teamID in pre 0.82.
In post 0.82 it would return neither. Well, actually, it probably still return a nil for skirmishAIID when the teamID is bad. But err, I would return nil | skirmishAIID, not nil | teamID. Or better said, it pre 0.82 it would return teamID, where (returned) teamID is nil if (provided) teamID is right wrong. And in post 0.82 it would return skirmishAIID, where skirmishAIID is nil if teamID is wrong. But then all the other returned value would be nil as well, woudln't they? And why the wiki would only mention it for the first? Or is the nil | a, b, c intended to be understood as nil | (a, b, c) instead of (nil | a), b, c ?

What I mean is:

Pre 0.82, Bad TeamID provided: return nil
Pre 0.82, Correct TeamID provided: return teamID, skirmishAIID, name, hostingPlayerID, shortName, version, options
Post 0.82, Bad TeamID provided: return nil
Post 0.82, Correct TeamID provided: return skirmishAIID, name, hostingPlayerID, shortName, version, options

The wiki was ambigious because it made you think the new version returned nil where the old returned teamID.

A better explanation would have been:

Code: Select all

Spring.GetAIInfo
( number teamID ) ->
      nil | (if bad teamID)
      [number teamID,] (bug in pre 0.82)
      number skirmishAIID,
      string name,
      number hostingPlayerID,
      string shortName, (synced => "SYNCED_NOSHORTNAME"; non-local => "UNKNOWN")
      string version, (synced => "SYNCED_NOVERSION"; non-local => "UNKNOWN")
      table options (synced & non-local => empty-table)

Smoth wrote:fixing things is good

I disagree: Fixing things is not good when it does not fix anything, does not do any good, doesn't help with anything, and break interfaces.

The extra teamID harmed no one and costed nothing. Its removal harmed mods, harmed widgets, and cost Lua coders lots of time, confusion and pain.

Hey I gotta run to the mall, checking clothes and stuff, feel like tagging along Smoth?

Posted: **17 Sep 2010, 17:57**

bth i would remove the | thing and just write "on error returns nil" or "returns nil for unvalid teamID" etc
many noobs just slowly learn lua and its a bit easier to read.

Posted: **18 Sep 2010, 14:07**

Better redirect newbies to http://en.wikipedia.org/wiki/Extended_B ... ôNaur_Form and continue using well known notation forms.

PS. I found a bug in forum URL parser. See above!

Posted: **18 Sep 2010, 16:52**

shoe shopping? I'd love to Z!

Spring RTS Engine

GetAIInfo

GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo

Re: GetAIInfo