giga970

I'm following the development of this very closely and I'm very very excited. Also, thanks for adding in the LOC suggestion I submitted. It's nice to see the scale of a project like that, especially if you've been working on it for a long time.

I really, REALLY want to use Parakeet as my main editor for GM, but saving seems to be bugged up for me. Running Windows 7 Home Premium in Parallels Desktop virtual machine. I installed .NET 4.5 (running Parakeet 0.2.2.) I submitted a bug report, copied the error and took a screen shot. Some sort of NullReferenceError. I love the features you're putting into it, but it's important to make sure that something like that doesn't get goofed up; otherwise it's of no use to anybody.

 

Not trying to be a downer. Somebody's gotta report bugs. I can't help with development at this time, so this is my way of making Parakeet better.

This project is great. I've been waiting for something like this for a long time. Thanks for taking the initiative. I've had a lot of issues with the Studio IDE nearly-crashing all the time, and it's very very cool to see a new alternative available.

I absolutely love that you've placed constants in the resource tree. THANK YOU.

You could load additional sprites/backgrounds asynchronously between levels to minimize initial load time. Then you could be "finished" loading once the async event is triggered and you've saved the sprite or background(s).

It's considered bad practice because of the way computers work, and if you had a background in computer science you would understand why they removed the function for GM:Studio (aside from the logistics of actually getting it to work.)

Consider a programming language like Java, or anything C-based really. In order to assign a value to a variable (i.e. set x = 8) x must first exist, or at least be declared. In game maker, you can declare variables by typing "var x;" which will tell GameMaker, "Oh, I'm making a variable called x, but I'm not going to give it a value." That's completely okay. You're telling the computer to set aside some place in memory to keep x safe.

I don't know how they got "variable_local_exists()" to work, but my guess would be, "let's look around the memory we've allocated for GameMaker and see if we can find something called x." What happens if we have more than one x? Well we know that an "x" exists, but we don't necessarily know whether that's the x you meant to look for. On top of being complicated and programmatically awkward, "variable_local/global_exists" is probably pretty slow, and it's a bad practice in code because you can't perform this kind of check in most other languages (certainly not Java or C++). If you're searching through all your memory to find one variable, you're doing something wrong. There's a way to code this without having to use that function, and your code will be far more efficient without it. Computers nowadays are fast enough to do that kind of calculation, but if you had a MASSIVE surface and you calculated the time cost of the script on that surface with and without "variable_local_exists" I'd place a safe bet that your script without "variable_local_exists" would run faster.

TLDR; Real programmers don't use "variable_local_exists" because there's always a better way to do it.

I'm pretty sure ALT-Enter toggles fullscreen on Windows now, instead of F4. Not 100% sure, though.