Neo2003
-
Posts
149 -
Joined
-
Last visited
-
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by Neo2003
-
-
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
-
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.
Note: I also took the opportunity to align VC80 configuration with VC90 one (removing x64 portability check)
-
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.
-
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
-
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).
-
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
-
hmm all of this is nice but we still dont know how to encrypt the data to be sent from the server -.-
We know it's not possible just because this packet is RSA encrypted with private part of the certificate and the client has obliviously the public one only.
-
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
-
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.
-
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
-
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
-
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.
-
I did compile it on Ubuntu 10.04 32bits without problem since I added -msse in the config to have sse enabled on Linux.
-
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
-
In [10643]
-
I updated VC80 and VC90 files (see 1st post).
I let you test until Monday then I push it
Neo2003
-
VC 8.0, 9.0 project files are messed up a bit, look at diff: http://paste2.org/p/1040074.
Oh yes, I think I did forget to update them for ace 5.8.2. They are still 5.8.0. I will update them.
-
Thanks for the testings you made Jethrogibbs.
Can others test it on Linux and Windows so that we can push this update after being sure all work fine?
Thanks all.
Neo2003
-
Hello,
Is it possible to allow avatar with size 80x80?
64x64 is very small and my small avatar is not accepted while it is 80x80 and 40kb in size.
I resized my avatar to 64x64 but now it's broken since it's an animated gif.
Note: It's not urgent at all.
Neo2003
-
- does the mob not react at all?
I can answer this one. The creature takes damage from the first shot(s), then become immune and you have a yellow text "Immune" and it is back full life.
-
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
-
Hello,
Try if you have same problem with the latest I uploaded (5.8.2) - See 1st post.
I will check if I can reproduce anyway.
Neo2003
-
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
-
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
walking trough door in a shop after unmount (mount / un mount problem)
in OldBug reports
Posted
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.