Ethernaut

Forum Replies Created

Viewing 15 posts - 256 through 270 (of 288 total)
  • Author
    Posts
  • in reply to: Clear errors and debugging #3839

    Ethernaut
    Participant

    It never shows up, and I get weird visual glitches (hovering the mouse over menus causes them to flicker) until I restart Ted. Again, using the side Files panel works fine, this only happens using “File/Open”

    Here’s a video of what happens:

    https://dl.dropboxusercontent.com/u/446189/monkey/tedFileOpenBug.mov

    in reply to: Clear errors and debugging #3837

    Ethernaut
    Participant

    Opening a file from the “Files” side panel works fine, it’s just when I use the file open dialogue that the file refuses to show until I restart Ted2.

    Even doing “open project” doesn’t work until Ted is restarted.

    in reply to: Clear errors and debugging #3836

    Ethernaut
    Participant

    Monkey2 1.0.5, OS X El Capitan 10.11.6. But I’ve been having this issue for quite a while with previous versions.

    I wasn’t sure what the state of Ted was in for OS X yet, so I never filed a bug.

    in reply to: Clear errors and debugging #3833

    Ethernaut
    Participant

    Yup, I’ve been using Mollusk as the ide.

    I haven’t had a lot of luck with Ted2 in OS X. If I run the Monkey2 (Macos) file under the main folder I can’t even open a file. Running ted2_macos under bin gets me a little further, but not much. I can open files, but they don’t show until I close Ted and reopen it.

    I’m checking the same error now with Ted2 debugger running, pretty cool!
    Thanks!

    in reply to: Generics puzzle #3278

    Ethernaut
    Participant

    At the moment I’m just trying to learn, and this seemed like a good “stress test” for the technique. I had never used Generics before, and I like objected oriented style a lot, so this felt like a gap in what I could do.

    The particular case that prompted me to use this (not my test example code) can be solved with casting, but it’s a method that would be called a lot and I’d rather avoid casting if possible.

    My next step is to learn interfaces properly. I understand how they work, but I’ve never thought of a practical situation where I’d rather use interfaces than classes. Also keep in mind that I’m an artist, not a programmer, and was never formally taught any of that, so I really appreciate that M2 is simple enough for me to learn it but still offers those possibilities.

    Thanks!

    in reply to: Generics puzzle #3273

    Ethernaut
    Participant

    Yes! That’s exactly what I’m looking for.

    Thanks Mark, I also ran into the cyclic error when I tried something similar and thought it was actually invalid.

    in reply to: Collision module and performance #2695

    Ethernaut
    Participant

    That’s great, thanks! I’ll dig into that gameobject code and see how I could adapt it as soon as I find a bit of time again.

    Just out of curiosity, I see that you added a lot more classes and stuff, but has the collision code changed much since last month’s commit (which is what I’m using currently)?

    I think I’ll go with a “transform” object just to keep that stuff separated from entity events and components, and I’ll handle the transform inheritance and collisions through the transform class. Thanks for sharing!

    in reply to: Collision module and performance #2672

    Ethernaut
    Participant

    So I’ve found a little bit of time to play with the collision module, and I have to say it’s working great!

    My next step is to try to use this with my own entity system. In my old one, each entity used to have a “Transform” object that provided much of the functionality you already have in tlBox, like coordinates, dimensions, moving with collision, etc., so I’m going to just use tlBox instead this time.

    There’s one little thing I wanted to ask what’s the best way to implement: hierarchies, so that moving the parent moves all its children as well. Notice that in this case, objects need to store their local coordinates, and then calculate the world coordinate before they can do anything useful.

    Should I add a step somewhere that adds the coordinates together on every frame before displaying and checking collisions? Os is there a better, built in way to do that?

    Thanks!

    P.S. Here’s a quick test I did to get my feet wet:

    in reply to: Developing modules in parallel with a game #1815

    Ethernaut
    Participant

    Thanks, I was thinking about settling with something like that.

    Also, to help me keep development folders for modules outside M2’s folder, I made this shell script that performs some basic checking, clears the module’s folder inside M2, copies the new files to the appropriate folder and compiles it, all in one easy command. I realised this would be useful since I had to run mx2cc anyway to compile the module, even if M2 supported symlinks.

    Hopefully this can be useful to someone else:

    https://github.com/DoctorWhoof/makemod/blob/master/makemod.sh

    I would love if someone with experience in shell scripts takes a look at this for anything that could be improved, especially safety (my first versions used to wipe the entire modules folder when no arguments were given…)

    in reply to: PixMap->Image bug #1765

    Ethernaut
    Participant

    I don’t think it’s a good idea to create a pixmap and an image from the pixmap every frame specially of that size

    Agreed, if all you want to do is draw to a texture, try using an Image Canvas. There’s an example in the Bananas folder.

    https://github.com/blitz-research/monkey2/blob/master/bananas/rendertoimage/rendertoimage.monkey2

    Also, make sure you use the TextureFlags.Dynamic flag on that texture when drawing to an image canvas that is updated every frame.

    in reply to: Monkey 2 examples github #1736

    Ethernaut
    Participant

    Those are great, thanks! It would be nice if the Monkey 2 page had some sort of “learn” section with links to examples like these.

    I, for instance, had no idea you could create timers like that. 🙂

    in reply to: V1.0.0 now out and hearts are back! #1455

    Ethernaut
    Participant

    Me, me! I want a heart too!

    in reply to: First Impressions #1194

    Ethernaut
    Participant

    Of course when you use type inference like this you always have to assign a default value to the variable, but I feel like that is actually easy to understand when you look at someone else’s code.

    Oh, and I’ve been using Mollusk as the IDE. Doesn’t officially support M2 yet, but it works pretty well already.

    in reply to: First Impressions #1192

    Ethernaut
    Participant

    I need an editor with % $ and and # keys mapped to :Int :String and :Float

    You may wanna try using := for variable assignments, like:

    in reply to: mapping input controls to key #1167

    Ethernaut
    Participant

    Although it’s one of those things you don’t forget once you learn it, I feel like it would be a more intuitive/familiar design if instead of using “New AppInstance”, the command was “Mojo.Init()” or “App.Init()” or something like that.

    It would be cool if the App.Run() ran automatically somehow as well. Monkey 1’s simplicity of use is a good design target for me.

    Actually, I wonder why Mark didn’t create an App class that handles the Window and all the initialization like it does in M1. The new way offers a lot of control, but is also more complex and has more room for error. I feel that it could be an option alongside a simpler M1 style App class as the main option. Maybe it’s planned for the future?

Viewing 15 posts - 256 through 270 (of 288 total)