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
Script Requests / Re: Simple Crafting Demo/Script
« on: August 09, 2017, 10:58:54 PM »
I once made one where you could do some crazy things. Can't remember the name, just look it up in the database.

Alright, here we go. :D

About the infrastructure...

I do understand that argument and it's a valid one until you take a step back and look at the situation from a different perspective. In Europe much smaller ISPs have manage to rack up Internet speeds to such high levels, that the EU recently passed a new regulation (or will pass very soon) that Internet speeds by ISPs have to offer a package that has at least 100Mb/s. Don't take my literal word on this though, I don't know the details and may have mistyped something. Still, if so many small companies across dozens of EU countries can handle this, it's absurd to think that the massive ones in the US cannot.

I will add my point about stifling innovation here, because it makes sense within the context of my arguments. I actually agree with you there. I don't think that abandoning net neutrality will stifle innovation. It will, however, stifle the future increase in Internet speed. Why? Simple. If ISPs are already billing customers and content providers left and right, why bother increasing speeds if you can increase fees and nobody can do shit about it? And if they wanted to increase speeds either way, they wouldn't be lobbying against net neutrality in the first place. So they are obviously just trying to extort more money from wherever they can.

Just an additional note: Overselling is bad IMO if you do it with too much. But a drop in 10%-20% of speed during rush hour is acceptable IMO. Again, this is just my opinion and some people might disagree.

About the free market and government regulations...

A completely free market is not a good thing either. Each time we didn't regulate stuff, things spiraled out of control. Every. Single. Time. A free market's natural progression is towards monopoly. Sure, sometimes we end up with a few big players, but just as often (if not even more often) we end up with one big player. That being said, regulations are a double-edged sword. They can prevent big companies from abusing their influence just as much as they can drive small companies out of business. e.g. If the government passes a law to increase the minimum wage, some small companies won't be able to afford this and have to close down while the bigger ones will have to fire people and automate more things (which isn't necessarily a bad thing, but that's for another discussion). That's why I think that net neutrality is the best solution, because it provides an equal ground for everyone and no one can be privileged.

IMO regulations should prevent unfair advantages and try to provide an equal opportunity for everyone while keeping a balanced free market where a higher quality service can thrive and drive competition out of business. It may sound harsh, but it's better for all of us in the long run.

Other arguments

Abandoning net neutrality could be a good thing in the long run, but the problem is that ISPs are catering the entire thing to what suits them instead of to what is best for customers. They don't want any regulations or anything. They just want more power and control over information to be able to make more money off of it. If there were better regulations (read: ANY ACTUAL regulations), this could actually help the companies while still treating customers and content providers fairly. The problem here is that at some point these regulations would have to be removed or at least loosened to allow a better free market yet again. And since we're going in circles at this point, I think that just keeping net neutrality and simply declaring it as a public good is the better option in the end.

All this being said, I do believe that we still need some extra regulations for companies while keeping net neutrality intact. As you already mentioned, there were cases with Comcast strongarming Netflix, etc.

Thanks for stimulating my gray matter on this matter again. ^_^

Resources / Re: problem to open mrmx-os
« on: June 23, 2017, 10:48:43 AM »
There is an issue with the input module that requires a newer RGSS DLL. :P

Resources / Re: problem to open mrmx-os
« on: June 23, 2017, 07:40:36 AM »
The Steam version / Humble store version and the official version from their website should work fine.

RMXP Script Database / Re: [XP] XP Ace Tilemap
« on: June 23, 2017, 07:39:36 AM »
Eh, it happens. I've uploaded tons of faulty demos in my time. xD

Sea of Code / Randomness and distribution
« on: June 14, 2017, 08:06:33 PM »
Those of you who worked with C or C++ probably know that on Win32 systems that the macro RAND_MAX is only 32,767 (0x7FFF). This causes problems if you want random values higher than that since due to the distribution, there are values that you will never get.

e.g. You want 1,000,000. 1,000,000 / 32,767 ~= 30.52. That means that you can get a 0 or a 31, but never anything between these two numbers.

Now, you could take two numbers and sum them up or multiply them, but that breaks the equal distribution of numbers and some values will happen more often than others. It's easiest illustrated with a few small values. Let's take a range from 0 to 2 inclusive. All possible combinations:

0+0, 0+1, 0+2
1+0, 1+1, 1+2
2+0, 2+1, 2+2

If you take a close look at all possible combinations, you will notice that the results are not equally probable. 0 and 4 appear only once, 1 and 3 appear both twice and 2 appears 3 times as a result.

The only way to really handle this issue is to combine the values in a way that preserves the equal distribution. If we simplify the entire thing and say it's only possible to generate 1 bit randomly, we can get the values 0 or 1. Now if we do this procedure N times, we can get a number that consists of N bits and all numbers generated in such a way will always be equally likely to appear and the distribution will be preserved. Since we already have 15 bits (32,767) at our disposal to be generated, we can just generate this value twice and then just combine them by shifting one of the numbers to have a 30 bit value.

I implemented this in our foundation library, you can take a look here at line 46 and 47 (or just find "#define HRAND()" if the code has changed since this post was made):
I do casting to int64_t, because I have multiplication and division with another 32-bit int so nothing breaks. Incidentally I think this is the same reason why Microsoft limited RAND_MAX to 32,767 in the first place.

General Discussion / Re: How to Get Enterbrain's Software Free
« on: May 31, 2017, 08:10:13 AM »
Maybe we should even delete the topic.

This does NOT work anymore. Most (all?) of their software has been updated leaving this method unusable.

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.

Pages: [1] 2 3 ... 922