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

Pages: 1 2 [3] 4 5 ... 187
31
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.

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

33
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?

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

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

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

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

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

39
Announcements / Re: Java Easy Image Editor 0.0.1
« on: March 29, 2015, 09:04:42 AM »
There are migration steps, Ism; if you want to be totally safe, you can manually move the Google Code repo somewhere new on GitHub.

40
General ENIGMA / Re: New To Enigma
« on: March 06, 2015, 09:11:28 PM »
The project isn't as active as it used to be, but yes, it's very much alive. Your options on Linux are a bit limited, but even apart from that, I think ENIGMA is still a viable contender, especially if you want extensibility. Depending on where you're coming from and what you're looking to do, there are certainly better options, but if you just want to take game development for a spin, then ENIGMA is probably a good choice.

41
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: March 01, 2015, 11:02:34 PM »
Strange. It seems something LGM/OpenJDK is doing is aggravating a compiz bug, which I assume is a big part of how Unity operates, so Unity gives up the ghost and logs you out. I have no idea why running LGM without ENIGMA would solve this problem. I'll see if we can't reproduce this in a VM.

42
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: February 26, 2015, 11:53:01 PM »
Strange... The window opens as a tab for me, and closing it returns it to the tab pane. This is extra strange, because you are using the exact same OpenJDK build I am. Would you be willing to copy LGM somewhere it won't find ENIGMA, and verify that the problem persists without it? If no C++ code is involved, then this is an OpenJDK bug, and we'll need to file a ticket about it. This sort of thing has cropped up before; last time, using drag and drop at all after displaying a splash screen caused OpenJDK to crash the X window server. This time, your guess is as good as mine what might be causing this crash.

When it crashes, what does your system do? Does it black out, or just become completely unresponsive? Do the LEDs on your keyboard flash? Flashing LEDs indicate kernel panic, which theoretically shouldn't ever happen, and spells certain reboot. Otherwise, did you try switching to TTY1 (control-alt-f1) then back again (alt-f7)? Some minor X hiccups cause me to lose keyboard and/or mouse input until doing that. Can you move the mouse at all? Does anything on the system start consuming tons of memory? (If OpenJRE begins consuming more than 500MB of memory, that's another bug—Java processes are supposed to have limited memory).

Apologies for the 20 Questions. It'll help me to know exactly what's breaking (though it seems at this point that no LGM code can be causing it directly).

43
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: February 24, 2015, 11:48:04 PM »
3) Close the event selector — The event selector is a tab that can't be closed. How are you closing it? Switching tabs or floating the tab and closing it does nothing for me. I can click "Modify" all day, no problem.

44
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: February 20, 2015, 11:23:06 PM »
That sounds like a JRE bug. What platform are you on? OpenJRE or Oracle JRE? What Java version?

It's a bit severe a bug to ask you to try to reproduce it, but if you can find consistent steps to do so, that would help. This is the first time I've heard of this issue.

45
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: February 19, 2015, 09:36:04 PM »
Even with that ugly indent scheme, the XML will be on the order of twice as large for a typical room. The only advantage of the XML is that named attributes allow you to elide attributes with default (probably zero or one) values. If this proves necessary, YAML also allows this using maps. So <inst id="1000009" obj="2" x="32" y="432"/> becomes {id: 1000009,obj: 2,x: 32,y: 432}, which is pretty meager savings, but that's still the worst-case, and large rooms will be mostly instances. The ease of parsing of (E)YAML vs XML is also a major feature. And if we're going to go toe-to-toe with full specs, XML will lose outright by YAML's superior support for primitives, node types, and even node references.

Not to mention that the best thing about YAML is that users' code appears verbatim in the format, with the exception that it is indented. I'll grant that it is unlikely for code to contain "</crc>", and unlikely for a given user to want to edit the file manually, and that together this means it's extremely unlikely that a user would want to paste in code with a closing tag, but correctly-formatted code uses HTML entities in place of reserved characters (and there are lots), so in general, a user can't open the room file and copy the code somewhere else, because if (x &lt; xprevious) is not valid EDL.

The comment line we would place in the YAML would be optional; it prevents cases where valid code entered in an IDE would break the format. In the 99 percent case, pasting in a well-formatted piece of code and indenting it twice will suffice, because the first line usually has the least amount of indent. The 99 percent case of the 1 percent case is where someone decided to indent their opening doc comment. They will have to either not do that, or place the opening YAML comment, which we might consider simplifying to, eg, eight or more hyphens.

Pages: 1 2 [3] 4 5 ... 187