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 - Josh @ Dreamland

Developing ENIGMA / Re: Migrate Releases
« on: September 05, 2015, 07:44:36 pm »
There's hardly a more descriptive change title than "Hacks in a fix for multidimensional array subscripts. Fixes #904." The Git spirit is small commits with simple change descriptions. Coming from Subversion initially, I prefer larger commits with more detailed messages, to which git is also conducive. The list you gave essentially embodies the spirit of source control.

Google does not use git itself. Google3 is a completely linear, monolitchic codebase. It is not possible to commit code to Google3 that does not build, unless you issue commands to bypass the mechanisms in place. If you do that, you had better know what you are doing.

Anyway, it's clear to me that you know what these commit messages should look like. You may find tags or merge commits helpful. That is, do your work in your own branches with lax commit messages, and then either flatten them for commit to enigma-dev/master, or merge them and specify a useful commit message. You might consider annotating these with some kind of searchable token so that you can create changelogs between versions automatically. Following this, even if you were not careful to annotate all merges to master, you could still crawl all commits for useful changelog points. This could be as simple as putting Changelog point: before each line in a commit description that actually contains noteworthy text.

Just some ideas.

Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 10:38:09 pm »
It's true that I never tagged a release as r4. Things kept changing—more than anything, my expectations. You could number from there, or you could just call it V1. Or V1 RC1 and have fifty of those before you just call it V1. It's up to you. I prefer rolling releases. The way version control is supposed to work is that master is supposed to be stable at all times; ready for a nightly build whenever. You then have multiple work branches that might not build, or might not work. This never really came to be in ENIGMA... my attempts to introduce it ended badly.

GitHub can tag releases for you, yes.

For a long time, the "Developer" tag was just a repaint of "Administrator," but I eventually fixed that (they're regular SMF membergroups, now, and I hard-coded tags for them). I wasn't very diligent with updating assignments, though. Of course, Harri is a privileged member—just not an administrator. This is mostly because the admin panel is duct-taped together, and it's very easy to break something in it, so I tend to stay out of it myself and don't see a reason to give anyone else access. But yes, I only fixed his "Developer" badge a few months ago. In my defense, there were political reasons that had nothing to do with my own feelings which prevented this change in the earlier stages of the board.

General ENIGMA / Re: Joshedit
« on: August 26, 2015, 09:24:55 pm »
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,
Code: (cpp) [Select]
// 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.

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

General ENIGMA / Re: Joshedit
« on: August 25, 2015, 08:04:47 pm »
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.

General ENIGMA / Re: ENIGMA progress
« on: August 01, 2015, 10:58:21 am »
I'm impressed, Harri. I don't have much else to say.

Issues Help Desk / Re: Some Fervi's Question
« on: July 11, 2015, 08:41:14 pm »
Sorry, Harri; I thought I hit reply, but apparently my response is victim to the ages. Apparently the question of what a FSM editor would look like has been answered by Unreal3D. I would prefer the ability to group nodes (or ideally, to have nested state machines in nodes, for different systems to use) in my implementation, but otherwise, the U3D editor looks sound.

I don't know what you mean by every variable being a switch statement. I worked hard to make sure that isn't the case, even in var. Lookups between objects are switch statements when the type of the object is ambiguous (which, for ENIGMA, I think is every dot-access for custom locals).

I think our best option for providing GM "support" in the future is to make sure that the warnings and errors the compiler emits are easy to operate on. For example, GCC will warn when you say [snip=edl]if (someVar = 10)[/snip], suggesting that you wrap the assignment in parentheses. If ENIGMA emitted this warning, a compatibility layer (read: trainspiler) could replace = with ==.

I already had proposals to deal with Game Maker's lack of type system (and ENIGMA's failure to strongly introduce one). In Game Maker, [snip=edl]choose(c_red, obj_sunflower, 10.5, "hamster")[/snip] is completely valid. ENIGMA retains this; the return type is var. In a better language, this would be disallowed, while [snip=edl]choose(c_red, c_green, c_blue)[/snip] would be allowed, and even [snip=edl]choose(obj_sunflower, obj_ladybug, obj_cloud)[/snip] would be permitted. This is the easy part. The hard part is knowing that [snip=edl]instance_nearest(x, y, obj_sunflower)[/snip] is not just instance_t, but an instance of obj_sunflower. I am still thinking about elegant ways of addressing this, from a language design standpoint.

I won't labor over what else to include in this post, because if I do, it might end up not being posted, again. So yeah, just some initial thoughts.

Issues Help Desk / Re: Linker crash
« on: July 04, 2015, 09:09:40 am »
If I had to guess, this is because Bash is capable of parsing any number of characters into an array of strings, while Windows is a worthless pile of slag. I don't know of a different way of conveying files to be linked to the linker, and those ways would be pretty barbaric, anyway.

There might be a way to switch Make's shell interpreter to Bash. Does running make from MSys-bash still give the problem, or only running it from cmd? The printout you gave looks like cmd.

There are ways to tell if you're in a bash environment from within the makefile, if you'd like to print errors.

Another solution would be to build static libs for each system before linking them. A third solution might be switching to cmake.

Issues Help Desk / Re: Some Fervi's Question
« on: June 30, 2015, 07:29:24 pm »
You've been missing out on a lot of conversation on that topic, Harri. The short of it is, I think Game Maker (and ENIGMA by extension) would be more greatly benefited by, eg, a finite state machine editor than by the "perfect language" I was trying to design. I still want a highly cross-compilable language, but I think that everything that made Game Maker and ENIGMA any good was in the editor, not in the compiler. The compiler's just the thing that makes it finally work, and ENIGMA wasn't even really good at that.

I haven't finished planning something elaborate enough to rekindle my interest in developing it, but we keep tossing ideas back and forth. PHP isn't a consideration; it might actually be the worst language in existence.

Issues Help Desk / Re: Cant open ENIGMA because of LGM
« on: June 02, 2015, 09:07:38 pm »
According to that exception, one of your extensions is missing an ID. This shouldn't really happen, which is why we've never seen (and therefore added handling for) that particular exception in the past. Have you tweaked any of ENIGMA's extension files?

A NullPointerException during save can mean any number of things. Do you still have the file that failed to save open? You can attempt to save such a file in different formats to avoid losing work (assuming that the problem occurs every time you save in the same format). If not, did you save the exception it threw? It would be useful to have so we can fix whatever went wrong (or at least make it so LGM recovers from it more cleanly).

If you closed LGM as soon as it failed, and it didn't save the resources you changed before the exception, and the exception caused the save to abort, then no, there's no way to recover those changes.

If you were asked to save because you tried to close LGM, and then the NPE occurred during save, but LGM nonetheless closed, let us know. That's a pretty nasty bug.

All your assets are yours, yes, and the pre-ENIGMA source code is completely your property. This is for the same reason that works created in GIMP or InkScape or even MS Paint are yours. Your game is a work you have created in ENIGMA, and probably various other tools. You may license it how you wish.

But that's not the whole story.

When you compile your game in ENIGMA, it is transpiled (a specific synonym for "compiled") to C++. The code it generates still belongs to you (just as the code InkScape or Flash generates still belongs to you). But then ENIGMA links your game's source against its engine. This is where things get hairy.

Because our engine is GPL, your use of it in combination with your source code (ENIGMA-generated or otherwise) subjects you to the terms of the GPL. Thus, you are free to use and modify it locally however you want, but as soon as you release it to the public, you must provide source code. And because the GPL is a viral license, you must also provide all source code that links against it. This means you must provide the source to your game.

It gets worse. The GPL is crafted in such a way as to prevent companies or groups or individuals from providing only obfuscated versions of the source code, which by some definitions, ENIGMA-generated source code qualifies. Specifically, the GPL defines source code to be "the preferred form of the work for making modifications to it." So that means the plain GML/EDL, like the kind you see in your GMK/GMX/EGM.

Other (non-code) assets are easier to license in GPL-compatible ways, and it's easier to work around that.

As Harri pointed out, members of this team have no intention of enforcing the GPL on users who are legitimately distributing games. If one of our contributors is nagging you, you should report that to one of us. Only copyright holders can enforce the terms of the GPL, so if anyone else is nagging you, you may explain or ignore them. That said, it should be sufficient to take us at our word that we will not force you to release your game as a GPL work. However, we are not legally bound by that word unless you get it from each of us in writing for your specific product, which creates potential trust issues. So if you want to play completely safe, the only sure-fire way is to go for the signatures or adhere to the terms of the GPL.

So let's talk about circumventing the GPL, or leveraging it to suit you. Specifically, you mentioned non-code assets.

Since your game as a combined work is covered by GPL, your users are theoretically free to use, modify, and distribute it as they choose. This may sound problematic at first, but it also means that they are free to use proprietary resources with it locally. Theoretically, you can include placeholder art with your game, or include no art at all. You could then distribute those assets separately, under whatever license you please—such as a basic license to use the art with games locally, but not to modify or redistribute it. Thus, while users are allowed to use the art with your game on their machines, they are not allowed to distribute the two as a combined work (they are forbidden from redistributing your assets).

This is one way of preventing legal redistribution of your complete game. However, since there are other copyright holders of the GPL code, those copyright holders are able to demand that you cease to release packages bundled in such a way. This would be exceptionally petty dickery, which you should once again report to the rest of us. This cannot lead to you being forced to GPL-license your art assets, however.

At the end of the day, though, I'd just like to point out that if people don't want to pay for your game, they aren't going to do it. And if they want to reverse-engineer your game, they're going to do it. Yes, source code makes it easier, but it also makes it less of a specialization, which serves to remove the black market from around it as well as the demand for doing so. In my opinion, you'd do just as well to point out that you expect to make $x/copy and that buying a copy is the right thing for users to do. Nothing in the GPL stops you from putting a gentle nag in your game to remind users to support you by purchasing a copy. Honest users will do so, and dishonest users won't, either way. Only a dick would redistribute copies of your game without that nag in them. Just don't overdo it, or it'll become much more reasonable for people to want to do that. ;)

As for other people publishing modifications, it can happen, and as your game grows in popularity, it will happen. If you cease to maintain your game, someone else might make a spinoff that could catch on. The good news is, you can always cherry-pick things they have added to your game—their changes must be GPL as well. The bad news is, if you don't actively do this, or otherwise maintain your code to make it appealing, or do something to maintain presence as the real originator of this game in the eye of the public, then the world will forget about you and move on to other versions. But then, at the point where your game is really that popular, you'll probably have the resources to take your project in all kinds of creative directions, and regardless of your license, ceasing to maintain your game wouldn't allow you to thrive in the current gaming market for very long.

So yeah, you have a lot of options relating to how to distribute and "control" the distribution of your game. But I wouldn't worry about it too much, especially before any serious development or planning begins.

And regarding the bit on modified code, don't worry about that—you're linking against an unmodified ENIGMA. A link to our repository would be more than sufficient.

Issues Help Desk / Re: Compilation problems on Linux 32bit
« on: April 10, 2015, 05:37:42 pm »
We don't currently have a list of SuSE package names. Feel free to add one to that Wiki page. Apparently someone rewrote it without an understanding that Ubuntu isn't the only Linux distribution.

Announcements / Re: We SSL now
« on: April 09, 2015, 05:31:17 pm »
Seems to be on your end. Just tried it on this machine without issue. Other forum pages will complain because user-posted content (images, mostly) is not secured, but login should work without issue.

General ENIGMA / Re: First Impressions Of ENIGMA
« on: April 01, 2015, 10:56:23 pm »
I'll develop again, at some point. I have other interests, at the moment (and an increasing number of them). Though I'll admit, there's something I'm hoping will come along that would rekindle my interest in the project.