Do not send me private messages unless it is absolutely necessary or the content is sensitive or when I ask you to do that...
I added player location because, up till now it was only possible way to find out where the player is - if not in the same area. I was not sure if you will always display players location next to portrait. But now reading your last posts again ... well skip it![]()
13.7.1.0 STABLE
- NOTE: this version is not sending scene data anymore (it was only in the latest beta)
- changed: timebomb will expire on 2013. august 1.
- added: ExpAnalyzer always shows the bar for p100
- changed: ExpAnalyzer respects based_on_run="0" option in experience bar settings
- improved: HUD startup is a lot faster than in the past
- improved: lower cpu usage
- improved: stability fixes in collector engine
- added: portrait overlay (real DPS, health, skill/passive list on hover) (options under <portraits> tag in config.xml)
- added: player status next to it's portrait icon
- if he is in a different area, "in New Tristram" is displayed for example
- if he is in the same area as you, but too far then "too far" is displayed (when HUD can't access actor data)
- if he is close to you and using the town portal then "using Town Portal" is displayed
- if he is close to you and identifying something then "identifying a rare" / "identifying a legendary" / "identifying all items" is displayed
- added: auto_hide option to reveal minimap. If this is enabled then reveal will temporary turned off when the cursor is over the minimap. (default ON)
- added: automatically reveal static (never-changing) areas of the map (go to Act 1 town, press Tab and enjoy)
- added: thousand separator helpers for price input controls (default ON)
- added: displaying values after the 15% fee (on the Sell tab and only in gold auction house)
- changed: Menu's CharacterBar is automatically hidden when Profiles, Achievements, Game Menu, or Auction House window is visible
- added: buff timer for Deadly Reach - Foresight
- fixed: the BattleTag display above players' head is fixed and re-enabled (it was disabled since 13.3.12.3 STABLE)
- changed: "y_offset" attributes under <resources><health> and <class_specific> are deprecated and replaced by "inside_globe" logical attribute (default OFF)
- changed: some default values and colors
- changed: using high_framerate=1 will affect D3 UI readout refresh rate too (means faster tracking of D3's UI elements)
- added: the debug option (ACD dump) will generate one more file called 'acd_dump_onscreen.txt'
- added: <stat_tracker enabled="1"> attribute to config.xml, so the entire StatTracker feature can be disabled (default ON)
- changed: project is targeted to x86 (instead of AnyCPU)
Last edited by KillerJohn; 06-30-2013 at 05:17 PM.
Do not send me private messages unless it is absolutely necessary or the content is sensitive or when I ask you to do that...
Do not send me private messages unless it is absolutely necessary or the content is sensitive or when I ask you to do that...
talked to my m8s ,using turbohud too, and they and i would like to compare during the run or at the end of a run whats about our dps output. so we can optimize shit , mby specs or the way we play togetherdone some with PS just wanna know what the guys here and u think about
i call it "Party Details" should be a tab on the stats tracker mbywith toggle or with hover popup/switch like the ogirinal switch button to total / today statistics
should be just for the actual run. no total or today statistics needed for this dps sheet
Nice PS work, but sadly this is not a new idea. The problem is how the real DPS number works... because real DPS is a server-side attribute and shows the average of the last few seconds, and it is a rolling average, it means that averaging that average DPS will result false values.
Do not send me private messages unless it is absolutely necessary or the content is sensitive or when I ask you to do that...
1) "actual" real DPS means a 2-3 sec average (calculated on server-side, I have nothing to do with that). This is a semi-true value, because it is an average.
2) separated actual real DPS is already displayed for all party members
3) I can display a "grand total" actual real DPS (adding up all players' actual real DPS), but this will be a summary of semi-true values and we don't even know how the averaging windows are calculated, so they can be off each other, so the sum-of-each-players-actual-DPS will be misleading.
4) I can display the highest real DPS per player, showing the maximum DPS mementary throughput for a player. But I have no idea for what reason. You can not measure a player's real performance through a run with his "spike" of his DPS...
Do not send me private messages unless it is absolutely necessary or the content is sensitive or when I ask you to do that...
mh yes ur right manrly annoyin
thought its a real time size u can read of each player. but if its server side ****ed up this doesnt make sense
and its the only way to read out "real dps" output? or are there other attributes to read out and calculate dps output by urself?=
so for ex. implement a real dps meter with ur own calculation. but would only work if u can handle and read out every hit on the enemy by player/players
Last edited by R3peat; 07-02-2013 at 02:43 PM.
dont understand that much of mem reading and stuff but theoreticaly if there is a number popin up in the game this number should be theoreticaly in mem at this moment at some position and can be theoreticaly read out or?
or the stuff THud works is all around functions in d3? same way if i would code a game with c# with a lot of methods / functions. if u would built me a hud for my game without the source u start scanning my game for running methods/functions ? so u can just show values of those functions/methods right?
so getting values out of a game is all about reversing the code? finding such running functions and call them for their values?
rly dont know much about sry if im nub :P
Last edited by R3peat; 07-03-2013 at 11:47 AM.
There are a few different methods one could use to get information from a program. The most crude version gets it by reading pixels and trying to figure out what data they represent. A better way is to read the memory for that process, but for that one has to know where and how data is stored and how to get to it (pointers+offsets). Like you say, this is much about reversing the code. Since Diablo is communicating with a server, one could eaves-drop on that communication and retrieve a lot of data that way (if one understands how the protocol works). Eaves dropping like that is quite complicated though. And then the final solution, injecting code. By adding or replacing machine code, you can make the program execute whatever you want instead. You can see it as live debugging, with live editing. This method is quite detectable though.
TurboHUD uses memory reading (basically non-detectable), no injection at all! It does not modify memory either. Now, the number you're talking about I assume is the damage displayed on screen when you hit something. Sure, in theory it's possible to monitor all these and calculate a "real" DPS. But in practice that's very hard to do with memory reading. You have to keep in mind that OSes are multithreaded, and a process may at any time be suspended to let something else run for a little while. All these breaks means it's easy to completely miss a temporary value (like a damage number flashing up on screen). When reading memory you're polling at intervals, otherwise an entire CPU core would be used, so this is where most data is missed. Even if those numbers can be read and added up, it's not sure they represent what the server thinks. They could just be pseudo-random numbers that only exists on the client to lessen server load. The only way to really capture all those values would be to inject a method that gets called every single time such value is generated, then you could be sure you got them all.
I hope you found this interesting/useful![]()