A bunch of small Q's about widget-development for anybody who might have tips. Sorry for the length. 1) Are there any tools beyond notepad++ and luaui reload I should know about? Any performance profiler or interactive console for run-time inspection or anything? 2) This is a player-list-ish widget (sufficiently different that it's not redundant with the existing ones), I'm trying to cover the bases - anybody got a working replay involving CommShare I could use to test that it supports commshare? Also, I'm confused about the existing PlayerList logic - how they know to call the player "noname". The behavior makes little sense. player and spGetPlayerInfo(player) or 'noname' where [player] is the playerID from GetTeamInfo (that is, the "leader" of the team). When I get the player list from Spring.GetPlayerList my "playerID" passes that "player and" test and so spGetPlayerInfo returns "UnnamedPlayer". Does GetTeamInfo fail to return a "leader" when you're launching from Spring.exe? 3) How do I tell the difference between a mobile and a building? isImmobile is not supported under 91, I think. 4) Is there a way to alpha out a whole Chili window and not just its background? Or do I have to apply alpha-updates to every GUI element within the window?
+0 / -0
|
 (xckd #138)I'm sorry, i had to.
+10 / -0
|
1) There's the 'widget profiler', which I'm sure zk has. If not, it should be easy enough to find. Besides luaui reload I would just toggle widget on/off. 2) ASAIK, Commshare should work with GetTeamInfo() since it's just multiple players on 1 team. (team is commander, allyteam is group of commanders) UnnamedPlayer is just what spring.exe calls you when you start game. To check maybe try use springlobby or weblobby to start single player (they should use actual name). So basically it sounds like you got it right. 3) quick search got this but it might be out of date http://springrts.com/phpbb/viewtopic.php?f=23&t=22849&view=next4) If I'm understanding you correctly, ASAIK you need to apply alpha to each element. You could always do something like for i = 1, #control.children do control.children[i]:SetColor(1,1,1,0.5) -- don't quote me on this end It might just be best to pm JK about that or ask in moddev and in case you haven't came across this http://gajop.github.io/chiliui/
+0 / -0
|
omg, yes, that widget API is exactly what I was looking for. Thanks! Anyhow, the UnnamedPlayer problem was just that the logic that the existing PlayerList widgets use to name the player "noname" is... weird. Only seems to occur when you use the "leader" from GetTeamInfo, not when you use the GetPlayerList entries. It's not a big deal, it's just inconsistent - the core ZK widgets use "noname", while my widget uses "unnamedplayer". I could obviously just check for the word "unnamedplayer" and replace it with "noname" but I'd rather replicate their logic if possible. And yes, I wanted to list the individual members of a CommShare team, so I'm using GetPlayerList from the teamID - GetTeamInfo only lists the "primary" player of a commshare-group. That's why I wanted to find a replay with a CommShare in effect - so I could ensure that my widget looks good in commshare scenarios.
+0 / -0
|
1) For testing: http://springrts.com/wiki/TestingYourGameNot just Lua but general. (add more if you want) 3) Basically must find something usefull in http://springrts.com/wiki/Lua_UnitDefsBut some traps, for example mods can have units that are "technically mobile" but have zero speed and so from player's view are buildings. (nano turrets being the tradionell example) Or even stranger things like units that get "immobilized" with Lua (movectrl) etc. It depends a bit on which engine version and which mod... In the linked thread it uses .type but that is deprecated at least in 96.0 (maybe earlier)
+0 / -0
|
Okay gotcha, I'm dealing with the same thing for my end graph widget. I've put it off for the same reason of never actually coming across a comshare game, or more exactly not taking the time to find one for testing. Still, I don't see any reason the way you're doing it shouldn't work. Hmm, that is wierd about the 'noname'. I do know on mine that when testing with spring.exe it creates a start script and 'unnamedplayer' is the name you get. quote:
ishost=1;
mapname=Eye_Of_Horus_v2;
myplayername=UnnamedPlayer;
onlylocal=1;
|
Now that I think about it if a team dies it no longer has a 'leader' so GetTeamInfo() doesn't return a legit id for playerInfo and thats when you get 'noname' maybe? While playerList always returns a correct playerID which must have the name 'UnnamePlayer'.
+0 / -0
|
Oh, that's it! I was testing with spec mode, and my widget doesn't update the names over time - it just was fetching them at start-up. So when I hover over my old pre-spec units, I see "noname" in the tooltip widget, while my new widget still said "unnamedplayer" because it had cached the player names. Oh, what a silly bunt. Thanks, the strange player-name behavior makes sense now. Obviously my widget needs to occasionally re-fetch the player-names.
+0 / -0
|
I also recently learned to get names after widget:GameStart() instead of widget:Initialize(). That might even fix you're problem, but if you do that it helps to do something like quote:
function widget:Initialize()
Chili = WG.Chili
if Spring.GetGameFrame() < 30 then
return -- not started, wait for callin
end
getTeamInfo()
end
function widget:GameStart()
getTeamInfo()
end
|
then it won't get names until after the game starts (otherwise I think it fails) but will also get them on /luaui reload
+0 / -0
|
quote:
Obviously my widget needs to occasionally re-fetch the player-names. |
PlayerChanged callin: http://springrts.com/wiki/LuaCallinReturnIf you are unsure where the "UnnamedPlayer" comes from you can change it: http://springrts.com/wiki/Springsettings.cfg#name
+0 / -0
|
I don't see the string "noname" in the Advanced, Crude, or Deluxe player list widgets. I think if you're seeing "noname" it's because that's what the engine provides under certain circumstances. As I vaguely recall from my efforts to make Deluxe handle names more elegantly than Crude, this mainly becomes an issue when players leave the game for some reason. Crude would show a blank name, or maybe sometimes "noname" (I think? maybe?). Deluxe tries to remember what each players' name was even after the engine stops saying who they were. This was annoying to write; the logic was convoluted and difficult to divine through testing. There's a good chance that my code is either wrong or more complicated than necessary (or both). "noname" shows up in the unit tooltip as the owning player for any unit that is owned by a player that isn't there any more. But that's a different widget. Remember that players can be players at the start of the game but not yet in the game, that they can drop out, rejoin, be removed from the game, lose their units, resign, exit, change teams, become spectators, and/or have been a spectator from the very beginning. Handling all of these cases correctly may be challenging.
+0 / -0
|
Okay, made some more headway... Is there any good way to alpha out anything but the background in Chili? Or any non-popping way to hide/show a widget? I tried gradually alpha-ing things out but labels don't support alpha and bars just turn black.
+0 / -0
|
I don't think chili has anything like a 'transition' built in, if that's what you mean. That would be neat to have at some point though. For labels you should be able to set font color to alpha, for example label.font.color = {1,1,1,0}. My best guess for the bar (progress bar?) is that there's more colors that need to be set to alpha, like bar color, bgcolor, fgcolor etc..
+0 / -0
|
Hm, I'll try label.font.color, I tried label.textcolor and got nowhere... I also tried bar:SetColor, which worked sort-of, but didn't actually alpha out the whole bar, it just made the active part of the bar fade into its black background. I probably need to peek under the hood at Chili's internals to see if this is possible, but it's probably not and I'll have to ax that feature.
+0 / -0
|
w00t, got it. Have to call widget:Invalidate to get it to pick up the change in arguments and re-draw itself, and snoop the source of the controls to see what color fields they use. For labels, I had to set font.color and font.outlineColor. For progressbars, I had to set color and backgroundColor.
+1 / -0
|
