Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 30 of 38

Thread: Questions about function fallbacks and chaining to generics

  1. #21
    Basic Member
    Join Date
    Dec 2016
    Posts
    729
    Quote Originally Posted by ironmano View Post
    Ah yes, only numeric index counts for # I ran into that as well.

    There is also some issue with tables with nil in the middle of them, I cant remember what it is off the top of my head.
    Also true for a.getn() which is equivalent of # operator. It is actually surprising there is no way to get size of table without writing your own implementation or purely using numeric indexes

  2. #22
    Basic Member
    Join Date
    Mar 2012
    Posts
    2,012
    Yeah I knew about that. It was quite a shock when I needed it. After hours of research, everyone (where I asked or posts I read) concluded that this is the best and most efficient way:
    Code:
    function GetTableLength (Table)
    	local length = 0;
    
    	if (Table ~= nil) then
    		for _ in pairs(Table) do
    			length = length + 1;
    		end
    	end
    
    	return length;
    end
    Explanations on the normal, high and very high brackets in replays: here, here & here
    Why maphacks won't work in D2: here

  3. #23
    Valve Developer
    Join Date
    Sep 2011
    Posts
    1,704
    I have a solution to this that we'll be shipping in the next update. It allows for proper instancing when chaining to the base class (so if you make a mode_laning_sven, calls from there to mode_laning_generic are to its own instance of mode_laning_generic) and only requires some changes to the boilerplate code that you put at the top/bottom of our lua files.

  4. #24
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    Quote Originally Posted by ChrisC View Post
    I have a solution to this that we'll be shipping in the next update. It allows for proper instancing when chaining to the base class (so if you make a mode_laning_sven, calls from there to mode_laning_generic are to its own instance of mode_laning_generic) and only requires some changes to the boilerplate code that you put at the top/bottom of our lua files.
    You are my hero

  5. #25
    Basic Member
    Join Date
    May 2014
    Posts
    270
    @ironmano. The AbilityLevelUpThink() in ability_item_usage_generic.lua now works like item_purchase_generic.lua. Since I change to the new boilerplate code, I have some function in ability_item_usage_generic.lua that can't be execute without me have to called it in ability_item_usage_xxx.lua. e.g BuyBackUsageThink() and CourierUsageThink() . But function like ItemUsageThink() can be execute without me have to called it in ability_item_usage_xxx.lua. Any explanation for this? Do I have to call every *Think() function in ability_item_usage_generic.lua in every ability_item_usage_xxx.lua from now on?

  6. #26
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    I would think it would be consistent if you can leave out any *Think() in ability_item_usage_botname.lua and it automatically calls the generic version, then they should all work that way. If not it might be a bug one way or the other.

    Either way, it looks from the change like the intention is to have something like the below for each function in *_botname.lua that needs to call a generic.

    Code:
    function AbilityLevelUpThink()    
    	ability_item_usage_generic.AbilityLevelUpThink()
    end
    Which is good from a code readability standpoint anyway.

  7. #27
    Basic Member
    Join Date
    Jun 2013
    Posts
    274
    I'm not in favor of it calling the generic file automatically. There may be some bots that don't use the generic file and some that call the generic file in different spots than other bots. The ability to call upon it when needed is pretty vital.

  8. #28
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    From what I'm reading there isn't any change at all to botname files automatically calling the generic function. Just that now with this new method bots can get their own instance of the generic where by default they share one

  9. #29
    Basic Member
    Join Date
    Jun 2013
    Posts
    274
    They never did automatically call them and still don't. All he did was remove the deprecated module() method and instead used a return-based function method. It works exactly the same as it did previous in terms of calling it in the botname files.
    I read your post as wanting all botname files to automatically call upon the generic file even without referencing it.

  10. #30
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    The generic function is only 'automatically' called if you don't override that function in the hero file, same as always.
    There is a small change in that now a bot gets its own instance of the generic (whole file not just the function) with dofile. This didn't work this way before with the old method.

    No I am very happy how it is now, I was referring to arz_on4dt's implication that some functions call the generic when not overridden and some don't. Maybe a bug I dunno, but no I don't want overridden functions calling generics automatically

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •