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

Works in Progress / Re: Happy Wheels Demo
« on: September 13, 2015, 11:20:12 PM »
This is pretty good, I'm very impressed. This is right up there with Happy Penguin? Excuse me if that's not correct, it was the penguin swimming game you showed me before. I think it's right up there with that.

When I first played it, things went a little better. I made it as high as lap #8 but didn't take a picture. After that I really struggled to get past level #1. But I think there's a bug, if you fail the first lap it's more difficult unless you restart. Once I restarted I got back up to lap #5 and forgot to take a picture again. I wanted to get past lap #10 but it's so difficult.

I'll try again a bit later for a screenshot. When you reach the higher levels does it start going on curves? If not you could use the path editor to make it curve, I could make an example.

Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 08, 2015, 08:54:47 PM »
Ok, can you tell me where the following file is coming from?
C:\Users\Leandro\Documents\Game Project\shotgun_funfun_online_gm81.gmk

Have you opened LateralGM at least once and opened that file before at some point in the past? Or are you trying to load it from the command line?

Proposals / Re: Editor Enhancement
« on: September 08, 2015, 07:12:45 AM »
Darkstar2, yeah pretty much. I don't want it in the content area it has too many buttons to be there and it makes the frame not compact as easily from the right.

TheExDeus, yeah I could do that if we REALLY wanted to, I could just port my docking library I just wrote on GitHub. However I've come to not even like docking managers and I feel they just make a cluttered UI. I never dock things in programs, I leave the tree on the right in Visual Studio and the tree on the left in Eclipse, doesn't bother me. Only thing I care about is having my tree and my class hierarchy, but the class hierarchy is on every object frame in LGM/GM so that's not really needed. I've considered ways to just combine the search results tree with the normal tree too, I am not sure about doing it yet, probably not going to.

egofree, yeah. For reasons above I don't want LGM to have full docking, I feel like it makes a cluttered UI. At this point in time I'd like to just go with a simple preference that makes the layouts of all the editors right oriented instead of left oriented. The only thing I personally care about is that the save button on editors stay in the absolute top left position of the frame (I've grown used to it being there).

Proposals / Editor Enhancement
« on: September 07, 2015, 08:11:23 PM »
So we are all aware of the traditional GM style editors:

We are all very comfortable with this to some degree, you save in the top left etc etc. But there's a problem here.

The tool bar buttons are never aligned with the content being edited. I propose that for LateralGM we move all the side panels on the room editor, path editor, sprite editor, and background editor to the right instead of the left.

With this change all of the toolbar buttons are properly aligned with the content area and requires less mouse dragging to click. What does everyone think about doing this? Since I realized this I've really come to like the idea. An alternative would be to move the toolbar in the content area (but this is gross if we keep it the edit panel on the left because I'm used to save being in the top left of the window). The other alternative is to simple right align the toolbar (though this also moves the save button to where you wouldn't expect it to be). Please let me know what you all think if I don't get enough feedback I may just end up doing this anyway.

The alternative looks like the following. To eliminate the whitespace we could put the save button in the bottom left like it is on the font editor and object editor then move the toolbar into the content area. I don't like this though because I am really used to the save button being in the top left.

As a preference it could also move the tree. The IDE would be either left or right oriented.

Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 06, 2015, 10:44:52 PM »
Are you by chance running this in a virtual machine?

I ask because the problem is related to the following:
Quote from: LGM Log
x80000002. Windows RegCreateKeyEx(...) returned error code 5.

I've never actually seen this before but this probably 100% an issue with your Java installation because it's not able to create the preferences file in the system registry. That's not our doing because the Java preferences API is a public API that makes it easy to implement preferences and actually abstracts/hides the system registry from you and uses INI files on Linux and Mac.

So this basically suggests that it's the lack of privileges for modifying the system registry. Have you by chance modified the security profiles of your Java installation in any way? Is there anything atypical about your Java installation or computer configuration?

Also the log suggests you are running Windows 7, is this true? Or do you happen to be running Windows 7 in a virtual machine?

Edit: A quick Google search indicates that this could just be a problem with your computer.!topic/google-web-toolkit/LQfsBSwD_ug

As I mentioned it seems to be the result of lack of proper privileges to run the program.

Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 06, 2015, 09:46:27 PM »
Hello Jhasper!

In order to better assist we will need some additional information from you.

* Is this the first time you've used ENIGMA or LateralGM before?
* Do you have administrative privileges on your account?
* Could you attempt to run LateralGM/ENIGMA with administrative privileges and see if the error is corrected?
* How did you attempt to open ENIGMA through enigma.exe or through double clicking the LateralGM jar file? I see you also attempted to start LateralGM from the command line, this will only work when you use LateralGM separately from ENIGMA. If you want to use LateralGM without compiling games feel free to move the jar file somewhere else on your computer.

Developing ENIGMA / Re: Debuging the .dll
« on: September 05, 2015, 08:57:56 AM »
Yes I know what you mean but at the same time it increases the chances that they will report such issues, even more of them than we may be aware. It's like shining a flash light in the dark.

Developing ENIGMA / Re: Migrate Releases
« on: September 05, 2015, 08:54:49 AM »
I'm not so sure about that then Harri, I don't really think I like that idea either. I support the idea of distributing the change log with the release inside the ZIP, but I see no reason to add it to revision control, we would literally be revising our own revision logs (is this not what git should be doing for us?). I fully support people's ability to use ENIGMA or any software offline, even if you have internet there's many parts of the world that don't including a lot of public parks and such where it's nice to stick software on a thumb drive and away you go. I don't even know if you can get internet/wifi on a plane or not yet cuz 9/11. Anyway I did think that maybe we could set up that git change log generator project and make it auto commit with one of the many bots we have to a repository that contains change logs for all ENIGMA projects. But I didn't like that idea because of the same reason I don't like you suggesting it.

I always did the change log as a more human readable form of the git revision log for those who may not know how to use git. Because of my historic inability to make nice commits I've also used both github's revision history and the change logs I've made to find stuff.

Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 10:44:42 PM »
Josh can you share the old ENIGMA copies with us if you have them on hand for me to archive on GitHub? I would also like to see the last ENIGMA zip I had on the shared dropbox up there too, so maybe we should call that v1 since it serves as an intermediate milestone to the latest version from r3. I like to keep archives of old versions because it helps with testing.

Also the new tags on LateralGM make it really easy to see what the master looked like for a particular release, which is one really good thing about this. I do not think I care much for milestones but still think we should use them, they are just watered down labels but they still help abstract the project progress.

Second, I too favor rolling releases because if we did automate the change log generation we could just make it against the most recent commit/PR in master. I don't like all of these granular changes and I've been working on making more inclusive PR's/commits. The real hard problem with this is that I try to fix one issue at a time and push it to GitHub to see if it fixes a problem. I don't like sending a large amount of commits with a fix for something only to later find out it didn't actually fix it. This is difficult because people do not like to test or help test, I am not referring to us, I am referring to users that report issues.

FYI: Maybe we don't even need change logs Harri with the GitHub compare feature.

Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 10:31:20 PM »
Are you guys ignoring my post about Breakpad? It's a really good idea, lets you debug without having debug symbols in the code using Google technology.

Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 10:26:34 PM »
Quote from: TheExDeus
Maybe we need to add a changelog in the repo as well, so that when a person downloads the release from github he can still see what has changed (even if the forum dies for example).
The problem with this is that if the release log is verbose/long then it is really hard to browse for other releases. The simple thing is to say to just make the release log shorter but that's not always feasible. The other solution is to make more frequent releases so the logs stay smaller. Personally I think GitHub should improve the releases feature by making the browse part short descriptions then clicking on the release gives a change log and a longer description, maybe I'll file an enhancement request/suggestion. Though I doubt they'll care what I think since they don't even listen to Linux Torvalds who created git.

Quote from: TheExDeus
And how do we start versioning ENIGMA? Just start at 1 or something? I personally think ENIGMA is working enough to actually be considered version 1 right now (except the LGM crashes).
I believe ENIGMA already had a version process and we're technically still working on r4... This would be a question for Josh. Josh has stated in IRC that he has old copies of r3 that should be able to run which I'd like to see archived on GitHub releases page with the newer portables just for historical purposes.

Quote from: TheExDeus
I kind of liked smaller versions previously (like 1.21, 1.22, 1.3 etc.) but it seems the current trend for a few years now is just increment the version by 1. So we get firefox 40.0.3 now and so on. So the after dot revisions are bugfixes and almost every feature is a major revision.
I too like smaller revision numbers in case you didn't notice we never got to LGM 2.0 yet. I think Josh also tried to persuade me into smaller version numbers before.

Quote from: TheExDeus
We should also create milestones, so we know when to release instead of on every commit.
I forgot about the milestones API.
But there's also the difference in annotated vs. lightweight git tags. Tags are built into git, not a GitHub feature, releases is a GitHub feature. Releases have a 1 to 1 correspondence with tags and tags have a many to 1 relationship with commits. A lightweight tag just references a commit "git tag -l v1.2 a1a1a1a" where a1a1a1a is the first 7 alphanumeric characters of the commit hash/number. Annotated tags can reference other objects or you can create them when committing using -m to enter a message or w/e and say something like "This commit marks the completion of v1.2"

The fact that tags and releases are 1 to 1 really screwed with my head at first, this means you have to make a new tag for every new release, you can't reuse tags. I really found this to be quite odd, so the direct links will always be a little redundant.
See what I mean? We could just rename the jars to just plain lateralgm.jar but I don't like that because then you can't download them all at once easily, you have to download then rename download then rename etc. Open to changing this though because it would make it easier to include in the packages file in the one ENIGMA repo that it uses to update on Linux using that script, which has to be changed to include the updated hash of the jar anyway to see if it's newer. On the other hand I should mention that nobody else on GitHub uses the same file name for every release like I just proposed.

Quote from: TheExDeus
Also, can github create a release for the current master automatically? Like instead of a specific version release the top one is always the current up-to-date one (like "beta" releases). I guess all of that must be done manually?
Yes, that's how I did the last release you just create the tag on GitHub. I used the command line to create the tags for the really old commits because GitHub only shows a list of recent commits to create a tag. Just draft a new release, open the "Recent Commits" under @target and select the top one.

Now the other thing to mention is that I lied about GitHub creating change logs. This is really stupid because given both commit hashes/numbers you can do a diff from the command line with tags, GitHub really sucks at these things (why Torvalds does not merge pull requests from GitHub). However other people have invented some automation tools that generates change logs which could be integrated. But also as I said above I don't like putting the long change logs on the releases page because of how terrible it makes it to browse for an old release, this is why I plan to stick to small change logs for each release with a brief description and the forum post containing the longer change log for the foreseeable future, unless you can think of some better way to do it. I do agree with you that I'd rather have it on GitHub though where it's more permanent.

Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 03:13:27 PM »
Alright Josh is good with it. As a first experiment I've moved all of the LGM releases over there, it was a total pain digging up the old commit logs but I did the best I could. Best thing to do is just to make sure we do it every future release.

I linked the forum posts with the change logs instead of putting them into the release description because most of them are super long which makes browsing that releases page a bore. I will continue to do this for future releases but may add some small additional details. From now on each new release of LateralGM and major build will be a new release on GitHub and a new forum post, so it won't be one long forum post as was done in the past.

I'll do the plugin jars next but I don't think I'll dig up the specific commits for them, I'll probably just base them all on the most recent commit then do it correctly for future releases. I believe we should continue to version the plugin against the LateralGM version but I'm not sure yet.

If we are going to do this for the ENIGMA portable zip then the ENIGMA tracker also needs to work out a proper version number and we need to start incrementing it to mark the releases.

So basically we can use the tags for marking major milestones or w/e and the releases can be generated for each major milestone/revision. Does everyone like this?

Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 09:10:50 AM »
FYI my post over here was somewhat related to this:

Programming Help / Re: date_date_string change format
« on: September 03, 2015, 08:19:08 AM »
Ok that's weird, figured I would have documented that one, it's in fact, the only one I did not. I honestly have no idea anymore lol.

Programming Help / Re: date_date_string change format
« on: September 02, 2015, 03:25:36 PM »
Yeah but still I documented it to.

And I'm not suggesting anything, just that we create our own now or stick with the C++ one. Like if we ever add JS as a scripting language like Unity that we wrap the method to format it the same way.