Jump to content

Neo2003

Members
  • Posts

    149
  • Joined

  • Last visited

  • Donations

    0.00 GBP 

Posts posted by Neo2003

  1. confirmed, with goldshire smith. Anyway this is client side check and it _only_ when you attempt enter and fail....

    possible missing some data refresh send to client and dismount... Unclear what...

    [added]it repeatable by chance. In fact most time for tests character auto-dismount and all ok.

    So block added only when this fail.

    I think you miss nothing. I have the same problem on Offy very very often and even more now that we can fly everywhere.

    Some small mounts are able to enter and you automatically dismount when you are in, or the mount is too big and cannot pass the corridor, then you are stuck outside until you right-click on your mounting buff to remove it, then you can enter. So it's a typical client behavior.

  2. Optimization is enabled by default in Release build.

    VC 10.0 uses MSBuild system so all default settings are stored in *.props files contained in folder c:\\Program Files\\MSBuild\\Microsoft.Cpp\\v4.0\\

    Thank you for this clarification around VC100. You are right, /O2 is set by default on this one. I did not see this since I don't have it installed on my PC at work. Anyway, it's not bad to have the settings set in project properties. This will align it with VC80 and VC90 ones even if this does not change the result.

    For VC80 and VC90 this flag is not set by default and the interface is misleading everyone since it displays random values when settings are not set. (For example I spent a long time searching why a daemon I write next to mangos to communicate with it did crash, it was just the call convention displayed gray as "__cdecl" while it was not.).

    I still believe this patch is fine like it is.

    Neo2003

  3. Hello,

    It's a very simple patch only for Windows users.

    Nearly all projects miss the optimization flag, that is one a the reason that makes mangos run faster on Linux since on Linux who would compile something without /O2 ?

    Then this patch activate /O2 for both w32/release and x64/release for all projects where it was missing.

    The gray display in Visual Studio for a setting that not mean it's activated, this means it's not configured and what is displayed does not reflect what is used by the compiler. Just check the command line arguments passed to CL and see that most of the projects don't pass any optimization = no optimization.

    Check this patch, if no objections this will go in GIT soon since it's a very basic minimal optimization.

    http://pastebin.com/incNzHJ5

    Note: I also took the opportunity to align VC80 configuration with VC90 one (removing x64 portability check)

  4. dont use fast math on vmap code, BIH doesnt go well with it

    BIH is in vmap code so in game project, not in g3dlite project.

    If you download G3D 8.00 sources and open the VC project files included, you will see that G3D library is set to compile with the following flags in release mode by default with VS compilers:

    Optimization: Full (/Ox)

    InlineFunctionExpansion: Any suitable (/Ob2)

    EnableIntrinsicFunctions: Yes (/Oi)

    FavorSizeOrSpeed: Favor Speed (/Ot)

    WholeProgramOptimization: No

    EnableFunctionLevelLinking: Yes (/Gy)

    EnableEnhancedInstructionSet: SSE2 (/arch:SSE2)

    FloatingPointModel: Fast (/fp:fast)

    But you are right, I did not dig Detour & Recast behavior and which flags the author uses. So it's unsafe without big testings on those ones.

  5. About compiler flags, you had anything particular in mind? Since all I can think about are cpu dependent.

    Yes, of course ;)

    Activate fast-math on g3dlite, Detour, Recast and MoveMapGen (FloatingPointModel="2" in vcproj files or in project properties C/C++ | Code Generation | Floating Point Model).

    As far as I remember, this option was first put to strict mode as default in VS2005. It has a big performance impact and code size impact due to x2 more instruction generated when put to strict.

    On my test PC MoveMapGen.exe (Win32/release) is by default 636Kb in size and takes 328 seconds to extract map 33. After it's 253Kb in size and process the same map 33 in 243 seconds.

    Note: I will soon patch all mangos project files so that release libraries and binaries are at least compiled with /O2 (ex: g3dlite is /O0 currently on VC80 and VC90, i386 and x64).

    Neo2003

  6. Hello all,

    Here a small multi-threaded python program that will spawn as many MoveMapGen processes as the number of cores you have and will maintain this load until all is extracted.

    Untested on Linux, it probably requires some parameters to subprocess.call in order to open an xterm per MoveMap Generator or all outputs are mixed.

    The list of maps I hardcoded is probably not complete. Be sure to keep 0,1,530,571 in the beginning in order to max load your PC. The collection is unstacked by the program so from left to right.

    #!/usr/bin/python
    
    import os, sys, threading, time, subprocess
    from multiprocessing import cpu_count
    from collections import deque
    
    mapList = deque([0,1,530,571,13,25,30,33,34,35,36,37,42,43,44,47,48,70,90,109,129,169,189,209,229,230,249,269,289,309,329,349,369,
       389,409,429,449,450,451,469,489,509,529,531,532,533,534,540,542,543,544,545,546,547,548,550,552,553,554,555,556,557,558,559,
       560,562,564,565,566,568,572,573,574,575,576,578,580,582,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,
       601,602,603,604,605,606,607,608,609,610,612,613,614,615,616,617,618,619,620,621,622,623,624,628,631,632,641,642,647,649,650,
       658,668,672,673,712,713,718,723,724])
    
    class workerThread(threading.Thread):
       def __init__(self, mapID):
           threading.Thread.__init__(self)
           self.mapID = mapID
    
       def run(self):
           name = "Worker for map %u" % (self.mapID)
           print "++ %s" % (name)
           if sys.platform == 'win32':
               stInfo = subprocess.STARTUPINFO()
               stInfo.dwFlags |= subprocess.STARTF_USESHOWWINDOW
               stInfo.wShowWindow = 7
               cFlags = subprocess.CREATE_NEW_CONSOLE
           else:
               stInfo = None
               cFlags = 0
           retcode = subprocess.call(["MoveMapGen", "%u" % (self.mapID),"--silent"], startupinfo=stInfo, creationflags=cFlags)
           print "-- %s" % (name)
    
    if __name__ == "__main__":
       cpu = cpu_count() - 0 # You can reduce the load by putting 1 instead of 0 if you need to free 1 core/cpu
       if cpu < 1:
           cpu = 1
       print "I will always maintain %u MoveMapGen tasks running in //\\n" % (cpu)
       while (len(mapList) > 0):
           if (threading.active_count() <= cpu):
               workerThread(mapList.popleft()).start()
           time.sleep(0.1)
    

    Have fun.

    PS: on Windows, properly setup your compilation flags and you get a -33% time to extract compared to what is on GIT currently (btw this is true for core too, release mode can have 20% speed increase by putting other compilation flags, but that's another story).

  7. One more though: Noticed that in some portions of the extractor code we use "int" and in others+core "uint32". Can't it cause problems? Lets say, on 64bit system int is 8 bytes, while uint32 is still 4. Can this sort of thning happen with ACE defines? it sure looks so. Do we really care?

    It shouldn't impact anything. All of the things we write to file in the extractor is read using the same type in the core (assuming extractor is run on the same arch and os as core ;)). If I missed something, we should fix it.

    Hello,

    I think you should use uint32, uint16, int32... everywhere like in the core. Personally I generate map, vmap... on my Win7 32bit and transfer the files to a Linux x64, and I think I am not the only one who does this.

    If you don't want to include core files that define them, you can use stdint.h which also exists in Win platform by including this: http://pastebin.com/cEt9Ph7P. But then you would have to use uint32_t, int16_t...

    Neo2003

  8. Hello,

    In this packet SMSG_REDIRECT_CLIENT @ offset 62 there is a string:

    "We couldn't figure out anything that was funny enough to put here.

    If you'd like, please make a suggestion for the next patch...

    "

    What is this for? encryption phrase?

    Edit: Adding packet

    18:22:20 id:000006 [s2C] SMSG_REDIRECT_CLIENT (33792 = 0x8400) len: 261
    0000: 0b 00 00 00 b3 7a 17 77 8f e9 dd 7e a1 20 6f a7  |  .....zw...~. o.
    0010: 5f 4e 2a 9d 22 20 dd b1 17 3b 10 b8 [u]5f 04[/u] 43 c9  |  _N*." ..;.._.C.
    0020: 7a 2c f2 0b 01 b6 78 30 19 00 d5 ff 9f 8b c6 9b  |  z,....x0.......
    0030: 51 da b0 3d 0d 98 38 bc 7a ea 12 41 de a5 57 65  |  Q..=..8.z..A..We
    0040: 20 63 6f 75 6c 64 6e 27 74 20 66 69 67 75 72 65  |   couldn't figure
    0050: 20 6f 75 74 20 61 6e 79 74 68 69 6e 67 20 74 68  |   out anything th
    0060: 61 74 20 77 61 73 20 66 75 6e 6e 79 20 65 6e 6f  |  at was funny eno
    0070: 75 67 68 20 74 6f 20 70 75 74 20 68 65 72 65 2e  |  ugh to put here.
    0080: 0a 49 66 20 79 6f 75 27 64 20 6c 69 6b 65 2c 20  |  .If you'd like, 
    0090: 70 6c 65 61 73 65 20 6d 61 6b 65 20 61 20 73 75  |  please make a su
    00a0: 67 67 65 73 74 69 6f 6e 20 66 6f 72 20 74 68 65  |  ggestion for the
    00b0: 20 6e 65 78 74 20 70 61 74 63 68 2e 2e 2e 0a 00  |   next patch.....
    00c0: 47 f7 cb 44 b9 0e e1 8f 25 f2 a3 09 8d 84 8c dc  |  G..D....%.......
    00d0: a2 25 46 b1 71 b0 d1 8c ae 64 ae 18 aa 91 17 b0  |  .%F.q....d....
    00e0: eb 56 95 38 fa ea 2a d1 68 8a 05 8d 2a 57 a8 04  |  .V.8..*.h...*W..
    00f0: a8 46 a9 ee 64 e8 d3 42 64 37 ea 0b e9 36 18 4f  |  .F..d..Bd7...6O
    0100: [u]c3 0c ef 2e[/u] 00                                   |  .....
    

    Underlined parts are port for first and IP address for the second.

    Neo2003

  9. Of course procs stack.

    They don't stack only in case they are both same, like when you have berserker on 2 one hand weapon. If the second proc when the one did already, as far as I remember, the 2nd proc is ignored. Having 2 times the same proc just optimizes the uptime as long as they don't proc in the same period.

    And for "on activation" item buffs, bliz clearly states on the item with what it does not stack: "... is sharing its cooldown with...." type of text.

    Note: I talk about 3.3.x ofc.

  10. Am I to understand you that if you buff

    30IntScroll, 20IntScroll, that then only the 30IntScroll will have an effect, but when the 30IntScroll aura expires, the effect of the 20IntScroll will become active?

    No, this does not work like this.

    If you buff yourself/anyone with 30 Int Scroll, then the attempt to buff the same target with 20 int scroll will result in an error message like "There is a better buff already".

    For aura, only the highest is applied. If the owner is no more in range or no more alive, the next one applies (totem, paladin aura...)

    For buffs with same level or higher than previous applied one, the last and higher one is applied and the other is canceled forever.

    There is no error when applying a raid buff weaker than an existing one (it's just ignored) while you have a clear message if you try to single buff someone which already has a higher buff.

    Neo2003

  11. I can't really imagine developing a server requiring a modified client without having the editor running after you. This is clearly passing the border.

    My perception is that if we can't make something work server side only, then their is no point of even doing a server requiring a client change, let's stay 3.3.5.

    Neo2003

  12. I play a hunter on offy as my main.

    When the pet cannot come back to the hunter, it stays at near possible place. Then if the Hunter go away or the place is to far from the hunter, it despawns.

    If the pet cannot go to the target, it resets his command and go back to the hunter.

    Pet never relocate, but can climb a very high angle if needed to join the hunter, lot more than a player can do.

  13. Hello,

    I updated G3D to 8.0 final since the one currently in core is a beta one.

    Many small mistakes are fixed.

    Example:

    index 3197ea4..6043aea 100644
    --- a/dep/include/g3dlite/G3D/Vector3int16.h
    +++ b/dep/include/g3dlite/G3D/Vector3int16.h
    @@ -80,7 +80,7 @@ public:
        inline Vector3int16& operator+=(const Vector3int16& other) {
            x += other.x;
            y += other.y;
    -        z += other.y;
    +        z += other.z;
            return *this;
        }

    I tested it on VC80 32/64, VC90 32, VC100 32 and also on Linux Ubuntu 32bits.

    Please test it too on your Linux, Windows, MacOS X, ... especially on Linux 64.

    Here is the patch, as always drop dep/src/g3dlite and dep/include/g3dlite with files inside the archive and overwrite other files in win folder.

    http://www.sendspace.com/file/007k2s

    Files are all in DOS format, this is because I use git on Windows. They will be anyway in Unix format when pushed.

    Neo2003

  14. As I suspect this authenticator is just an ActiveCard solution, you would have to run an ActiveCard server to have the proper challenge/response from the server side. And then you would need to declare the tokens for this service to recognize the tokens sent code.

    So in 2 words: forget it.

    Neo2003

  15. Hello,

    I changed the ACE version, 5.8.2 is really the latest.

    I have made the linux part too (tested on Ubuntu 32 bits), changed the way I remove warning 4996 and also removed the warning about ACE_Atomic_Op without altering ACE files. In fact I changed in src/shared/Threading.h:

            private:
               ACE_Atomic_Op<ACE_Thread_Mutex, long> m_refs;
    

    Edit: I also used the sources that are in unix format, not MS crlf.

    I will upload the new patch as soon as I can (not possible from where I am currently).

    Neo2003

  16. Hello,

    This is just an update of ACE. Currently MaNGOS uses version 5.6.6. I updated it to 5.8.2

    I post it here because there is a warning about using "this" before initialization of the class, and I am a bit lost since they are Virtual classes (in src/shared/Threading.h).

    I patched the sources to remove C4996 warnings which already spam a log the compilation console with current MaNGOS and added the utf-8 fix. Changes are between // MaNGOS changes begin and // MaNGOS changes end.

    Tested to work on VC8, VC9 and VC10 with [10602][10605], I need someone to validate it on Linux.

    Here are the files: http://www.sendspace.com/file/p2381r

    Oct. 11th: New version 5.8.2 with Linux and all VC support: http://www.sendspace.com/file/3b2sq7

    Oct. 21th: Updated the VC80 and VC90 project files the solution files to reflect 5.8.0 to 5.8.2 changes: http://www.sendspace.com/file/3xndih

    Drop the current dep/ACE_wrappers and use the provided one.

    Overwrite other files.

    Neo2003

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use