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 - Goombert

Off-Topic / Re: The curse of being a very wealthy indie developer
« on: September 02, 2015, 10:47:36 AM »
I found the story interesting though nothing new. I've thought about this myself before, I think it's something we all think about at one point another if we were rich.

It some ways the thought depresses me but I would probably just continue to find more projects to work on. I've always had a money doesn't matter philosophy and that's the best way to look at life. It's not the answer to all your problems, just live your life the way you want and be happy with what you've done.

Proposals / Google Breakpad
« on: September 02, 2015, 08:56:49 AM »
This is a cool library used in Firefox, Chrome, and Google Earth. It allows you to build an executable with no debugging symbols, the library will generate crash minidumps. The debugging symbols are saved during compilation of the executable though. Later when a crash occurs a separate program can take the minidump and the debug symbols and put them back together again to create a human readable stacktrace. So basically you can build an executable without debug information and still debug it.

I think this would be something really useful to take advantage of in ENIGMA. It would allow our end users to make extremely efficient games but still debug them just as in every GM 8.1 or earlier GameMaker version. It would also give us extremely useful information when users report an ENIGMA crash to us on GitHub as we can cache and store the debug symbols for every release we've made or have them include it with the crash report.

Using it with end user games would be a little trickier though because it means when you release your game you have to hold on to a copy of your debug symbols and properly version your game. However I think I have already thought of a way around this. Since we already make use of zlib to archive the resources, we could also archive the debug symbols file right into the executable. While this would still increase the file size of executables to include the debug symbols the game would not run like shit because the symbols would be separated from the program code.

This would mean that anywhere a game is used it would run just as you would expect but you could also take any crash/minidump log it spits out and feed the executable and the dump file to a debugger to get a human readable stacktrace. We could also achieve GM8.1 and LGM style exception dialogs by just embedding it into every exe or make it an option if the users really care to squeeze out the few extra bytes in file size. Either way I think this could seriously improve the situation regarding debugging in both ENIGMA and its engine and end user games. I'd like to know what everyone thinks.

Developing ENIGMA / Migrate Releases
« on: September 02, 2015, 01:49:20 AM »
I want to propose this since I've been making more use of it in recent projects. When we archived the old LGM versions we stuck them in our dropboxes which is, despite me having created a shared ENIGMA dropbox, still subject to link rot. I never did attempt to migrate our old and new releases to GitHub because I never understood the feature until now.

Basically if we move all of the ENIGMA ZIP's, old LGM jars, and all those old revisions and packages over to the GitHub release pages we get static links.
For example:

Instead of what we have now on the LateralGM: Revisions Wiki page:

Notice how the GitHub version is not subject to link rot? This is by GitHub's own design for the very reason we are intending to use it. Using the GitHub release pages also allows me to archive the change logs in the description. This is important because our forum is also subject to link rot as topics are moved and the forum board evolves, people will still be able to find the change log well into the future (considering GitHub is probably more likely to be around in 10 to 20 years than we are). This also means we don't have to make so much use of third parties like dropbox since setting up proper file transfer to ENIGMA's server would be a lot of work and cumbersome to say the least (which is why we are still struggling to finish the EDC). This also means that every contributor can establish a release if they have appropriate access to the repository.

There are some things that need addressed. Primarily the GitHub release mechanism automatically versions the repository and detects change logs. So if you don't enter a description it automatically detects the changes made to the repository since the last release was made, which we can make more effective use of in the future. This will make our initial migration of the old releases cumbersome though as I'll have to paste all of the change logs there and you'll just have to ignore the one GitHub shows in cases where a change log can't be found (I have them for all of my releases just not LGM 1571), which is not that big of a deal. This also means however that ENIGMA needs to establish version numbering and so do all of the other projects including JEIE, etc etc.

Once this is done however I would update all the appropriate documentation on the Wiki and related links. I would not delete the old revisions archived on our shared dropbox but the Wiki and everything would be updated to reflect the new release process. I also would not delete the old revisions page right away until some point in the future when the links become broken or our shared dropbox has been fragmented.

I would continue to maintain the Extra Packages page for quick links to all of the latest releases. The page would just be updated with the rest of the Wiki.

I've experimented with archiving two old releases of LateralGM on its repository.

I also believe this would reduce the confusion of random people finding LateralGM through Google and not knowing where to download it. The GitHub release mechanism is pretty common and you know people have come to get used to it, myself included. It also makes formatting the change logs nicer by allowing us to use markdown and link to specific tickets instead of by URL like I do now.

I'd like to know what you all think about this, I think this is the way to go and I am looking to do all the footwork to make the change. I'd just like to take some feedback and suggestions on it first.

Also I will need additional privileges to a few repositories such as JEIE to do the releases which I asked IsmAvatar about before but never got a response, hopefully I can get a hold of her.

Edit: Actually it seems like it is possible when drafting the releases to base them on a certain commit, but I don't know how far back we'd have to dig. I could probably dig for all of the releases I made but maybe not the ones for 1.6 and 1.5 as they may not have been migrated from Sourceforge.

Programming Help / Re: date_date_string change format
« on: September 01, 2015, 11:51:34 PM »
Please follow Harri's advice, but also he is incorrect about these functions not being documented on the Wiki because they are (I documented every single one).

On a side note Harri, I am not sure if that function is a great idea because what if we do ever support a different language, shouldn't we need to define our own date/time formatting? Don't stress about it, just something I want to call your attention to. At the same time it doesn't matter because we could likely just add the C++ standard date/time formatting to the other programming languages and adopt it as our standard.

Developing ENIGMA / Re: Styleguide
« on: September 01, 2015, 11:47:36 PM »
Actually Harri, Josh already took the liberty of writing this all down, so you know what guys, let's table this discussion.

Here's what we are going to do:
* Link this page from the main wiki page under the contributions section (I already have).
* Try to persuade new contributors to follow these conventions and guide them if they need assistance in configuring their code editor.
* Do not over trivialize a pull request where the formatting is incorrect, just mention it as a side note, pull it and fix the formatting yourself so they know for a future patch submission. This way they will not be discouraged by the rejection of their first commit.
* The coding conventions can be followed loosely, just don't let it get out of hand.
* Continue to correct areas where the formatting is wrong. This includes a lot of places I may have touched because nobody ever really explained the coding conventions or why they are important to me.

Do not go crazy trying to run a formatter over everything like I suggested I was going to do, this problem has been enough of a distraction already from bigger things that need solved. Harri also mentioned that he's already fixed a number of formatting problems. Just please follow this advice as we continue into the future.

Quote from: TheExDeus
I didn't propose we make our own styleguide
I know, the reason I said that was because I didn't want you to get distracted, there's more important things, I just wanted your input.

Quote from: TheExDeus
Maybe I can merge my branch then. Or you checkout it, because it has a lot of changes.
That would be nice, when I have time I am going to run the formatter over LGM because it has gotten way out of hand and I let it get that way. Nobodies been in there to do some cleaning and now that I know how I am going to do that. But also I was going to address the issues you and egofree were having and fix any of the remaining JoshEdit problems cleanly if there are any. So it would be nice if you have whatever changes you've made into ENIGMA master so I can get a working copy set up and fix these other issues by like Sunday.

Quote from: TheExDeus
Maybe egofree's mentioned Atom could do it as it basically renders html.
I would use the feature if any editor ever added it. Egofree's suggestion would probably be the best because look at how Eclipse parses HTML and Javadoc's to provide documentation in the IDE from the source code (this was something we did want to do with LGM). An editor that can do that is the best place to implement what you want.

Quote from: egofree
This is a little bit off-topic, but since you are talking about text editor, there is a totally free and open-source alternative, which is is fine also : atom editor (  It has also tons of plugins available. (To install new ones : File->settings->packages).
Also, DaSpirit had me try Atom and iirc it didn't work very well and it was very laggy I believe because it's written in JavaScript. Don't take my word for it though examine the program for yourself. I really liked Sublime when I just tested it and its package management, but I recommend you support free and open source software over proprietary software such as Sublime.

Developing ENIGMA / Re: Styleguide
« on: September 01, 2015, 09:34:13 AM »
Alright, great thanks for the feedback some other things to consider:

I like the solution I mentioned above regarding tabs when tabs are used for normal indent and vertical tabs are used to create the columnar alignment, this makes it work with python.

In that picture it would mean "string s" whitespace would be replaced with a single preceding vertical tab, and all of the other lines would continue to be normal tabs.

Regarding Sublime, I haven't switched to it yet, but there is an elastic tabstops plugin for it:

I also got this FF extension which stops making the tab key change focus so it works nicely with, even though already had tab input support (depends on the website and how keen the developers are, stack overflow is a pain to format code)

Whether you use spaces or not though tab is still used for the indent so you can select multiple lines, code editing in browsers sucks either way you go imo.

Anyway I've personally gone 180 degrees back the other way I think to just tabs because I feel all of the advantages outweigh the benefits when properly configured and because of my above discoveries and that tabs separate model from view.

Anyway, not to be rude Harri, but to be honest, I don't want to do our own styleguide. Whether anybody likes Google's or not I don't really care, it's very popular and I feel just as comfortable working with it. So my vote goes towards us adopting the Google styleguide to make things easier for new contributors and because it is already widely adopted and has a number of extensions for many editors, plus it's what Josh and I already have configured on our computers and you do partially as well.

I'll wait and see what he says, if we get his seal of approval I'm checking out ENIGMA's latest branch and running over the whole code base with a formatter. Maybe though since you don't mind the elastic tabstops idea we could be a revolutionary project in using this coding convention and make it more popular, let's see what Josh has to say and egofree or anybody else feel free to weigh in too.

Edit: Also I love your idea about the code headers, definitely agree with you there. I also get kind of sleepy reading code with doxygen as well, this is why I like a class hierarchy view.

Developing ENIGMA / Re: Styleguide
« on: September 01, 2015, 06:31:00 AM »
Well, I'll be a monkey's uncle, you're right.

I wonder if it defaults when you open the editor or if it needs configured in Eclipse first like I had to do with the Google styleguide I needed for my other library. If it is the case of the former then that leads me to point out that I don't particularly like this style and I don't think Josh or anyone but IsmAvatar does, but I believe this has been mentioned before. In practice I would rather just keep it what it is then try to change it. However I do feel ENIGMA and LateralGM would benefit further if they used the same styleguide.

Regarding ENIGMA, since Josh works at Google, and the compiler has always been written with that style, I feel as though that's the one we should go with, at least for ENIGMA. The reason being is that Google has the styleguide well defined and you can even download an XML schema file for it to plug into Eclipse or other editors.

Still looking to see what everyone else thinks as I wouldn't want to make contribution difficult for everyone, I think this would actually make it easier and it's bugging me to the point I may check out the latest ENIGMA and clean it up if we can all decide. I am looking basically to get everyone's approval to enforce it since it seems egofree is comfortable with it, I am comfortable with it, and so is Josh. Using style formatters is not difficult but my only wish is that Josh would have sat me down and made me think about it before letting me contribute instead of just letting me ignore it. Anyway, most projects adhere to a styleguide at least to some degree, but ENIGMA straight up has nothing to the point the code is a complete mess, at the very least we need to define the indentation style.

Developing ENIGMA / Styleguide
« on: August 31, 2015, 09:00:14 PM »
This was always a huge problem when I began contributing to ENIGMA. Having to format and reformat code constantly. Recently I've taken the practice of using standard style guides for my projects and sticking to them.

I feel ENIGMA and LateralGM have suffered tremendously from the lack of an enforced styleguide. This post is not about tabs vs spaces but about using consistent formatting in both projects.

My personal preference would be the use of a mixture of space and tab indentations which I am conflicted on but have expressed in a 64Digits post:

I've been configuring my code editors to allow me to use a consistent coding style for multiple projects. I was simply reviewing some of ENIGMA's source code and stumbled upon the inconsistencies in formatting, caused by myself and a lot of others. You can see in the following screenshot some of the problems, some lines are indented using tabs and others with 2 or 4 spaces.

This makes it considerably difficult for contributors, including each and everyone one of us, whether we prefer tabs or spaces. The reason is simple and that is the lack of consistency. I would be able to work with either depending on what everyone else would prefer to use. But I think the quality of our code base could be seriously improved through the ratification of a standard coding style for the project with input from everyone. Please let me know what you think.

General ENIGMA / Re: Joshedit
« on: August 26, 2015, 05:50:43 PM »
I've got the solution to your temporary problems ego. Also I'm going to follow up with a private message to you to let you know what else I've been working on.

Quote from: TheExDeus
I can be less dirty, but I don't think it needs a billion features. Just make it load and compile egm. Compilation is done trough makefile flags anyway. The only thing CLI actually does is it parses EDL and then adds resources to the compiled exe.
Not so much about it being dirty as it is about making it long lasting, etc. Josh's library has something to do with parsing command line flags, you should ask him about it.

Quote from: TheEXDeus
It doesn't matter that much how it is saved inside egm as we can create the resource tree from a description file of some sort.
No I hate that, Josh doesn't like it either. The directory structure is already there. From a design perspective it should definitely be imposed by the IDE or the model's "view" as in MVC. A lot of IDE's also automatically sort your tree in alphabetical order and don't even give you an option.

Quote from: TheExDeus
And the bugs that threw exceptions are now gone. I only have LGM freezes and crashes without any kind of exception or error message.
I know I agree, I'm just saying that dialog was one of the greatest things that ever happened to LGM, it's one of my favorites actually. Probably my most proud accomplishment and the greatest thing about using Java as we almost 99% of the time know exactly what's causing an error, except the rare JNA cases where it gets mixed with native code.

Quote from: egofree
Well, the 'official' version of LateralGM available now on Github uses 'your' version of Joshedit, with pull requests not accepted by Josh. So it's not only about constants. Try to get LateralGM and Joshedit from Github and you will see it not will compile.
Taken care of, I've uploaded my last fork of LGM. I had this local on my disk and it's the last version I worked and I haven't touched it for a year. I uploaded it to ENIGMA's dropbox account. I tested it in Eclipse just now and it builds fine with JoshEdit, no need to check anything out, just import to your workspace. However I likely patched around shit waiting for Josh to merge my PR's which is something else I want to get to next.

Edit: I have no idea where to put this, but please continue to maintain the list of links for LGM's old revisions. These are good when people need to downgrade Studio projects or import corrupted GMK's etc.

Quote from: egofree
9 Months ago, i told you about the problems with Joshedit and you told me that you were too busy to fix it. That didn't prevent you to start DockFX. Of course, everybody has his own life, and Enigma is a free and open-source project, so nobody has to work on this project, but at least if you had time to do DockFX, you could have take time to fix your problems before leaving it, even if you were not motivated anymore by this project. To leave modifications in a open-source project with compile errors is not professional and don't show respect for other developers. :P If you really didn't have time to finish your work (i doubt it as you started DockFX), at least you could have reverted your changes in LateralGM. You left the problems with Joshedit but also reading of egm files broken ! At the same time to finish on a positive note about you, you made also an outstanding work on this project and an excellent support on this forum, and i thanked you several times about this.
You're probably right, that's why I'm not pointing any fingers. But also at the same time what am I supposed to do when Josh is working and doesn't have time to clean it up and merge it or explain what he's looking for to me? Nothing so I just get the "fuck it anyway" attitude. So I blame all of us. I <3 you guys, but I totally don't want to work on LateralGM.

Quote from: egofree
Also i worked hard last year to add multi-selection, and in the in end, they were never available to anyone, except on github. So i worked for nothing.
I don't think this is true I could have swore in the post where I was updating LGM's status last including the resource searching functionality that I had released a version with this included. I am pretty certain that is the case, if not, fuck, whatever, blame me I guess. :P

Quote from: TheExDeus
We could of done that, but as I lost interest in GM years ago I didn't do it myself. I have moved on from GM8.1 or any kind of GM at least 3 years ago when I started adding totally new stuff to ENIGMA. And I do it constantly now too. You can still remove all the non-GM stuff easily though as nothing there should be very integral to ENIGMA engine.
Quote from: egofree
In the end nobody seems to be interested by LateralGM anymore. That's too bad, because except of the instability problem in the plugin, i feel LateralGM is not bad at all.
These two are related, I agree with both of you. A little less Harri, because it's not so much that the other changes aren't good. It's just that I've seen a lot of people recommending LGM when Studio fails to import projects. GM8.1 and lower was like the best thing we ever had, Studio was crap, and that's why we never supported a lot of it including the ds accessors like mymap[?5] and mylist[%3] which are just downright absurd for any programming language.

I'm just saying, hey guys, there's quite a bit of people that could use LGM for a while into the future. I think it may not be too late to split LateralGM in two with a version for only 8.1 and lower, but I don't recommend you try to follow through on this.

Quote from: TheExDeus
Another thing to look at might be really the CLI way. It might actually be easier to have that up and running the fixing a plugin that uses JNA. But anything is better than just watching LGM burn every time you open it.
I'll prod Josh tonight about it if he's around.

General ENIGMA / Re: Joshedit
« on: August 26, 2015, 07:32:53 AM »
Quote from: TheExDeus
I used ENIGMA on Linux recently and it worked. I ran it on Tegra K1 which is actually an ARM, but supports GL3, so I didn't have to change anything. I will try running it more on Linux. I tried testing Linux on Virtual Machine, but then I have GPU problems as the virtual GPU driver doesn't support GL properly.
Yeah I don't agree with Josh on this at all, Linux is like the only place ENIGMA does actually work the way it's intended. Though I can not comment on any recent versions because I haven't tested at all.

Quote from: TheExDeus
1) Make CLI work so LGM wouldn't work trough a plugin thus creating instability.
Josh had no objections to a CLI just that it be built properly which the one I set up probably isn't, it was very quick and dirty. I asked him some time ago about one and he mentioned his GFlags library which I think he has up on GitHub, you'd have to ask him.

Quote from: TheExDeus
2) Finish EGM so it is future proof in a way that additions wouldn't break it.
I like the EGM format I just don't like how sprites are confined to the sprites folder in practice instead of theory. I think the IDE should impose that constraint not the file format. Regardless EGM is a great format and the meta-data uses a format that's a lot less verbose than XML. So I like the format, despite some of its implementation being a little buggy, one of the issues I did address a long time ago was the file handles left open in LGM which made it impossible to move or delete an EGM while LGM was running. Also some of the plugin side YAML parser is missing features that the ENIGMA side EYAML parser has, despite the latter being a subset of the former.

Also I don't want to hear any complaining about LGM's exception dialog, you should be glad I made it so ubiquitous, not that you are I am just saying to all of you in general. It led to me fixing a number of trivial bugs that would have otherwise gone completely unnoticed from versions before I even touched it.

Quote from: TheExDeus
3) Make parser more robust by reducing GM compatibility features.
What are we talking about here, getting rid of globalvar or what? I'd say we should add an option. But after talking with Harri I still feel like the best idea would be to do GM8.1 compatibility to 100% and then fork ENIGMA with anything else we do. I look at it like this, we have the code base, everything we need for 8.1 compatibility is there. Throw out any of the other frivolous shit we've added and any new functions and feature freeze it as an 8.1 and lower augmentation and NOTHING MORE. It's probably too late to do this now, we should have done this a long time ago. If I had the power or the time to do it though that's exactly what I'd do but it's still probably a huge task in and of itself.

Quote from: TheExDeus
Yeah, it is meant an ironic reference to the fact that Josh isn't actually interested in it.
You guys have lost me with this, I don't get it. JoshEdit is likely named after JEdit which was also Swing and provided syntax highlighting, he likely put his name there to distinguish his project.

General ENIGMA / Re: Joshedit
« on: August 26, 2015, 01:07:18 AM »
Quote from: egofree
Robert, I don't see how that is Ego's problem. If JoshEdit doesn't work because it was left in unfinished state, then it's a problem there.
Yes that was incorrect, I did not mean it the way you interpreted it, I meant that is where the source of the problem is. This is not his fault even remotely.

Edit: After further review I believe I originally meant that it should be building but I couldn't recall the specific details of whether I had made additional changes. Thus why I said "I was going to say that is your problem" instead of saying "That is your problem", you see the difference?

Anyway I would fix this but right now I'm starting another full-time semester plus these other projects I am working on like DockFX is too much to do. To think about working on LateralGM right now with all the outstanding issues just makes me want to cry. I don't even have the time to be here, I have to finish finding my books online or purchasing them and get started reading.

Quote from: TheExDeus
I'm getting so tired of this half-ass "add a broken feature and forget it" kind of work ethic.
That was where I last left off, I don't recall leaving anything else in such an unusable state beside constants, which also occurred around the same time I started to become unmotivated.

Here's what happened:
* Josh insisted I set up LateralGM to pull JoshEdit directly.
* I did that and moved several of the changes I made into separate pull requests. I didn't know how to use a styleguide then and Josh was busy with work and couldn't take the time to sit down and do it the way he wanted it.
* I gave up on Josh's intent to pull JoshEdit directly upon checking out LateralGM and continued to make additional changes LateralGM side. However they were only a few lines, it really shouldn't be that difficult to get the latest JoshEdit working with the PR's applied.
* I gave up on LateralGM for a while chosing instead to focus on my studies. Made an improved release of JEIE and then decided to focus on nothing but my studies.

Quote from: Josh
It's been two years since I've been able to do a git pull and compile a game on Linux. That's why all our other Linux users either maintained their own forks (as DarkAceZ did, and he was 14 fucking years old at the time), or left (as most others did).
Nope, you just did that game for 64digits in 2014 and iirc you applied a patch somewhere I thought.

Also I've just been kind of mellowing out and hoping ENIGMA's problems will just go away. Personally I wish we would have done GM8.1 compatibility as best as could be done and left it at that and not touched the source any further because I think we were getting really good and stable for a while. And then forked ENIGMA and LateralGM for any Studio functionality, that's what I wish we would have done but at this point I refuse to remove any GMK or GM6 support from LateralGM. I'd rather fork the IDE and stick with a GM: Studio compatible version only but then GMX doesn't even have a version number so what's the point. I don't even have any interest in developing an IDE for that program.

Developing ENIGMA / Internationalization and Localization
« on: August 24, 2015, 02:46:01 AM »
Just thinking about the troubles LateralGM had maintaining translations. There's a startup project that basically works like git for translations where authors can create translations for a project.

As an example this is the one for the ControlsFX project:

This could be a good idea for the future as it can attract more professional translation services and there are paid versions too.

Developing ENIGMA / Re: Debuging the .dll
« on: August 21, 2015, 03:35:35 PM »
Yes Harri listen to Rusky, the debugging symbols/huffman codes are not my doing, it's Java's doing.

General ENIGMA / Re: Joshedit
« on: August 21, 2015, 02:32:49 PM »
I was going to say that is your problem because the JoshEdit that LateralGM checks out is a fresh copy from his main repo but I added print support.

There may have been other modifications that I made and did not commit though I really can't remember. He likely does not want to merge my pull requests because of the huge commit history and I wasn't very good at formatting Java files back then with a style guide, but LateralGM doesn't actually use one so he's probably just to busy or doesn't care. I am looking to port JoshEdit to JavaFX.

Works in Progress / Re: Son of Blagger - remake
« on: August 15, 2015, 10:01:18 PM »
It looks like a pretty straight 1 to 1 correspondence with the ENIGMA/GameMaker version. I am really interested in JS now too and I'd like to share my prototypes with you too egofree but now's not the time. Also your game loads pretty fast too, not bad at all!