View topic - How to obtain unitdef by unitdefid?



All times are UTC + 1 hour


Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: 31 Jul 2010, 21:38 
AI Coder

Joined: 16 Nov 2009, 18:26
I'm not sure if this is an oversight in the AI interface, a bug in the skirmish interface, a bug in the python interface, or I flat out misunderstand how I'm to do this. First, allow me to explain what I'd doing and trying to do.

I have a unitid provided by the unit created callback. I then grab the unitdef from the Unit interface.
Code:
unitdef = Unit.getDef( unitid )


That all works as I expected. I then check the UnitDef.getBuildOptions() result. I'm told this returns the list of unitdefid(s) which the original unit of the obtained original unitdef is capable of building. Sure enough, I call UnitDef.getName() on each of the values obtained from my call to getBuildOptions() and they look like what you would expect the unit to be able to build. So far, so good.

So here's the question. How can I take that list of unitdefids and obtain each corresponding unitdef? I tried doing so in a round-about manner as follows, as I've not found a more direct route to obtain the information.
Code:
name = UnitDef.getName( unitdefid )
UnitDef.getUnitDefByName( name )


But that doesn't do what the name says. It only returns the original unitdefid, which is contrary to the method's name. Shouldn't it really be called, "getUnitDefIdByName"? Or perhaps the python interface is doing the wrong thing? Meaning, perhaps the interface should be returning the unitdef, as the name implies, and its mistakenly returning the unitdefid, which the name does not imply?

Shouldn't there be a UnitDef.getDef( unitdefid ) method or equivalent? Seems like there should be a very straight forward method for obtaining a unitdef by its given unitdefid. Seems like an obvious bit of functionality, which makes me think I'm overlooking something.

I think I'm stuck unless someone can straighten me out. Which wouldn't be the first time I needed straightening out. :?

--
I edit the message. I provided some clarifications which may have been confusing if careful attention was not given. Please re-read.


Last edited by echoone on 01 Aug 2010, 00:34, edited 5 times in total.

Top
 Offline Profile  
 
PostPosted: 31 Jul 2010, 22:58 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
This doesn't make much senseless, since a unitdef is always the same, a united represents a unit type, not a unit, so either you mean the united is the same as the original which seems obvious, or you mean the builders united when you are referring to the original, at which point either the builder can build itself, or you've confused everyone and yourself

Further clarification necessary!! If possible in a single sentence


Top
 Offline Profile  
 
PostPosted: 01 Aug 2010, 00:12 
AI Coder

Joined: 16 Nov 2009, 18:26
echoone wrote:
How can I take that list of unitdefids and obtain each corresponding unitdef?


Top
 Offline Profile  
 
PostPosted: 01 Aug 2010, 01:54 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
Normally the API provides an array of unitdefs, which are indexed by ID, I cant speak for your API of choice, but that's how it worked in the legacy API. I dont know why you couldnt just use the name strings though =/


Top
 Offline Profile  
 
PostPosted: 01 Aug 2010, 07:31 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
as AF suggests, thi is a Python AI Interface issue, not general/C AI (Interface) one.


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group

Site layout created by Roflcopter et al.