Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Blizzard

Pages: [1] 2 3 ... 922
Nice work!

Script Requests / Re: Mrmx-os script to can use the keyboard
« on: May 17, 2017, 08:37:17 AM »
Maybe the input box is set to use a weird font. :/

Script Requests / Re: Mrmx-os script to can use the keyboard
« on: May 16, 2017, 07:39:40 PM »
That's weird. The base RMX-OS has a custom input module included there. It should work. I really don't know.

Script Requests / Re: Mrmx-os script to can use the keyboard
« on: May 16, 2017, 07:46:24 AM »
Did you click on the input box? There should be a caret blinking.

Chat / Re: Your Life Here
« on: May 16, 2017, 07:40:32 AM »
Congratz! :D I'm really happy for you! :D

Lexima Legends IV - Chaos Project / Re: Legion in Warrior Mode
« on: May 14, 2017, 12:40:03 PM »
So, I'm there again. >_> I'm testing Zero Hero and I' just beat Doom Caller. Reading my first post again I'm really not up for doing this at Jason 37, Endout 38, Lucius 35 and Ariana 41. xD I'll at least wait until I get Sydon or something (right now I arrive in Mandora). The EXP from the other bosses and the decent stuff I got from the rewards should be enough to keep me afloat at least until chapter 9. Phoenix Sword especially will be useful at the Mountains of Slumber.

RMXP Script Database / Re: [XP] Blizz-ABS
« on: May 14, 2017, 12:32:39 PM »
Your biggest challenge is actually the fact that a lot of keyboards have a limit to how many keys you can keep pressed at once.

Script Troubleshooting / Re: Problem with my pathfinder
« on: May 12, 2017, 08:26:37 AM »
Yeah, it performs faster because of its greedy nature. xD When it works like that, some paths will be faster, some will be slower depending on how straightforward they are.

I think that you shouldn't make it more general. Algorithms and generalizations are fine, but your should use the specifics of a problem to optimize the shit out of it. Since we have a Cartesian coordinate system and it's not likely to change, we should use that fact to make the implementation faster.

Sea of Code / Another reason why WinRT is shit
« on: May 11, 2017, 11:13:20 AM »
So today I had to work with WinRT again. It was with sockets and WinRT has their own socket implementation. So no c-style sockets are allowed.

The main first issue is the problem that WinRT can't handle reading an "endless" stream from a socket. The problem point is the IInputStream::ReadAsync() method (because everything in WinRT MUST be async). Once you run the method, you can a special AsyncOperation object. You can assign a "Completed" delegate to that object and once WinRT reads at least one byte from the socket, that delegate will be called. Now, the issue here is that if there are no bytes available for reading, WinRT will wait an undefined period of time. This can be a timeout of apparently 180 seconds (somebody mentioned that information somewhere on Stack Overflow, I don't know if it's correct) or basically indefinitely. The catch is that there is no way to ask WinRT whether there are any bytes available for reading. So if you want to keep reading for a while or are wrapping sockets into a higher level system, you are fucked.

Now hold on. Yes, this is nasty, but this is only the introduction into the probably biggest async API design flaw I've seen in my entire life. Prepare yourself for a next-level fuck-up of multi-threaded programming.

So I kept thinking about this issue and an effective way to circumvent it. And I came up with something. I decided to use a buffer which I would then check for data in my main thread method call where I want to receive the data while I just keep calling ReadAsync() and let it do its thing.
Since we're working with async calls here and shared data between what appears to be separate threads (waaaaaait for it...), obviously this data needs to be protected with a mutex (this is a locking mechanism that prevents threads accessing the same data at the same time since threads are undeterministic). So I did that. But suddenly I would keep getting deadlocks sometimes (this is when an already locked mutex is locked in the same thread again and basically means freezing of the thread). I was surprised how this was possible. And then it hit me. I did some testing to confirm my theory and I was right.

You see, usually that "Completed" delegate callback should be called from a different thread. So using a mutex to protect data is absolutely necessary. There is no other way. And most of the time that's exactly what WinRT does. Except when it doesn't. It's possible that ReadAsync() actually finishes before you assign the "Completed" delegate. And you know happens when you finally do assign it? The callback gets called immediately IN THE SAME THREAD WHERE "Completed" WAS ASSIGNED! So if you locked a mutex before assigning "Completed" and then you have to lock that mutex withing the delegate that was assigned to "Completed", you will get a fucking deadlock! Fuck you, Microsoft! Fuck you!

The good news is that I was able to resolve the deadlock by unlocking the mutex before assigning "Completed". But fuck Microsoft and their asynchronous-but-sometimes-it-isn't API. >:(

Here's the final code so you have an easier understanding what I've been struggling with. I added a few comments to make it easier to understand

Code: [Select]
// this workaround is required due to the fact that IAsyncOperationWithProgress::Completed could be fire upon assignment and then a mutex deadlock would occur
hmutex::ScopeLock _lockAsync(&this->_mutexReceiveAsyncOperation); // ScopeLock makes sure the mutex is unlocked when this method finishes (very useful when throwing exceptions, etc.)
bool asyncOperationRunning = (this->_receiveAsyncOperation != nullptr);
_lockAsync.release(); // has to unlock that mutex again...
if (!asyncOperationRunning)
this->_receiveBuffer = ref new Buffer(this->bufferSize);
this->_receiveAsyncOperation = inputStream->ReadAsync(this->_receiveBuffer, this->bufferSize, InputStreamOptions::Partial);
this->_receiveAsyncOperation->Completed = ref new AsyncOperationWithProgressCompletedHandler<IBuffer^, unsigned int>(
[this](IAsyncOperationWithProgress<IBuffer^, unsigned int>^ operation, AsyncStatus status)
if (status == AsyncStatus::Completed)
IBuffer^ _buffer = operation->GetResults();
Platform::Array<unsigned char>^ _data = ref new Platform::Array<unsigned char>(_buffer->Length);
DataReader^ reader = DataReader::FromBuffer(_buffer);
hmutex::ScopeLock _lock(&this->_mutexReceiveStream);
this->_receiveStream.writeRaw(_data->Data, _data->Length);
hlog::errorf("OK", "async data: %d", _data->Length);
catch (Platform::OutOfBoundsException^ e)
hmutex::ScopeLock _lock(&this->_mutexReceiveAsyncOperation); // ... because this lock here might as well happen in the same thread as the one at the beginning of this code and cause a deadlock
this->_receiveAsyncOperation = nullptr;
this->_receiveBuffer = nullptr;
catch (Platform::Exception^ e)
return false;
... // down here I lock this->_mutexReceiveStream and read from this->_receiveStream, but it's not relevant to this issue

Script Troubleshooting / Re: Problem with my pathfinder
« on: May 11, 2017, 10:35:30 AM »
This isn't really A*, but more of a modified Dijkstra.

That's what I meant.

You mean because of this?

Code: [Select]
key = {|a, b|
        a[2] > b[2] ? 1 : (a[2] < b[2] ? -1 :
        (Math.hypot_squared(a[0] -, a[1] - <=>
        Math.hypot_squared(b[0] -, b[1] -}

I'm first checking the already known cost before checking the heuristic cost. So you think I should check them together?

Script Troubleshooting / Re: Problem with my pathfinder
« on: May 11, 2017, 07:51:47 AM »
That's true, I did optimize my script in such a way.

I think you're wrong about Dijsktra. The thing with a Cartesian coordinate system is that coordinate distances are consistent throughout the whole grid so technically the heuristic of the xy coordinate difference is actually not just an cost estimation, but a consistent cost. I used that fact to make the Dijkstra's algorithm implementation faster and that's basically what A* is. It just uses a heuristic like that to decide which nodes to check first.

Script Troubleshooting / Re: Problem with my pathfinder
« on: May 10, 2017, 08:35:32 AM »
I'd have to go in-depth with your algorithm to figure out what's wrong. xD

A* is actually just a modified Dijkstra's algorithm. Instead of going through all nodes, an x,y coordinate heuristic is used to check possibly favorable nodes first.

Script Troubleshooting / Re: Problem with my pathfinder
« on: May 10, 2017, 06:50:17 AM »
Actually looking up a different path finder might be a good idea since you can figure out how the other one is implemented.
That being said, I vaguely remember that you're supposed to use heuristic cost to the new node from the current plus the movement cost to the current node. I haven't taken a good look at your code yet though.

General Discussion / Reboot Develop 2017 "Making a better RPG"
« on: May 09, 2017, 08:53:51 AM »
Tim Cain from Obsidian Entertainment talked about RPGs this year at Croatia's Reboot Develop. It was a pretty great talk. And you're lucky! They recorded it. xD

There are some really good points for everybody who wants to develop RPGs. One of the points that really resonated with me was avoiding numbers which seems counterintuitive since numbers are kind of a core thing in RPGs. But the thing is: they are not. I haven't watched the video so I hope you can see the slides properly since there are some important visual things that he shows.

BTW, the actual talk is less than an hour even though the video is 2 hours long.

EDIT: Quickly glanced through the video and yes, the slides are properly visible. Have fun!

Lexima Legends IV - Chaos Project / Re: Bugs Megathread
« on: May 06, 2017, 06:27:39 AM »

Lexima Legends IV - Chaos Project / Re: Bugs Megathread
« on: May 05, 2017, 12:41:59 PM »
Screen shaking near borders of maps (Hard to see but yellow line flickering in and out of screen at bottom)
(click to show/hide)

KK20! >8U You said you fixed that.

Chat / Re: Your Life Here
« on: May 03, 2017, 08:33:10 PM »
That's fantastic! I'm glad things are finally working out for you. :)

Yeah, the sleep thing can be nasty. I just got out of a weird period where I had trouble sleeping all night even though I barely consumed any caffeine. I would go to sleep normally so that I can get 8 hours of sleep. But instead I'd wake up easily 7-8 times during the night being either thirsty or needing to go to the toilet. On top of that I would wake up an hour before my alarm usually goes off and then I couldn't fall asleep again. There was the daylight saving switch around that time, but the clock was moved one hour forward, not backward. #_#

RMXP Script Database / Re: [XP] XP Ace Tilemap
« on: May 03, 2017, 06:48:00 PM »
So, we've been hunting a memory leak for the past 2 hours and it turned out to be this script. Your C code seemed fine so I started digging in Ruby to see what could be causing the issue. And I found it. xD You're missing this in Tilemap#dispose:

Code: [Select]

But it's is somewhat unsafe to use code like this. If the Tilemap isn't disposed explicitly, the memory will remain allocated and not collected by the GC. IDK if you maybe should change this implementation entirely and just throw out that CallBackController class. Your call.

Chat / Re: Your Life Here
« on: May 02, 2017, 02:20:44 PM »
Apparently caffeine only increases alertness, but doesn't really do much to improve cognitive functioning. In other words, it just makes you not feel the effects of being tired. Of course in the end it fucks up your sleeping cycle since you can't fall asleep even if your brain is basically in derp-mode already. I've experienced this myself with burnout and higher doses of caffeine. Those "higher" doses aren't even that high. Maybe 100mg-150mg which is actually just one cup of a stronger coffee type or 2 Red Bulls (1 Red Bull = 80mg). The energy I usually got from drinking Red Bull or Coke was probably just the sugar rush. >.< So yeah, caffeine isn't a solution.

You also mentioned the duality of seemingly opposite traits. I've noticed that in some people recently. e.g. I know a girl who's pretty low self-esteem in general, but yet she's also confident. It's quite interesting to see how somebody can exhibit two seemingly opposite traits. xD

Well, I'm glad that you're feeling better now and that things are getting better. :)

Pages: [1] 2 3 ... 922