egofree
|
|
Posted on: August 19, 2015, 01:51:47 am |
|
|
Joined: Jun 2013
Posts: 601
|
I wanted to fix the instability problem of LateralGM, but there are others problems to fix before that. Robert worked last year on Joshedit, and he made some pull requests which were not merged : https://github.com/JoshDreamland/JoshEdit/pullsThe problem is that the version of LateralGM on github uses the latest modifications made by Robert, and it's not possible to compile right now the project, even with his fork (I tried to use also his different branches) Of course there is the possibility to remove the new functions in LateralGM, which is not a big deal. But another possibility is to accept the pull requests. Josh, is there a particular problem for merging the pull requests made by Robert ?
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #1 Posted on: August 21, 2015, 02:32:49 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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. https://github.com/JoshDreamland/JoshEdit/pull/14There 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.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
Josh @ Dreamland
|
|
Reply #3 Posted on: August 25, 2015, 08:04:47 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Even in its current state, ditching the parser would probably be an unpopular opinion. I'd recommend adding a tag for the beginning of code you don't want formatted. You'd probably miss it yourself unless you never use object.somevar or with().
I'll point out that a lot of the reason I don't want to work on it is that the project is perpetually broken on Linux. 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). Not to mention that a lot of things I did had side-effects that people would address by effectively undoing the thing that I did. It's no fun fighting an uphill battle.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Goombert
|
|
Reply #4 Posted on: August 26, 2015, 01:07:18 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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. 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. 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.
|
|
« Last Edit: August 26, 2015, 02:25:07 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
time-killer-games
|
|
Reply #5 Posted on: August 26, 2015, 06:37:49 am |
|
|
"Guest"
|
the code editor's name is pretty creative, i had to say that at least once after all these years. does it stand for anything.
|
|
|
Logged
|
|
|
|
TheExDeus
|
|
Reply #6 Posted on: August 26, 2015, 07:25:02 am |
|
|
Joined: Apr 2008
Posts: 1860
|
Even in its current state, ditching the parser would probably be an unpopular opinion. I'd recommend adding a tag for the beginning of code you don't want formatted. You'd probably miss it yourself unless you never use object.somevar or with(). They are the only things I need. But I think I would try implementing all of that differently. Was there a reason you didn't want to do all of that with classes? Like one class per object. Then object.somevar would literally be correct C++ syntax to getting and setting a variable. The only reason it wouldn't work now is because you can assign a variable at any point (even inside a with(){} statement which cannot be determined at compile time). So what I suggest is making "local somevar" declaration mandatory. This would allow creating a list of variable in the class. Actually you could still use a map inside the class for variables that are undeterminable at compile time (like it is done now). Int to instance conversion could also still be possible. I'll point out that a lot of the reason I don't want to work on it is that the project is perpetually broken on Linux. 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). Not to mention that a lot of things I did had side-effects that people would address by effectively undoing the thing that I did. It's no fun fighting an uphill battle. 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. 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. And ditching GM is something I have been proposing in years. Loading GM versions before GMX seems good for me. It is just that we need a robust egm format too. And we almost got there but it broke because of room data being in binary (which is idiotic). The plan for ENIGMA and LGM is quite simple: 1) Make CLI work so LGM wouldn't work trough a plugin thus creating instability. 2) Finish EGM so it is future proof in a way that additions wouldn't break it. 3) Make parser more robust by reducing GM compatibility features. These 3 things would reduce outstanding issues to almost zero. ENIGMA engine bugs are constantly fixed by me and I think it is very robust and is getting faster all the time. The problems seem to be things I don't work on. the code editor's name is pretty creative, i had to say that at least once after all these years. does it stand for anything. Yeah, it is meant an ironic reference to the fact that Josh isn't actually interested in it.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #7 Posted on: August 26, 2015, 07:32:53 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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. 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. 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. 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. 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.
|
|
« Last Edit: August 26, 2015, 07:44:54 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
TheExDeus
|
|
Reply #8 Posted on: August 26, 2015, 08:01:43 am |
|
|
Joined: Apr 2008
Posts: 1860
|
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. 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. 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. 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. We could also make it just save everything in the same structure the user sees in LGM and thus allow resources to be thrown around the tree. I personally don't need that, but I can see how it could be useful. 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. And the bugs that threw exceptions are now gone. I only have LGM freezes and crashes without any kind of exception or error message. 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. 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.
|
|
|
Logged
|
|
|
|
egofree
|
|
Reply #9 Posted on: August 26, 2015, 11:38:52 am |
|
|
Joined: Jun 2013
Posts: 601
|
First, thank you all for your replies and for your help. Ego, if LGM could actually be ran then would you try fixing stuff for it? Maybe Josh can at least merge the changes, it is not like he is working on JoshEdit anyway.
Yes, I will take a look. Thanks to the new commit in Joshedit, a few bugs are gone. There is still the problem with the following pull request from Robert, which is not merged : https://github.com/JoshDreamland/JoshEdit/pull/37 (Provided an interface for JoshEdit exceptions to be redirected as in LateralGM so the user can be presented with a friendly error dialog) In LateralGM, you have for instance the following line : Runner.exceptionHandler = new CustomExceptionHandler(); And of course it will not find the exception handler. So if Josh doesn't want to merge this pull request, i will just remove the lines in LateralGM. Then i will try again to see the problem with the plugin. That was where I last left off, I don't recall leaving anything else in such an unusable state beside constants ...
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. 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 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. 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. 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. 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. For instance, the multi-selection feature i added last year is better than the one found in GM Studio. I am not really motivated, but i will to give again a look at the problem with the plugin and try to fix it.
|
|
« Last Edit: August 26, 2015, 03:42:26 pm by egofree »
|
Logged
|
|
|
|
|
Goombert
|
|
Reply #11 Posted on: August 26, 2015, 05:50:43 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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. 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. 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. 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. 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. https://www.dropbox.com/s/gefgz1p286uw6e5/lateralgmlastcheckout.zip?dl=0Edit: 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. http://enigma-dev.org/docs/Wiki/LateralGM:_Revisions9 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. 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. 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. 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. 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. 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.
|
|
« Last Edit: August 26, 2015, 09:52:51 pm by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #12 Posted on: August 26, 2015, 09:24:55 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
They are the only things I need. But I think I would try implementing all of that differently. Was there a reason you didn't want to do all of that with classes? Like one class per object. Then object.somevar would literally be correct C++ syntax to getting and setting a variable. The only reason it wouldn't work now is because you can assign a variable at any point (even inside a with(){} statement which cannot be determined at compile time). So what I suggest is making "local somevar" declaration mandatory. This would allow creating a list of variable in the class. Actually you could still use a map inside the class for variables that are undeterminable at compile time (like it is done now). Int to instance conversion could also still be possible.
GM's overall design is not conducive to that. It's similar to something that would be conducive to that, but it's not immediately conducive to that. Take instance_nearest, for example. The correct GM syntax is [snip=edl]instance_nearest(x, y, obj_target)[/snip], where obj_target is the integer ID of your target object, or any other identifying integer in GM (namely the any constant, but it's technically valid to pass noone or an instance ID, which guarantees that the given ID is returned). The return type is also integer. What you would want in a better language is something more like [snip=c++]instance_nearest<obj_target>(x, y)[/snip]. To contrast, // Current prototype; gives no useful information int instance_nearest(double x, double y, int object);
// New prototype to support the above proposal template<typename object> object& instance_nearest(double x, double y); any& instance_nearest(double x, double y); This code assumes the existence of a type called any which represents the highest object tier ( object_locals). Using instance_nearest<any>(x,y), you can still implement RTTI (probably in the form of just accessing object_index) to ascertain the type of the returned object and correctly cast to it, but otherwise, no casting is necessary. Without totally redoing all of ENIGMA's instance functions in this manner, however, your code would have to look up the object and cast it every time before you can access nearest.somevar at all. This will bloat your code, look hideous, and be a general pain in the ass to write and maintain. 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.
I would hope the CLI has more options than that, but yes; at its most basic, the point of the CLI is just to build a GMK/GMX/EGM, and that can probably be accomplished by verifying argc==2 and taking argv[1]. Odds are, though, you want to support things like --syntax-check myfile.edl or --attach-resources resource_directory ouput.exe. The library I wrote that Robert is talking about is called DeepFlags, not GFlags. You might be interested in either project, though. A few other things to address. (1) Robert also wanted me to mention the language I'm designing in my spare time. I haven't put any code down that is specific to it, and even if I had, I'm not sure that it immediately offers a solution to this problem, but I'll go so far as to say that providing a means by which you can address the instance_nearest problem described here and the choose problem described elsewhere (and elegantly address the problems we've already solved, such as script_execute) is a lot of the motivation behind the language's design—not out of regard for Game Maker/ENIGMA, but in response to places where C++ has limited our ability to do this naturally. I'm happy to talk about features of this language; I occasionally do on IRC. (2) I'm still and always very interested in IDE development, though I'm not, as I've told Robert a couple times over the last two weeks, presently "in the mood" to write an IDE. I believe that the IDE is ENIGMA/Game Maker's number-one asset. It's far more valuable than the language to the success of these two projects. I don't think a CLI is a replacement for a proper IDE. The room editor is indescribably important, and the Overworld resource I described would make a huge difference, as well. I'm also interested in numerous other editors. I'd like to try my hand at a FSA editor, for instance. Happy to talk more about this, as well. (3) According to Robert, you're under the impression that I want some graph bullshit instead of coding. No; that would be insane. There is no "instead of coding." Coding is what makes things happen. But coding is everywhere: Every toolkit has coding. What makes Game Maker cool? You don't have to write code to place objects in a room. You just place objects in a room, visually. That's what made GM stand out. More editors have surfaced that do that, of course, so it seems less unique; less important. I'm arguing that it's still the most important part. Offering a way to construct a FSM to handle, say, animation or AI for an NPC, is another way to remove some boilerplate and code complexity. Like, how much of your code is [snip=edl]if (current_state == running) { sprite_index = spr_player_running; do_run_behavior(); }[/snip]? Wouldn't your life be improved if you just had a "running" behavior you could edit, and a FSM entity that governs transitions sprites and the trivial bits of the transition logic for you? The Overworld resource I mention from time to time is another critical asset. Another great asset would be a way to visually account for game unlockables. Think of stars and star coins in the Mario series. Wouldn't it be nice to see a list of which levels contain those? Where they're placed? Wouldn't it be nice if the code to organize that was all generated for you transparently? This is what I'm talking about. Anyway, I think that's what needs said, for now.
|
|
« Last Edit: August 26, 2015, 10:17:22 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
egofree
|
|
Reply #13 Posted on: August 27, 2015, 10:15:27 am |
|
|
Joined: Jun 2013
Posts: 601
|
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.
If i remember well, you did it, but then you had to put an older version, without the multi-selection, as egm reading was broken with the constants modifications. I am sure, however, that right now the windows installer, and the linux version don't have the multi-selection, as i tested them recently. Anyway as LateralGM is very unstable and not usable right now, it would not change anything, except if the stability problem is fixed.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #14 Posted on: May 20, 2016, 05:58:44 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
I just want to say, that I take full responsibility for this happening and I'm sorry I did not fix this when it first occurred. Rusky has now corrected the submodule for JoshEdit. https://github.com/IsmAvatar/LateralGM/pull/294https://github.com/IsmAvatar/LateralGM/pull/293It should now be possible to clone and setup LateralGM in just two calls. git clone https://github.com/IsmAvatar/LateralGM.git cd lateralgm git submodule update --init
LGM no longer has any code that JoshEdit does not, and this will prevent the two from ever getting unsynced again. Any changes to JoshEdit should be sent to the JoshEdit master branch, and then simply update the submodule and rebuild a new jar of LGM. As far as piping exceptions from JoshEdit again, I decided to go ahead and file a feature request for that on its repo. https://github.com/JoshDreamland/JoshEdit/issues/58
|
|
« Last Edit: May 21, 2016, 09:18:10 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|