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

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.

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

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.

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.

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.

Issues Help Desk / Re: Extension .egm does not match EGM?
« on: February 18, 2015, 10:59:07 pm »
XML is the ugliest imaginable format. It's extensible by nature, yes, but it is extremely verbose. And while its hierarchy makes storing code obvious, the problem is simple enough to work around in YAML. As for XML's propensity for hierarchical data, well, rooms are pretty linear in the scheme of things. I posted a proposal somewhere (or maybe I just started coding it and didn't finish) about what I wanted rooms to look like. Consider something like this:

Code: (YAML) [Select]
name: room_0
: 00C0FF
- name
: bkg_3
: 1000
: yes
: no
- name
: bkg_overlay
: -1000
: no
: no
- id
: 0 # Optional for in-sequence
: yes
: 0
: 0
: 640
: 480
: 0
: 0
: 640
: 480
: obj_player
: [32, 24] # Also allowed: separate lines for h/v
: [4, 4]
- id
- object-index
- x
- y
- rotation
- obj_player
- obj_dirtwall
- obj_7
: [
  [1000001, 0, 64, 400, 0],
  [1000002, 1, 0, 432, 0],
  [1000003, 1, 32, 432, 0],
  [1000004, 1, 64, 432, 0],
  [1000006, 1, 96, 432, 0],
  [1000007, 1, 128, 432, 0],
  [1000008, 1, 160, 432, 0],
  [1000009, 1, 192 432, 0],
  [1000012, 2, 32, 432, 45] # obj_7 is still index 2 on our list, even if its id is really 7.
- ind
: 0
: |
   // Code begins here
    can_fly = false;

- ind
: 8
: |
   // Code begins here
    text = "To jump, press [space].";

The "// Code begins here" bit is to prevent issues with code snippets wherein the first line is indented for whatever reason. This is important since YAML is indentation-based. XML deals with this by escaping < and >, which I also disapprove of. Comparatively speaking, the cost of YAML is cheap.

I'll also point out that the verbosity around viewport/projection can theoretically be replaced with viewport: {x: 0, y: 0, w: 640, h: 480}, although e-YAML doesn't presently support that.

Announcements / Re: Google Summer of Code
« on: February 18, 2015, 09:08:01 pm »
daz: I have paid literally seventeen cents for my Rackspace Cloud Files so far. Cloud files is not Cloud Servers. They charge by the megabyte, and we're using a couple dozen.

And yes, our GSoC participation is out the window due to lack of proper coordination, and for an overarching reason: more minimum-time contributors is not what we need right now.

Announcements / We SSL now
« on: February 11, 2015, 09:09:40 pm »
I recommend using our shiny new SSL connection for signing into the forums from here on out. I will look for a way to enable this by default.

We don't want the default forum browsing to be secured, though, as you will just receive warnings that the content users post (images, avatars, etc) will be from third-party sites.

However, I made some arrangements, and these domains and the certificate are now paid through 2020. The website, however, is not. Right now I have launched an IRC bot, which the host said was okay despite the terms of our VPS lease. I will continue to renew this VPS as long as they allow both of these to run. I will also be, at some point in the next century, setting up a build bot here. If at any point this becomes "too much load" for our VPS, we will be moving to a dedicated server.


Announcements / Re: Google Summer of Code
« on: February 08, 2015, 08:28:01 am »
Yes, the IDE is my number one pain point. I know Java; I have to work with it far more often than I like, actually. The issue is that even if I do add the resources and features I want LateralGM, the amount of work required to make it work well with the EGM format seems out of my reach. That's why I've started putting my chips on NaturalGM, which I think might warrant a spot in GSoC, if you pardon its small age. But ENIGMA? Yeah, I might let this one go....

I finished my MEI generator and am moving back to the flags header. A chunk of today will be spent doing my laundry (about three weeks' worth) and going grocery shopping. I might finish Flags today, but I doubt it. I'll probably finish it tomorrow after I get home from work. After that, I have one more pet project that is more interesting to me than ENIGMA, and then I guess I'll try to muddle through this merge once more.

I'll be a little more clear; the parts of ENIGMA that are now interesting to me are the parts of ENIGMA the IDE doesn't support. And I don't want to do Java IDE work. I don't really want to do IDE work at all, actually; Java isn't all that bad for it. But Swing is broken and LGM needs major surgery on its other two tiers for this, so what's the point?

Announcements / Re: Google Summer of Code
« on: February 07, 2015, 08:44:23 pm »
I'm afraid it's not that simple. It isn't that I have so little free time—it's just that when I sit down to fix one of ENIGMA's problems, I find myself traversing a whole loop of increasingly large problems until I lose interest and stop working. There are so many broken things with it that I just don't want to fix any of them, because I have this feeling that it makes no difference in the long run. And the amount of time required to fix one item correctly isn't itself all that high—it's just that I only have two days a week that are all mine, and it isn't long enough to fix something completely. And when I start to fix something and am then interrupted by a week of work, I lose interest in it, and then it gets bit rot. So really, it's more an issue with contiguous ENIGMA time. Even when I do take a week off, I spend it visiting family. So...

I actually have more free time now than I did in college. The problem is focusing on ENIGMA long enough to make a difference. When I was young, I'd make a plan and stick with it even if evidence (read: Rusky) suggested it would eventually fail. This is why anything ever got done. Now that I'm older and can see around corners, it's not so easy to just continue down the path of gradual improvement.

Most of the little things in ENIGMA are done. The project right now probably doesn't really need people to do little things so much as it needs someone to finally get the time to do big things. But I figured it'd be worth bringing up GSoC anyway. The reason I created this thread is because I'm not personally convinced we should participate in GSoC, for just those reasons. But if you can convince me, I can convince Google.

If you want to know what I'm working on this moment, it's a program that reads in a video and produces MEIs of frame intervals of a given length. The reason for this is complicated and involves my landlord. Before that I was working on a new flags library, which is for general-purpose use. Before that I wrote a world editor for Terraria worlds. Before that was Christmas, and around that time, I recoded a piece of ENIGMA's compiler, and eventually did merge that in. So that's one less thing that needs done before I can actually get anywhere with it. Before that, I don't really remember.

I don't know that there's a simple answer to what it will take for me to sit down and finish that new compiler. IDE support for all the wonderful things dazappa is requesting would certainly help. Maybe I should nip this in the bud and just write a damn IDE. If I finish the widget framework I started in ENIGMA ages ago, that would probably help. But even then, ENIGMA on Windows is a nightmare. I don't know how you put up with it. I guess you're clever enough to set up your own compiler so you don't have to put up with the release zip cheeseboy started Robert compiling. The whole thing is mucky, and I just don't like touching it. And every little administrative task wastes so much goddamn time. I spent four hours today trying to figure out how to set up an SSL certificate for ENIGMA's site. I've wasted tons of time looking for a good license. The EDC's a wreck; I've wasted hours on it, too. There are things I'm not good at, which I normally end up doing, too. It apparently doesn't need done that bad, of course, because my attempts to just ignore it all have been largely successful. But then it just balls up and I don't want to go back.

I mean, if all you want is a new parser, it's in the branch. It doesn't support all the things I wanted it to, but it's correct. It will want the new JDI, which is in another branch. I went to merge those, but my lexer changes were incompatible, so I went to consolidate those so future changes would be easier to merge in. I then discovered a couple problems with the way JDI handles macros, and went to fix those. It got messy and resulted in a slowdown, so I elected to start replacing the macro system, which I hoped would solve both problems. I got distracted doing other things, including the fucking EDC and license problem, and never finished.

I imagine that gives you some idea of how I feel.

Announcements / Re: Google Summer of Code
« on: February 07, 2015, 05:11:03 pm »
I have created a new Wiki page for these tasks. Feel free to edit the page to elaborate on tasks. If you add a task, please also begin a discussion about it here. Please don't delete a task without discussion beforehand.

Announcements / Re: Google Summer of Code
« on: February 07, 2015, 05:03:53 pm »
  • User events. I thought polygone finally got those working. Are you sure they don't? If not, I'll consider adding them as a task.
  • Sound system improvements. Robert added most of those, but he did so when he was new. No idea if they work. Worth investigating, and can certainly be a task.
  • Particle systems with attractors etc Does forthevin's extension not support attractors? Tell me what's missing, and consider it a task.
  • Views system is extremely inconsistent when compared to GM I'll need you to elaborate, again... :P
  • Pixel perfect collisions We definitely have these. Are we missing rotation? What's missing?
  • Polygonal collisions with collision editor Added as an IDE task.
  • Full box 2d integration Added as an extension task stub. Can you elaborate?
  • Working HTML5 export via emscripten or equivalent We have this. It was never hooked into LateralGM because it and the compiler are not extensible enough.
  • Android because god knows we failed. Historically speaking, the reason we don't have this is because I'm bad at holding people's hands through it. I don't think GSoC will change that.
  • New compiler. Good wishlist item, bad GSoC item. :P
  • Force rename of resources with junk names. Okay, this is a small enough task that we can add it.
  • Game debugging. Required metadata exists in now-bitrotted compiler branch. Still less effort to implement in a new system than current master.
  • Game profiling. See above.
  • Room speed was not consistent. Dozens of people have worked on this, and it's my understanding that it's finally fixed.
  • Export games instead of having to go to temp files. Solved, then broken, then solved, then broken, then solved, then broken, then solved, then broken, then solved, then broken, then actually solved, then really broken, then solved, then broken, then solved, then broken, then solved (?)
  • Async events from GM Don't understand the use of these; not personally invested in task enough to hold someone's hand through it.
  • Configurations like GM. I know nothing about these, but IFDEF makes me think it's a parser task. The only task I'm honoring for the current parser is "SHRED AND BURN."
  • Texture groups support like GM Sounds good. Also sounds mostly like a UI task (Correct me if I'm wrong).

Harri: are you currently a student? Or, are you interested in mentoring?

Announcements / Re: Google Summer of Code
« on: February 07, 2015, 04:07:33 pm »
Dime a dozen tasks are great. They're a great way to get a new contributor interested in the system. I think we'll hit a snag trying to sell some of the larger tasks to people. Keep in mind, the candidates are going to be paid, but they still get a say in the project they work on. We're competing with how interesting a task we can generate.

So, can anyone list any of these "dime a dozen" tasks?

Announcements / Re: Google Summer of Code
« on: February 07, 2015, 12:02:31 pm »
The rebuttal I'm receiving is that it is the job of the mentor to provide guidance for the recruits. This is certainly the case, but we can't postpone things like authoring test games until the student has already created code. We should have a sample game or other test suite to give the student as soon as they join. At very least, in the case of a networking system, we should have a game that is working except for the networking bits, which can be broken, commented, or completely missing—as long as there is minimal effort to adding them in. We can't have our mentors scrambling to write a buggy test game while the student hangs around waiting. That would be a waste of the student's time and Google's money.

And yes, students are suppose to be somewhat autonomous and generate their own work items—this does not mean that we can leave the mentor and student to completely improvise the entire process. Some real planning ahead of time is still required. At very least, students should have a breadcrumb trail to follow in the absence of the mentor.

Here is an interesting news bulletin: I am allowed to mentor as a Google employee, and current contributors who are also students are allowed to sign up.

Announcements / Google Summer of Code
« on: February 07, 2015, 11:56:23 am »
Hello, everyone; long time, no see.

Google Summer of Code signups are around the corner. Are we, as a group, interested in participating? I am considering sponsoring either ENIGMA or NaturalGM, or even both, depending on which project is able to generate an workable list of tasks for contributors.

The problem with ENIGMA's participation is that its contributor base is already mostly college-level help, so the majority of tasks that would be easy to delegate to new help are already completed, while the remaining work requires more skill and background info on what ENIGMA is and what it is supposed to be.

That said, looking over the wiki page from last year, some of the workpoints seem nearly feasible. The problem is that no one has started any of them. If we want help, we have to be serious about having room for participants to actually contribute code. We can't be allocated a new contributor and expect them to figure out what ENIGMA is and just start tacking entire new systems on. Work points such as "Implementation of an Asynchronous Networking System" are entirely too much work for someone who is unfamiliar with the project. Does the Network_Systems folder even work like the other systems folders? How will a new contributor even know they are on the right track?

If we are to participate, we need tasks that begin with ten lines of code and end with implementing an entire system. There needs to be room for a contributor to start small and grow in the project. I can't endorse ENIGMA with such course-grain tasks. This is the reason I stayed out of the GSoC planning last year, and if we can't generate a better task list this year, we'll hit the same fate.

We can improve the "Implementation of an Asynchronous Networking System" task by creating a reference list of what we actually expect this system to look like, and offering an example game which, given these functions, should be able to be played over a network. We can't expect a new contributor to write the game that tests his or her new functions. That's way too much work for someone who has never heard of the project.

Related: Do we even have a simple dev wishlist, anymore? I occasionally hear about X huge thing that is completely broken and everyone has been working around, but I have essentially no idea what people want to see out of this project right now, aside from a new compiler. It seems to me that we have no little tasks; the project is waiting on someone to "just go through and fix everything." Does anyone care to prove me wrong?

To be brief, if we want to participate in GSoC, we have to make sure we have tasks that are actually suited to someone who has never heard of the project. Otherwise, I guess we can sit this one out.