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.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
1
General ENIGMA / Re: Enigma allow to edit game maker projects???
« on: December 15, 2014, 05:18:44 pm »
We strive to stay up to date with the latest versions of Game Maker. The latest version of LateralGM (the actual GUI - enigma is just the compiler) should be able to load your games just fine. Please let us know if you run into any issues.
2
General ENIGMA / Re: Improving rooms editor
« on: December 15, 2014, 07:52:29 am »
Good work. The titled panel is a good idea. Also, ensure that the checkboxes are visually dependant. That is, when the first one is checked, the second one is grayed out and unchecked.
3
Proposals / Re: Improving tiles editing
« on: December 08, 2014, 02:20:57 pm »
Looks OK to me.
Just curious, any chance we could turn it into a Combo Box with all of the current layers? Or would that be too much work (e.g. no easy way to get all of the layers currently in use without iterating over all the tiles)?
Just curious, any chance we could turn it into a Combo Box with all of the current layers? Or would that be too much work (e.g. no easy way to get all of the layers currently in use without iterating over all the tiles)?
4
Developing ENIGMA / Re: LateralGM 1.8.6.828
« on: November 14, 2014, 03:35:59 pm »Unfortunately there's not a whole lot of customization that can be done with the Save dialog, so that's about the best I could do. The two areas are Format and Filter. The radio buttons specify the format, and are the only important ones. The dropdown at the bottom is only a filter, which filters which files are displayed - you can leave it as the default and it will save your file just fine.Quote* Save and load dialog warnings do not recognize extensions and file filters are not consistent among a lot of dialogs, needs cleaned up and fixed.I hope this involves checking why Save As has two places specify the format to use. It always bugged me. Ism mentioned something about it years ago, but I don't remember if it was in defense for that decision or not. Right now I don't know which of them are actually used, or even if both somehow is. So I always have to click the radio button "egm" together with dropdown menu "egm". Also, "egm" should probably be the default choice and be at the top.
The limitation of the Save As dialog is that the dropdown at the bottom, Filter, is always there and can only be used for that purpose. So I can't remove it, and I can't use it to replace the radio buttons.
EGM should be the default option if you load an EGM file. Otherwise, it defaults to an LGM format for compatibility purposes. I propose a setting for it.
5
Issues Help Desk / Re: LateralGM seems to have just... stopped compiling?
« on: November 09, 2014, 02:21:42 pm »
Since when did LateralGM start compiling?
6
Developing ENIGMA / Re: LateralGM 1.8.6.79
« on: November 09, 2014, 01:31:39 pm »Quote from: egofreecan't reproduce the error anymore. But why this event selector is in the main toolbar ? It's only for objects. It should be in the objects window. If you don't have an object open, it can't be used. This doesn't seem logical to me. This icon seems useless to me in this place. It is also displayed when you are in the objects events and you click on the modify button.It has been in there since LGM was first started egofree, it's kind of unique to the application, occasionally I click on the button as well to get the panel. If you think it should be removed you should discuss it with everyone else, I personally don't have an opinion on it either way because if you don't use it, it's not in your way so it shouldn't bother you.
Actually the Event Selector has a bit of a history behind it, and has changed a lot through each of the LGM releases. Originally it behaved very much like GM's, but we figured we could do better, and a few ideas were thrown around and some experimentation was done. What you're seeing now is really just the latest incarnation, and can certainly be changed.
The button is one of the newest additions, and even it has changed a bit, moving around and getting new icons.
I certainly agree that it doesn't make sense for it to be present when there are no Objects to select Events for, but that said, removal of the button on such a main interface as the Toolbar might be a little too overt. I could be wrong. Feel free to try it out and keep it if you think it works. Fortunately the location of the button is very unobtrusive, so we don't have to worry about other items shifting.
7
Developing ENIGMA / Re: LateralGM 1.8.6.731
« on: October 30, 2014, 01:23:01 pm »
Upon further review of the GPLv2 (and discussion with Josh), I retract my request to revert the introduction of GPL2 code (specifically the modified RTF Editor code). The code can stay.
GPLv2 section 6:
This means that the code must remain GPLv2 only and modifications to it must remain GPLv2 as well. However, the code can still become a part of LateralGM as that prohibition was not made until GPLv3 (with the "tivo" clause).
I look forward to release.
GPLv2 section 6:
Quote
Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
This means that the code must remain GPLv2 only and modifications to it must remain GPLv2 as well. However, the code can still become a part of LateralGM as that prohibition was not made until GPLv3 (with the "tivo" clause).
I look forward to release.
8
Off-Topic / Re: GMS prices up again
« on: October 30, 2014, 10:26:24 am »
More information here: http://help.yoyogames.com/entries/102854766-YYC-and-Pricing-Changes-November-2014
9
Proposals / Re: New Theme for LGM?
« on: October 29, 2014, 02:52:56 pm »
Most authenticated video games require that your password contain at least 2 female characters.
10
Developing ENIGMA / Re: LateralGM 1.8.6.724
« on: October 28, 2014, 01:36:02 pm »
Just a reminder that commit 96349086834 should be reverted as it contains code that is not compatible with our license. Please do so before making another release.
11
Proposals / Re: New Theme for LGM?
« on: October 27, 2014, 09:51:48 am »
I'd do it but sourceforge won't let me log in and doesn't seem to want to send me an email to retrieve/reset my password.
Edit: Done. As a reminder, sourceforge requires that your password be exactly 10 characters long, the first character must be an uppercase letter, the next 5 must be a dictionary word, followed by one of the ten symbols above the number keys, and then the remaining 3 must be a prime number. Also, your email address must contain no capital letters.
Edit: Done. As a reminder, sourceforge requires that your password be exactly 10 characters long, the first character must be an uppercase letter, the next 5 must be a dictionary word, followed by one of the ten symbols above the number keys, and then the remaining 3 must be a prime number. Also, your email address must contain no capital letters.
13
Off-Topic / Re: Tips for making an IDE?
« on: October 27, 2014, 09:42:14 am »
LGM wasn't built with Plugins in mind. When I started the project, I had no experience with plugin APIs, nor did I have any clue how I would apply it even if I did. Once it started to get to the point where I wanted plugins to be possible, I started refactoring some of the core parts, and adding hooks. That said, the plugin-ability of LGM is limited, and a bit of it has had to be refactored every now and then to allow plugins to do more things as they crop up.
So while there's a lot to be said about plugin-ability, it's not completely necessary. It might save you some strife later trying to implement plugins, but I'd say that the refactoring I did for LateralGM at that time was quite enjoyable.
Also, as far as thinking everything through goes - requirements change as you develop. You can't expect to lay out the entire blueprints up front and then just code monkey away at it. Lay out the groundwork first, develop it, and then figure out what parts you need next. LateralGM started with just a non-functional menu and a non-functional resource tree. That was it. That was the first prototype, and it was quite popular. Each part I added to it after that I made sure to put a lot of thought into and fully thought out the structures that I would need to do it. That first resource tree wasn't just a non-functional resource tree. It was a fully structured resource tree, with a data model behind it that actually reflected the state of the game that was in memory. The second prototype simply hooked in the code to load a game (.gm6) into that pre-existing memory structure. And the tree immediately reflected it. No fancy bells and whistles, just core functionality.
So while there's a lot to be said about plugin-ability, it's not completely necessary. It might save you some strife later trying to implement plugins, but I'd say that the refactoring I did for LateralGM at that time was quite enjoyable.
Also, as far as thinking everything through goes - requirements change as you develop. You can't expect to lay out the entire blueprints up front and then just code monkey away at it. Lay out the groundwork first, develop it, and then figure out what parts you need next. LateralGM started with just a non-functional menu and a non-functional resource tree. That was it. That was the first prototype, and it was quite popular. Each part I added to it after that I made sure to put a lot of thought into and fully thought out the structures that I would need to do it. That first resource tree wasn't just a non-functional resource tree. It was a fully structured resource tree, with a data model behind it that actually reflected the state of the game that was in memory. The second prototype simply hooked in the code to load a game (.gm6) into that pre-existing memory structure. And the tree immediately reflected it. No fancy bells and whistles, just core functionality.
14
Off-Topic / Re: Tips for making an IDE?
« on: October 23, 2014, 09:14:26 am »
Founder of LateralGM here. Thought I'd give my two cents on my methodology that helped get LateralGM to where it is today.
I like to run things by learning from the mistakes/failures/shortcomings of others. Game Maker doesn't work on Linux? I'll make mine work on Linux. G-Java evaporated from massive feature creep? I'll avoid features and focus on core functionality. This methodology reflects in all of my projects.
That said, one of the most common mistakes I have seen here in the ENIGMA umbrella community (at least, in the years when I was mostly active) is starting a project with features (massive feature creep from the beginning). Not in ENIGMA itself, but in side projects, and especially IDEs. Don't get me wrong, every project requires an idea - something new - a feature, but many projects here get tied up in features and leave the core functionality and bugs to rot in the gutter. And that's the last you hear of those projects - they evaporate in a brilliant burst of colorful features with no substance.
As such, I always advise people starting new projects to identify a core set of features, the "idea", and build the functionality for it. Focus on the core - the meat and bones - the part that actually gets stuff done - function over fashion. There will be plenty of time to add pretty bells and whistles later, AFTER the core functionality is done.
As you're developing the core functionality, you'll think up a bunch of new features that would be neat to add to the project - features that you probably wouldn't have thought of if you hadn't focused on the core. That's great, write them down in some central place with all the rest of you feature ideas. You can work on them later, when you're actually doing features. Keep them in mind while you're building your project so you know to build certain things more modular than they have to be so that those features are easier to implement later.
As for each idea, feature, etc (the language, the file format), do take some time to flesh it out, and find someone else to bounce ideas off of. If you keep revisiting some piece of code after the fact to add something you missed, the code will quickly start to deteriorate into something ugly and unmanageable. Refactoring is always an option, but code that's been touched up a lot of times tends to have its ugly greasy fingers in everything, making refactoring really difficult because you find yourself breaking a lot of other things. Think it out first, define the core set of functionality, and then implement it. You'll be very pleased with the result, and with a bit of luck, you'll never have to touch it again (until someone decides they want to change the code formatting...).
That's my advice. The world needs more people who take the time to do it right.
I like to run things by learning from the mistakes/failures/shortcomings of others. Game Maker doesn't work on Linux? I'll make mine work on Linux. G-Java evaporated from massive feature creep? I'll avoid features and focus on core functionality. This methodology reflects in all of my projects.
That said, one of the most common mistakes I have seen here in the ENIGMA umbrella community (at least, in the years when I was mostly active) is starting a project with features (massive feature creep from the beginning). Not in ENIGMA itself, but in side projects, and especially IDEs. Don't get me wrong, every project requires an idea - something new - a feature, but many projects here get tied up in features and leave the core functionality and bugs to rot in the gutter. And that's the last you hear of those projects - they evaporate in a brilliant burst of colorful features with no substance.
As such, I always advise people starting new projects to identify a core set of features, the "idea", and build the functionality for it. Focus on the core - the meat and bones - the part that actually gets stuff done - function over fashion. There will be plenty of time to add pretty bells and whistles later, AFTER the core functionality is done.
As you're developing the core functionality, you'll think up a bunch of new features that would be neat to add to the project - features that you probably wouldn't have thought of if you hadn't focused on the core. That's great, write them down in some central place with all the rest of you feature ideas. You can work on them later, when you're actually doing features. Keep them in mind while you're building your project so you know to build certain things more modular than they have to be so that those features are easier to implement later.
As for each idea, feature, etc (the language, the file format), do take some time to flesh it out, and find someone else to bounce ideas off of. If you keep revisiting some piece of code after the fact to add something you missed, the code will quickly start to deteriorate into something ugly and unmanageable. Refactoring is always an option, but code that's been touched up a lot of times tends to have its ugly greasy fingers in everything, making refactoring really difficult because you find yourself breaking a lot of other things. Think it out first, define the core set of functionality, and then implement it. You'll be very pleased with the result, and with a bit of luck, you'll never have to touch it again (until someone decides they want to change the code formatting...).
That's my advice. The world needs more people who take the time to do it right.
15
Proposals / Re: Request
« on: October 22, 2014, 04:13:46 pm »
If you seriously wish for this, please private message an administrator of these forums, such as myself or Josh, and we can ban your account, host, and/or ip for a fixed period of time.