Page 6 of 6 FirstFirst ... 4 5 6
Results 51 to 57 of 57

Thread: Performance & Memory monitoring

  1. #51
    Basic Member
    Join Date
    Sep 2017
    Posts
    56
    Notepad++ it is for me. I'd be interested in trying LDT at some point but yeah no worries, focus on your bot! (or whatever else)

  2. #52
    Basic Member
    Join Date
    Dec 2016
    Posts
    180
    First of all. thanks Nomad for his guidance.

    Actually, I never use some kind of copy-pasting techniques in my code because implementing of other utility methods does not worth it to do for a simple few codes. recently i tried to implement what you already mentioned about code optimizing or similar like that. I'm not a professional programmer indeed but regarding to my experience, LUA has some minor latency and errors( maybe ) on GC, what already people noticed. I'm using some huge tables for just one hero, making decision(s) what to do in each frame. these ideas may be raised that "OK, remove tables as much as you can" or "try not to update or trigger your code in each frame like what nostrademous did" or other things like that. Second one might be applied but what my knowledge help me with this, my DM ( Decision Making ) will fail in many frames of game.
    if we have to care all basic things of memory usage, optimization and etc. in our code, DOTA TEAM BOT SCRIPTING may become the last thing we should care about.

    Again, I admire you and other guy's will and diligence for helping us.

  3. #53
    Basic Member
    Join Date
    Dec 2016
    Posts
    180
    Im using ZeroBrane for lua coding

  4. #54
    Basic Member
    Join Date
    Mar 2012
    Posts
    2,017
    Well if your code fails because of optimizations or changes to code because of best practices, then, as I said before, there is a design issue.
    You can see some discussions I had with arz_on4dt: from the simple comment I made some time ago about his var names to optimizations he changed a lot. His code now may do similar things to before but the examples he posted on this thread are changed a lot. He updated his code with a proper way of coding (good job arz ) and he himself admitted performance increased (not to mention the silly warnings, previously caused by incorrect code, that he removed by fixing his code)

    If you have problems with your code feel free to post and we'll see if there is a way to help
    I still have to look at some code arz posted last week that I didn't have a chance yet too - I didn't forget

    But I don't agree with you on the last statement. This is not about the D2 API. It is not the responsibility of an API to automatically write code for you or optimize it.
    Look at C. A lot of people trashtalk it because you have to do your own memory management and garbage collection. One mistake and it can turn into memory leaks. A few more and you can get out of memory. Even more and you could get a BSOD. It is not C's fault for that. It gives you all the tools and possibilities to fix this, but C is not for everybody. If you want the code to do half of your job, you can turn to Java or C# but the performance will not be the same as with C. C will be faster than any C# or Java application, every single time.

    Same here. Lua does what it does. If you do it well, then it will work fine. However Lua can integrate with a different environment, like a framework or a game engine, which is our case here. Anything you call in the D2 API calls functions from the engine. If you call them wrong you can crash the game or eat memory. This is not Lua's fault. The same thing can happen if someone from Valve write the next major update incorrectly by calling an engine (not Lua!) function wrong and causing memory leaks. Does that mean it is DOTA's fault or is it the programmer's fault that he didn't use the code properly?

    Simpler example: calculating something. Maths is so versatile that it offers at least 3 ways to do most things. From Analysis to Trigonometry. Same with Physics. Each with its own advantages and disadvantages. Maybe in one you need more variables, maybe another is faster, maybe another has more accuracy.
    Most engines seem to use the same code. Why? Over time it got to a point where each found the most optimized way of writing things and in the end they all use it. Every game will need physics and collision. Chances are the code is similar to most. Bad games with low FPS will obviously have different code, maybe older. Other my use the same library (Havok for example). But if the code fails is it Havok's fault? Doubtful. If it works on one game but fails on another then it is probably the programmer's fault.

    Bottom line: Lua is not the problem Yes, it gets complicated because it is not just a simple call of Unit.KillEnemy() and the function should automatically know how to use items and abilities and move and dodge projectiles. You have to code it all. And if you use the native code and just do modes in Lua - same thing. The code exists. But in C++.

    There is no simple way, sorry
    Developing, whether it's scripting or actually programming, is never simple. Even in JavaScript. Look how it evolved. From the simple code to open a pop-up to this.

    But don't give up. Trust me: you learn a lot more from code optimization than from actual coding
    And believe me - the reward of seeing a properly written bot (with easy readable code) and the low FPS and the performance is amazing.

    P.S. in a 5v5 which botpack do you think wins? One that has 40 FPS and runs fast or a bad one that runs at 15 FPS ? Just like in a real game, FPS and ping matter, even for bots.
    Explanations on the normal, high and very high brackets in replays: here, here & here
    Why maphacks won't work in D2: here

  5. #55
    Basic Member
    Join Date
    Sep 2017
    Posts
    56
    Seems I might have to walk back my comment that avoidance zones keep working if you instantly delete them. Results seem to indicate it isn't entirely the same behavior, though more testing is still required. It might be the case that they only still work right next to the player, and not for further zones.
    For now I've shifted to just using avoidance zones for towers and other static zones.


    As a minor aside. It seems that if you keep using the restart console command to start new games, and keep doing that for a few hours, eventually overall performance will degrade, including much higher Think times. There appears to be some kind of leak somewhere. It's not a huge deal, but if everything starts feeling slower and your console gets spammed it may just be that you need to properly restart the game.

  6. #56
    Basic Member
    Join Date
    Mar 2012
    Posts
    2,017
    I sent a PM to Chris with something I found in a debugging session of mine. The memory leak might just seem to be an effect. I suspect the cause is that restart doesn't properly cleanup the VM.
    There is a weird message when I close the game sometimes as I see the VM initialization even when disconnecting back to the menu (?????) Not sure what that's all about.

    If the cleanup gets fixed then more issues might indirectly be resolved. I had some talks on some threads with SIKIM about some false positives caused by (ab)using the restart command.

    So as a PSA, that means the restart command could be used on certain unit-tests done on point, but not for actual (reliable) tests or playing the game. GetRuneTimeSinceSeen() is one of the functions that has this problem. I use this a lot for rune control and I had to do some workarounds in the bot logic to get it to work after using the restart command. The effect is that it "remembers" when the bot last saw the rune in a previous match.
    Explanations on the normal, high and very high brackets in replays: here, here & here
    Why maphacks won't work in D2: here

  7. #57
    Basic Member aveyo's Avatar
    Join Date
    Aug 2012
    Location
    EU West
    Posts
    2,927
    Just to clarify the disconnect thing: dota main menu is actually a loaded map - the "start".
    Whenever you end an online match / bot match / whatever by disconnect, the "start" map gets reloaded.
    VScript launches two instances of the vm, one for the server part (locally hosted, starting first) and one for the client part (also local, starting 0-2 seconds later).
    Whenever having issues, try using the disconnect command as it properly refreshes code that might not be compatible with cl_script_reload_code.

Posting Permissions

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