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

Graphics and Video / Re: Between heaven and earth
« on: September 30, 2015, 07:17:16 am »
I'm going to be honest, the greatest experience I could probably have in life is to just go here and masturbate in the wild. If somebody would just stick a desk out there for me, I could accomplish a lifetime of work in so little time. I'm using one of these as my new desktop background for a while to freshen things up a bit. The site looks great and I am very impressed with its responsiveness with such high quality photographs.

Idk what else to say, both the CLI and compileEGMf are needed to get the best results. Anyway, you have my opinion on mixing XML with YAML for EGM, I was still interested to know if you can think of some way we could leverage XML's querying abilities in a unique way. Those wiki links are the best place to look for the other EEF formats and what not.

Quote from: TheExDeus
Well maybe making it only use one thread is solution then?
That's the problem actually. For example the output window overflows sometimes because its reading a stream of text from the compiler and updating the GUI off the Swing Event Dispatch Thread. Because Swing does other things when not on the EDT, updating the GUI component by setting its text is inherently unsafe when your not on the EDT and leads to unexpected/undefined behavior as the official Java documentation will tell you. This is again, a problem with many GUI frameworks that are not thread safe, just like Swing. I believe Windows Forms is not thread safe either, however the new JavaFX is thread safe. Swing is pretty legacy these days, if you look at its source code its like halfways undocumented and doesn't mark barely any of its methods final. JavaFX is a much cleaner solution, but I'd sooner rewrite a new IDE with it than try to port LGM to it. I think WPF is thread safe like JavaFX because they both support data binding.

Quote from: TheExDeus
It doesn't complicate anything as the IDE must be able to save EGM anyway and the CLI needs to be able to load it.
You've got the idea now, the assumption that the plugin could be abolished, I admit, was originally me proliferating my own stupidity. Now let me beat the point home a little harder.

It's simpler from an external perspective, but not from an internal one.

Externally it does look like this...
Code: [Select]
system(cliPath+" -egm "+randomlyGeneratedFileInTemp);

But internally, throughout the whole process, it turns into this...
Code: [Select]
system(cliPath+" -egm "+randomlyGeneratedFileInTemp);

Instead of this...
Code: [Select]

Note the final example is in a perfect world where LGM had the proper architecture, GMK was not a binary blob, and compileEGMf was able to load/find resources. Anyway, yes, go CLI, there are numerous benefits for it. It also serves as an excellent tool for when LGM is just really failing with the plugin, and it also loads and compiles projects quicker if you do not need to change anything at all.

Quote from: TheExDeus
I do agree that XML is more verbose than some alternatives, that is for sure.
I don't know, reading the XML is useful when a corruption occurs, that's why we don't want binary blobs. I wouldn't say XML is hard to read, I did HTML programming in junior high school. I don't know how I would have been towards YAML when I was younger. When I first saw it a few years ago in ENIGMA I wasn't sure I understood it, but it wasn't difficult even though it looked foreign. Now that I am older, I definitely prefer it just because it's easier on my eyes. That said, GMX is basically the XML format, we've done YAML in every other part of EGM. So that is basically why I don't support the room format being XML because that is inconsistent. Using YAML makes the EGM format unique from the others, and I really don't think we should do another format just because we want XML. There's not really a good argument at all here especially considering we already have the suitable YAML infrastructure.

Quote from: TheExDeus
I just meant that the excuses like "Plugin is crashing, not LGM" is futile here.
Sure, but I've not been saying that. I've been saying, stop looking at LGM, and look at the plugin. Specifically because several of the issues I am already aware of and think I know what's causing a large bulk of them. A lot of them being related to the changes in Java 7 that made plenty of Swing apps start showing errors about LegacyMergeSort. Those I believe are related to doing GUI stuff when not on the Swing Event Dispatch Thread because Swing is not thread safe. I never understood it when I was younger but it basically means doing GUI stuff on any other thread leads to unpredictable results. The plugin gets a lot of these because it makes a lot of use of threads and tries to do GUI stuff from those threads. A few versions back I tried to wrap a bunch of stuff in SwingUtilites.invokeLater but I am not sure what benefits it had.

You can search all over the internet, these have been creeping up for plenty of Swing apps:

Anyway it's really not a Swing problem and quick hacks to enable the old legacy sorting should not be used. You have to ensure this functionality in any non-thread safe GUI framework, even though Swing is a heaping pile of garbage. The real correct fix is to analyze existing code and make sure GUI stuff is being done on the main Swing EDT. I can't take a look at the plugin right now but I did fix these issues LGM side where the project loading is threaded many versions ago. It's important however that when you guys experience these issues you not just file a bug report with the stack trace but tell me exactly what you were doing. It's impossible to track down, as I have never found a way to reproduce it consistently, because the code is being executed on discrete threads.

I haven't spoken up about this because I thought it was known after my research with egofree. This is why I continue to say the plugin was designed poorly because nobody considered thread safety. Also remember that EGM used to leave a ton of open file handles. So not everything in that plugin was finished and I patched around a lot of it not knowing what I was doing. However, I think the effects of anything I've done are not that big, it clearly seems to have been getting worse even though I haven't been touching it. So my analysis and research has supported my conclusion that it is the plugin that was designed poorly and old issues are creeping up to bite us in the behind some more.

I think this ticket is one of them, I'm trying to get more info from the person, these tickets always really annoy me when people don't respond:

Quote from: TheExDeus
Removing one .ey entry can trow a segfault.
Yeah there should be some more user friendly error reporting that reports that, possibly by integrating it with the compiler's existing error reporting stream/interface. It could actually just show up and return back to LGM in the console window, that's not even a plugin issue though, that's an ENIGMA issue because the same thing would likely occur in the CLI.

Off-Topic / Local School District Drops GameMaker
« on: September 22, 2015, 03:18:50 am »
A small school in North Carolina has decided to stop using GameMaker: Studio because of its proprietary DRM. The school claims on a number of occasions the program corrupted games developed by students. The school is SkilStak located in Cornelius, North Carolina and is a private school for teaching students 8 to 18 years old computer programming through game design.

From a GitHub repository hosted by one of the school's staff members, we find the following quotes:
Quote from: SkilStak School Staff
I strongly encourage anyone considering GameMaker to look at instead. You learn real technologies that will carry you farther than the proprietary and drag-and-drop GameMaker, (which is now owned by an online video gambling/gaming company). We have dropped GameMaker from all classes at SkilStak after it corrupted a student's game irrecoverably. He was the 6th in 3 years to lose everything because of GameMaker bugs. He would have had to reassemble everything from assets and saved code, which is stored in XML and prone to horrible merge conflicts when combined with GitHub for beginners. Just say no to GameMaker.

We can also find on their related Twitter account:
Quote from: SkilStak Twitter
GameMaker @yoyogames crashed and corrupted student games for the LAST TIME! Game-1 now based on thanks to @photonstorm #html5

Quote from: TheExDeus
That is really not a problem as you can just write to a temporary.
While writing to the disk is certainly not as expensive as it used to be, it also simplifies the design in addition to enabling the other features I mentioned like live recompilation.

The above diagrams should help convey this a little better. If you use purely a CLI it severely complicates the overall process of passing the resources from the IDE to ENIGMA where it eventually has to be passed to compileEGMf anyways. The top diagram is what we get when we use a plugin for the IDE view/presentation tier. The bottom is what we get when you use only a CLI. The CLI is meant to serve as a replacement to the presentation tier only and not really support another presentation tier on top of it. This significantly complicates the overall process of passing the resources by requiring them to be loaded into the IDE, written to the disk, then read back from the disk on the other end before being passed from the CLI to compileEGMf. It is much simpler to have a plugin to just pass what was already loaded in memory directly to compileEGMf as we do with JNA.

In the model-view-controller architecture, LateralGM and the CLI are a view, they are simply different ways of viewing and manipulating the data.

For a managed application like LateralGM, the CLI is only useful for telling compileEGMf to find resources we haven't loaded. But it's not useful to LGM right now, because LGM loads every single resource whether you are editing it or not. In fact, the correct design would have the CLI never even referenced by the IDE, compileEGMf is missing the functionality of finding resources and loading them from disk which the plugin should also be utilizing. This is a significant amount of work though.

However the CLI does make it extremely easy from a conceptual stand point to build a new IDE and get ENIGMA to compile the project files, this is not debatable and I'm not arguing it. A lot of people also really like a simple command line and this is partially why I created it, even though I also created it originally because of my naive understanding of how it could just simplify everything and I thought we'd no longer need a plugin (which is not true as I've described). So yes, by all means the CLI needs finished but I do not have time, and it would be perfectly ok to use it for a new IDE until that new IDE has a proper plugin framework.

For reference, you can read why IsmAvatar originally invented the plugin in the first place, and it's for the exact reasons I mention.
Quote from: IsmAvatar
Enigma started out as a CLI exe only. LateralGM was forced to communicate to it through this limited fashion, writing the game to a file, passing the filename to the exe, and pipe-reading ENIGMA's output from the exe and files that it produced, which was much slower than it had to be.

One day, IsmAvatar figured out how to get Java and C++ to communicate via DLL with the use of JNA, which allows LGM and ENIGMA to share memory structures and make interactive calls to each others functions, which is much faster and much more dynamic. Since then, ENIGMA has redirected itself towards being a DLL, and the build process has been streamlined for that purpose. As a result, ENIGMA became almost exclusively a GUI program.

Due to the thee-tier architecture of LateralGM (front-end back-end separation), it isn't hard to use a headless LateralGM - that is, just the data and logic tiers, without the front-end presentation tier. As such, it wasn't long before this fact was exploited, and combined with the Plugin to communicate with the dll, to construct a Java CLI for ENIGMA.

Quote from: TheExDeus
And we did have posts with Josh talking about rooms in a non-binary mode. In it I showed how XML is actually not bloated if used correctly. Yet has more features than EYAML proposed. But I honestly don't care in which format it is.
Rusky has pointed out to me that XML supports namespaces and some other features I see, so excuse me for being naive originally. I was not aware of this but I think it is still debatable about how verbose XML can be, and I clearly tend to agree that it is. However, XML apparently does have some good data processing and querying features (which I was already aware of), but why exactly does ENIGMA need them? YAML is clearly/technically/colloquially not a markup language and really good for just plain old data, which our rooms basically are. So I would like to know if you had some ideas for utilizing the XML processing/querying features or not, because that is something to consider before making a decision.

Quote from: TheExDeus
What you said irrelevant.
I don't know what you want me to say. LGM has taken all of the necessary precautions to make sure the errors are properly reported, and so has the plugin framework. Even a native IDE would require a plugin framework so that it's not limited to only ENIGMA, it's a simple separation of duty. What is the problem here? Are we still not able to debug these compile errors you're having with the plugin or what? I don't know how they've managed to creep up all of the sudden. The plugin was unstable but not unusable when I last left as it appears to be now.

Quote from: TheExDeus
I don't see how that is a lot of work.
Because I'd have to set up ENIGMA and the plugin which are all broken locally because again I was messing with 64 bit. Not to mention you have to go and regression test and make sure it completely works the way it should, file handles are properly closed etc etc. Additionally I haven't worked as much with the EGM format and tried to leave it alone for the most part besides adding UTF-8 and closing file handles so the project could be deleted once the IDE finishes with it, it was causing tons of problems before with saving EGM's when I first got here, I eliminated those issues a long time ago. EGM was really unfinished and still is pretty unfinished though we've added timelines and some other things.

Quote from: TheExDeus
Again, if you have EGM loading then this should be trivial. It should be even easier, as you must SKIP a step. Just don't open the .zip and instead read the folder structure.
Yeah it probably wouldn't be too hard but it would need tested and you'd have to double check and regression test etc. I am not up for it because I don't have time to set up all of ENIGMA and everything right now. I have like 1000 other projects I am wanting to be working on and my school work, I'm still going full time.

Quote from: TheExDeus
Robert, I see that you have basically remade LGM 5x over the past few years and it would have been awesome if you actually managed to finish one.
I can't, it's way too much work, and nobody ever really took an interest in working with me on the projects or making them a reality except Josh offering occasional help. It's not like there's any actual architecture to them either, for the most part it's just a recreation of the GUI. That's not that bad though because they do serve as great templates/starting points and that's why the source code is still up on GitHub.

Quote from: TheExDeus
CLI is the easiest way to make a custom IDE compile a game with ENIGMA. That is why I encourage finishing it, because then HitCoder and other people who want to make an IDE wouldn't have to waste time somehow interfacing with ENIGMA. They would just need to make a writer for EGM which is a trivial format.
Yes it certainly does make it easier to get started, but ideally in a perfect world you still need compileEGMf to pass resources that have been opened but not saved in the IDE. This is the problem GM Studio's IDE has, it always forces you to save your changes before running, which 99% of the time nobody wants to do, Especially me, you make small changes just to test them. I don't even like how Eclipse or Visual Studio make me do that, but they generally get a pass because I only have the tabbed code editor open. You can't do that if it makes you save every single time. Also if the resource was already being edited and loaded in memory, it's still quicker to just pass it by memory than have the CLI read it from disk. The only time the CLI is useful, besides making it easier to interface for a new IDE, is when the resource was never loaded by the IDE. So basically it's virtually worthless because LGM was never redesigned to handle opening single resources, it still opens up the entire binary blob because of GMK, even for the EGM format and GMX too, when it could do it the way Studio and Visual Studio and every other IDE does it.

Though as I said, VS and Eclipse would both benefit by having the ability to pass the text files with changes already in memory instead of asking me to save, it would in fact be more quicker to translate the memory than do a disk write and then a disk read. Though large architectures like that would have some problems with build systems. I should also mention that it was Josh who described to me the benefits of having something like compileEGMf. It also enables the ability to do things such as live code editing, where as when you make a change to a script it automatically recompiles and is reflected in the game. You may have seen this before with online shader editors for GLSL and stuff that feature live compilation.

But yes the CLI should be finished and it would be great for supporting third party projects as you suggest and allowing them to more rapidly interface with the engine. I do not have the time to finish it Harri and where I last left it, it was compiling GMX projects.

Quote from: TheExDeus
1) Change room data into XML.
I was going to do that, but clearly if that's all you want then there is GMX. XML is a bloated markup language and Josh already proposed an EYAML format to replace the binary room blobs. Anyway, I don't have time to do it, that's a substantial amount of work. The breaking change is fine though because I have backed up every old plugin and LateralGM version in multiple locations and they aren't hidden either, you can find them easily on the Wiki and I've linked it multiple times. So if you'd like to make the changes to the plugin, knock yourself out it needs done but nobody has time right now.

Quote from: TheExDeus
2) Make a format that is basically extracted EGM.
EGM is actually supposed to support this, it was never finished and I never had the interest in doing it. Also note the above comments regarding LGM still loading the entire project instead of just the resource you are currently editing.

Quote from: TheExDeus
It doesn't really matter what crashes. When the user opens LGM and it segfaults then of course the only thing he can blame is LGM.
Irrelevant, we should try to inform the user of ENIGMA's architecture, it's not difficult. Also, the plugin installs its own error handler using the LGM interface which prints the very name of the thread. The plugin, in fact, changes the URL for the "Submit Issue" button to point to ENIGMA's plugin repo instead of LateralGM's. I also made it change the message to specifically tell you that the error occurred in the ENIGMA plugin. I did that on purpose to stop ENIGMA related issues from being filtered onto LateralGM's tracker, though it didn't always work at times because some still trickled through. This is sometimes caused by a plugin issue propagating back into LGM, ie by screwing up the tree model which doesn't result in an error until the user clicks something. At the point the issue occurs in the main Swing application dispatch thread which is owned by LateralGM's process.

Quote from: TheExDeus
On my laptop my plugin fixes made crashes almost non-existent (about 1 crash every 3 hours or so).
So push the changes to GitHub. I do not have a working copy of ENIGMA right now because I last left off with trying to build a 64bit version. I don't have time to set everything for that up right now. The plugin is under the enigma-dev domain and again, we have all of the old versions backed up.

Anyway, I have made some time for some small LateralGM improvements and quick bugfixes I've made. I've fixed like the newest 3 issues on its tracker. I also added a new color picker control that lets you copy and paste hex color values. I am doing this release to fix the JoshEdit problems so that egofree is able to build LGM again and people can continue to develop it. Then I have to get back to doing some other side hobby projects. I also added the right orientation mode as a preference and it's implemented in every editor. There will a bunch of tiny other changes regarding improvements to some of the layouts and stuff as well. I know in this screenshot the layout looks bugged because I'm still working to get everything working nicely.

Haha alright HitCoder I understand. This was not an attempt to discourage you and I would gladly help you with hooking any project up to ENIGMA, keep in mind that this is how I got started working with ENIGMA when I had no idea how it would be done. But at this point with the design of NGM we've not just tried to make a better IDE with swapping room editors and such, the point is that this architecture actually makes the IDE more sustainable in the future, which is what we need the most. We don't need another IDE like LGM or it just turning into a mess, this is not me criticizing your attempts, it's actually a criticism of my past self just thinking I can fix all of the problems by porting it to another platform/language/framework. With a big fat/monolithic program like LGM, once you've built it big enough it gets really hard to extend things because it's all glued together so tightly. MVC makes it where changing things doesn't break everything else in the process.

Also if you still have the urge to do an IDE, just do it anyway, it doesn't matter if people end up using it. Be creative with it, there are plenty of people who complain about the user interface of both GM and LGM. Try to create something original and experiment, you might just come up with something interesting like I did in LGM for the non D&D mode. If it's good enough and you can motivate me to do it or want to take a crack at Java we could even get it into LGM. Even simple things like changing panel or editor layouts (which I'm doing a bit of myself in this release I am working on). I'll tell you a better way to learn game design than using GM or ENIGMA, it's by building your own GM or ENIGMA, I can't tell you how much I've learned working on these projects.

I can promise you I will notify you and everyone else when NGM reaches a point that we can show it off without being all smoke and mirrors or vaporware, thus why we've been keeping it hush hush more than the other projects I've done just as experiments. And don't worry about anything you said, I read it all and I agreed with just about all of it, you're very reasonable and have a good understanding of the problems.

Edit: This may seem counter to what I've said and it kind of is but it's definitely worth noting, please see this wiki page:

Hey HitCoder, I'll give you some feedback that hopefully gives you a deeper understanding of where we are and maybe even give you some ideas.

For the most part you are absolutely right and we kind of all agree. LateralGM was meant as an intuitive GM IDE. Because it does so well and it's something that people have become used to, I've tried to avoid completely radical changes and instead encourage forks of the project. What bothers me and a lot of people is that the IDE is extremely monolithic. You can't replace a single editor with a different one or add new project formats, the plugin system for LGM is not very well designed. Don't take this the wrong way, but I actually do not agree with the complaints about LateralGM on Windows because of this. Sure LGM may not be designed well for a good plugin, but its problems almost always crop up when used with the ENIGMA plugin on Windows. LateralGM by itself rarely if ever (I've never seen it) segfault on its own all by itself, it's always the ENIGMA plugin crashing it. And this is not just because of LGM's poor plugin architecture it's the generally bad design of the ENIGMA plugin itself.

There's several options to building an IDE:
* Java with Swing (what we have now with LGM)
* Java with JavaFX allowing CSS styling and customization (would be a lot better than LGM; look nicer and modern and less inconsistency in the Look & Feel; would also be faster as JFX is hardware accelerated)
* C# with .NET/Windows Forms or GTK# (might be a little better; C# is not quite as bad as Java and the look and feel is at least consistent with Windows Forms/GTK but there's not possibility of styling (I think?) but you could also just use a different GUI framework but I am not sure what possibilities C# has)
I attempted this with SharpGM and did a number of GM's editors.

* C++ with Qt Framework (would be fast; would look really nice has less bugs and sometimes looks more native than wxWidgets)

* C++ with wxWidgets (would be fast, wouldn't be bad at all)
I've also done this one already when I started and was building wxENIGMA

* C++/EDL/GML by building an IDE in GM/ENIGMA (may be kind of clunky and require a lot of extensions; then again there's a lot of the features you need already there; can't really do any super advanced things you may want to do though like radical changes to the architecture; ie would be better done in ENIGMA than GM or by just making ENIGMA its own project different from GM with an IDE in itself like Unity3D)

We've also discussed a native C++ Command Line Interface for improving LGM. This would almost certainly get rid of all of the segfaults in LGM but would possibly be slower in some cases because of the increased disk input/output operations to save the files before passing them to the CLI. Because of this it is better to think of the CLI solution as an alternative but ENIGMA should still support in memory compiling through the compileEGMf library interface. When the IDE has the resources in memory it's actually just quicker to pass them in memory than write and read them back from the disk. The CLI only makes it potentially quicker for LGM because it's Java and passing resources in memory between Java and C++ with JNA is probably really slow because it has to do so much work (probably why big games take so long time to compile compared to reloading them in LGM). I hope that makes sense? It's the combination of Java that makes compileEGMf slow, but neither is really that slow by itself just translating the memory layout of Java to C++ kills it. Anyway we already know I did a partial CLI that was working for ENIGMA with GMX but I am certain it has broken since then though Harri expressed interest in developing it further. It is also important to mention that the C++ CLI itself would drive ENIGMA through the compileEGMf as it does now, so even if LGM used a CLI, compileEGMf would still be involved, the only difference is that disk I/O would be used to pass the project instead of JNA.

Basically, we've gone down every avenue of possibilities and I personally have no preference I'm just around to code whatever somebody wants me to code. I am actually working on a new LGM release fixing a number of small bugs that I hope to make available by Christmas. What the big game changer is going to be is NaturalGM. DaSpirit has continued developing it and I've been helping him. I mentioned this also in the other topic. He's taken advice from Josh who works at Google and Rusky and some of my own ideas as well. I want to keep helping him work on it because I think it would be nice to have an IDE that is maintained by somebody outside of the ENIGMA project. DaSpirit has no real interest in ENIGMA or even GM but he does enjoy developing the IDE we've been working on and does want to make it available for GM and ENIGMA. The design of NGM is very good, it follows the model-view-controller architecture for software. This means that things like project loading and serialization are part of the model. They are self contained in a library and not dependent on any GUI code. So basically you could write a C++ console program that loads and lets you edit the project with just this library.

This solves a lot of the LateralGM problems for many reasons. Because the data/model is separated from the view/GUI components you can take the library and swap the GUI out for wxWidgets/Qt/Windows Forms/GTK/JavaFX/Java Swing or any GUI framework you want. LGM was not really designed this way, though Swing is supposed to be MVC, everywhere you look in the source code our data is tightly coupled with the GUI code. So in other words, porting LGM to use JavaFX even would be a total pain because I would have to rewrite a ton of the code for the tree model and everything. With NGM you can also swap out a plugin for a room editor with an entirely different room editor. We've been making good progress too, I've helped him build a few models including one for the log table which displays output messages. We're focusing on the core design rather than just replacing LGM. And since it's primarily led by DaSpirit who has an interest in making it available to GM users as well, it means less work that the ENIGMA developers have to do. Since I ended up having to maintain LGM because nobody else would; I mean except egofree, it's just a lot of work.

So I am still going to keep developing LGM just for fun and to fix small bugs because they are easy. I am also looking to cleanup the build system so egofree can build it again after the next release. I do not think JavaFX is mature enough yet to port LateralGM to it but I will continue to assess the potential. I will also be continuing to help develop NGM because I really like the potential and I think it is the best thing to contribute towards ENIGMA. I am also open to helping you or anyone else develop an IDE if you have specific questions and just need to know how to interface with compileEGMf or anything like that. I am available and you can always feel free to post questions here. Please feel free to use any of my previous work, the links are all on GitHub.

Works in Progress / Re: Flappy Wheels
« on: September 16, 2015, 01:28:47 pm »
:O No I didn't, I swear; I renamed it to "Happy Wheels Demo", I swear.

Issues Help Desk / Re: [FIXED] Error opening the ENIGMA - Illegal character
« on: September 15, 2015, 06:57:12 pm »
Ok I've done some additional testing. I am not able to reproduce this in any LGM version that is newer than LGM16b4. I even recreated your exact file path and LGM loaded it fine from the CMD line and it was exactly the same when I loaded it with enigma.exe

Have you ever used an older version of LateralGM before at all? I need to know specifically if this is still your first time using ENIGMA/LGM or you've downloaded and accessed the older versions before.

Works in Progress / Re: Happy Wheels Demo
« on: September 15, 2015, 01:07:03 pm »
That's turning my stomach considering I just ate Reese's peanut butter bars. I like pigs in a blanket, not the polish crap everyone talks about, I mean baked hotdogs in bread with a slice of American cheese.

TKG, also, this is the off-topic forum, so your post title is misleading. You actually have a working demo so I am going to move this to WIP unless you have a discussion involving the YYG's HTML port. In which case I still think it's better you fragment this into two posts.

Issues Help Desk / Re: [FIXED] Error opening the ENIGMA - Illegal character
« on: September 13, 2015, 11:25:33 pm »
My apologies I did not see this right away. That is extremely useful Jhasper I was wondering where this bug was coming from before. I had the same issue myself with the recent files and couldn't remember how it started. Now I have a way to reproduce it hopefully. I will likely be able to get this fixed in the upcoming LateralGM release I want to make within the next few months.

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).