Valhalla Legends Archive

Puedo ver. Entonces, quizás debemos hablar en su lengua.

Qué es "kick pj"? No entiendo qué significa.
Por supuesto D2GS no es fuente abierta, porqué es característica intelectual de Blizzard Entertainment. Es su software de servidor.

A propósito, escribío StarForge?

Wouldn't it be a lot more professional, cleaner, and efficient to write a function for this instead of using a regex?

bump

For anyone wondering, I haven't checked into it much yet but two days ago I stumbled upon WM_PRINT, which I believe might be the solution. I would be able to do solution #2 as described in my first post.

It's quite desirable to have a RichEdit control with a background image - however not so easy to accomplish this.
A -very- long time ago, I learned how to do this with Visual Basic 6. It was as simple as setting the WS_EX_TRANSPARENT bit of the extended window style of the richedit contol in question, and slapping an image control with the picture you'd like in back of it. It's unfortunate this isn't so easy for any other language. VB6 does a lot of custom window drawing voodoo with all of its controls, which helps much in this matter.
Working with nothing more than the Win32 API is considerably more difficult, however, because of a god awful blur created when the richedit repaints when scrolling (WM_ERASEBKGND isn't sent to the richedit then).
According to MSDN, with WS_EX_TRANSPARENT enabled, it "should not be painted until siblings beneath the window (that were created by the same thread) have been painted. "

Ok, the first logical thing to try is to send a WM_ERASEBKGND where it didn't...
Subclass the richedit, and on WM_VSCROLL call RedrawWindow with RDW_ERASE | RDW_INTERNALPAINT.
Doesn't work. Has no effect.
It seems like the blur is being painted onto the parent window's background (which is the richedit's background too, since it's transparent), so the next logical thing to do is try to redraw the parent window yourself.
In the richedit's proc, handle WM_PAINT before returning CallWindowProc, where you will FillRect the target area of the RichEdit right before painting. No effect, still blurs.
Then, you notice, every time the richedit is painted to, the parent window receives a neat WM_ERASEBKGND message too! Maybe it'd work if you tried to manually erase the background here? No.
So on, and so forth....
Then, I had asked myself if making it a transparent window was even necessary.
Long story short, it is. For some reason it seems the background clearing/painting is done in the richedit's internal painting routine (what were they thinking?). Any paints made in a WM_PAINT handler before calling the original window proc would result in a neat painting over your picasso.

So there must be some way to do this, right?
There are, theoretically. I don't know how to do either of these, which might be potential solutions:
1). Make a brush with CreatePatternBrush using the image you'd like to paint the background of the richedit with, then you'd somehow be able to have it paint the background on its own with the brush you indicate.
2). Have it output what it would paint into a memory DC, so you're able to TransparentBlt it onto the final window, effectively getting rid of the background it painted on by itself.

I couldn't solve this problem two years ago when I threw this feature into my bot, so I kind of cheated by using microsoft's implementation of #2: WS_EX_COMPOSITED.
This is basically a bit that enables double buffering for a window and all of its child windows, only problem is that it can't be used on a control (only top-level windows or MDI children), so you'll see its undesirable effects on all child windows of that parent window, which include an ungodly amount of CPU usage, and the inability to have column headers in a listview. It took me a while to figure out the exact cause of the latter, as it had caused a constant stream of NM_CUSTOMDRAW WM_NOTIFY messages to be sent to the parent from an unidentified hWnd which turned out to be the column component.
Back then, I looked at it as a temporary fix, but over time I'd forgotten about it. Now that I go back to implement a neat feature I just thought up which utilizes richedit background drawing, I'd remembered, and attempted to make a more permanent solution with my 2 years more experience. I failed again.

P.S.
You might take 5 minutes of your time and search for "transparent richedit" on google, and you'll find a wealth of CodeProject and related sites with articles on exactly this, but before you post links to those here, do download the demo applications and try them out yourself. None of them are able to overcome the unfortunate blur effect.

EDIT*
if anyone needs to see for themselves, this is the blur effect happening to the codeproject article's demo application.  apparently, this doesn't happen to cuphead. i suspect if this is true and i wasn't being bullshitted to, there is a newer version of riched32.dll out there with this problem fixed.

I assume it'd get that from the game server.

Quote from: MysT_DooM on June 12, 2009, 12:33 PM
If W3GS is anything like SCGS than yeah, one would have to send the chat to each person.

Funny you'd say that, i thought it was overwhelmingly obvious there is no SCGS.

Yeah, the server was only sending it for a short amount of time (I first noticed it at 5:30 PM). I am now unable to recreate this.

I think that's because you didn't move the class pointer into ecx before calling, since it's a thiscall.

Just started getting this today, right after the 0x54 packet in the SRP logon

ff 43 08 00 00 00 00 00

...can anyone packetlog warcraft 3 and see if there's a response to this packet? I don't have it.

It's a blob of memory from the server's daemon. An old bug on their side they never patched over. This has been discussed multiple times before, check the forum search feature out.

That's a real odd address, you sure you're calling that function in the valid range?

Hey chris, i found something for you...

6F6A0C50h

enjoy :-D!

As I stated over AIM, it's just impossible. stop trying unless you have a cluster of 4000 supercomputers. finding the socket descriptor is a much better way to go about everything.
Question to people who might know: battle.snp seems to have anything related to wc3 logon, but it's not at all included in the warcraft 3 client's binaries. game.dll is responsible for battle.net logon, yes? That's the conclusion i came to. But look at that file, it's honkin'. Takes me 2 hours to disassemble and analyze in IDA. What's worse is that from what i was able to tell in 5 minutes of analysis, the socket descriptor is stored in some large-ish dynamically allocated struct, and it's just so huge the filesize itself is extremely discouraging. crap.

Quote from: Yegg on May 16, 2009, 11:50 AM
Brew:How do you know that you answered his question? You made it clear in your post that you were not clear about exactly what he was asking.

In my first post, I was indeed speculative. Not as to what the possible solution may be (that was made quite clear by the topic), but instead the purpose behind this.

Quote from: Yegg on May 16, 2009, 11:50 AM
I guess you're also not aware that people see this site in Google and can often have a problem solved by reading the posts on here. The topic isn't ancient and at least more valid infotmation was tossed in.

No, I'm perfectly aware of this. I do have confidence in googleers, however. They probably can infer from the first post all the obstensibly apparent information you "added" to the discussion.

Quote from: Yegg on May 16, 2009, 11:50 AM
Way to waste a post.

touché!

Quote from: Yegg on May 16, 2009, 01:28 AM
I figured since he already bumped it, it wouldn't be as bad . Not to mention, the activity in the forums still isn't all that great, but I do see a few new members around now.

But it is just as bad. Remember how I said that stupid posts are better than no posts? I was dead wrong. It's better to burn out than fade away. Please stop posting ambiguous, no-brainer shit, and preserve the post quality, Yegg!
Not to mention the aforementioned question had been answered by the FIRST post (my own). The OP hasn't responded, meaning he had already solved the problem a long time ago and your posts here are just dead unnecessary.