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

526
Tips, Tutorials, Examples / Re: Setting up External Editors
« on: September 06, 2013, 09:45:15 AM »
Most people would expect you to write the setting without attempting to change the theme knowing it would fail.

527
Tips, Tutorials, Examples / Re: Setting up External Editors
« on: September 05, 2013, 06:53:36 PM »
Robert: That is part of LGM's original functionality. I have no idea what compelled you to map that properties file to a UI dialog without mentioning, "by the way, %s indicates the filename and, odds are, your program will want to know that."

Thanks for sharing, Ben.

528
General ENIGMA / Re: Contributing to the Wiki
« on: September 05, 2013, 08:33:28 AM »
Templates take time to propagate when edited. My preference would be to have pages requiring that link to instead link users to the correct download page on the Wiki. That said, I'm not opposed to the idea.

I should point out, though, that down the road, we will be adding a feature to this website for serving the latest version of ENIGMA. I'm not sure how far down the road we're talking about, so at this point, do whatever.

529
Third Party / Re: CLI and new IDE for Enigma
« on: September 02, 2013, 10:21:47 PM »
Heheheheh... I am very curious as to how these IDEs will turn out. Our third contender is, of course, NaturalGM. The projects vary in projected capability; let me give my honest (and skeptical) opinion of each really quick.

Contender 1: canthelp's (ssss's) project, Game Editor
The pros:
Being written in Python, this IDE has grown up extremely quickly. It borrows code from LGM and ENIGMA's code bases, as well as from Robert's IDE's codebase. In addition to that, it is by far the most functional and quickest growing of these IDEs. It may come as a surprise that in general, the IDE performs better than LGM, which is powered by Swing rather than Qt. This IDE is also being tailored largely to the needs of ENIGMA, which means it is likely to have the new features we need.
The cons: Everything in this IDE kind of melts together. Plugins are doable only by virtue of python being a scripting language. The author will attest to the code being quite messy. The user has to install Python to be able to work with this IDE.

Contender 2: Robert's C++ LateralGM
The pros:
Being completely native and designed specifically with ENIGMA in mind makes this IDE an obvious choice for a new user. Thus, like canthelp's IDE, we're likely to see the resources we've planned out within a few releases. In addition to the speed problems, this IDE seeks to address the EGM/GMX loading issues from its Java predecessor.
The cons: While focus has gone into keeping the file readers and writers modular, not a lot of attention thus far has been paid to general modularity. The individual editor components are not themselves separate; there is a lot of interdependency that is unlikely to be sifted out. Maintaining this IDE will also take back seat, as Robert is generally preoccupied with other facets of ENIGMA.

Contender 3: DaSpirit's NaturalGM
The pros:
Spirit has taken care to ensure modularity of each component of the IDE. It is (as far as has been seen) possible to develop a resource plugin for NaturalGM without regard for other resource plugins in the system, which means the odds of us finally adding an overworld resource to the mix are great (we should be able to duplicate the path editor plugin and go from there—its functional requirements of the remainder of the system are identical). Additionally, this should help ensure that users wishing to add their own resource types to ENIGMA are able to do so easily, as both IDE and engine will be able to accommodate them.
The cons: At this point in its development, I can't isolate any concrete issues with the software. That in itself is the only issue: at its present state, NGM is mostly backbone, but the backbone is shaping up comparatively well. The issues that I am able to foresee have all been addressed; only time will reveal any remaining problems as he starts on the concrete implementations.

530
General ENIGMA / Re: Contributing to the Wiki
« on: September 02, 2013, 09:49:48 PM »
Really appreciate the work you've done, Ben. Thanks a ton!

531
What error does ENIGMA fail with? That part's probably easy to fix.

532
Issues Help Desk / Re: Parenting and even inheritance
« on: August 29, 2013, 04:35:11 PM »
I told polygone to implement a new AST node for me, but he gave up in roughly the expected time. I'm taking a break from the compiler long enough to work with Ism on the EDC's new cloud server. It has been a bigger pain in the ass than anticipated. Both, actually. If you've been keeping an eye on JDI's progress, you'll notice the C parser in the branch throws roughly twice as many errors parsing <string> as the one in ENIGMA. That's the bad news. The good news is that it is parsing with 100% accuracy, which is both the source of the errors (if it can't parse accurately, it throws errors instead of assuming A-OK), and the reason that the new compiler is able to do the advanced type inference required for OOP.

I understand that in addition to the new features I want to see in ENIGMA, a lot of the longest-lived bugs are counting on the new parser. There's not much I can do about it unless I want to take another shortcut, which will only mean repeating this again in so many months.

On the plus side, the reason for my lack of free time is working against itself: I took courses over summer and am graduating in a few months. This will mean a brief transitional period wherein my output is even less than right now, followed by a time where the bulk of the stress in my life is between the hours of 9-5, and, if all goes according to plan, 20% of that stress will be this project.

533
General ENIGMA / Re: Compiling from source
« on: August 29, 2013, 04:25:11 PM »
What? The default OS is supposed to be Windows, as it is the only operating system too incompetent to identify itself from the CLI. I don't know where it's getting that ---------- shit.

534
Issues Help Desk / Re: Mouse over event
« on: August 26, 2013, 09:42:49 PM »
Each step, set a mouse_xprevious and mouse_yprevious. You can then get the direction using point_direction(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y), and likewise, the speed using point_distance(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y).

To also test if the mouse has passed through your object, use this:
Code: (EDL) [Select]
if (collision_line(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y, obj_myobject, true, true)) {
  double dir, spd;
  dir = point_direction(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y);
  spd = point_distance(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y);
  // ...
}
mouse_xprevious = mouse_x;
mouse_yprevious = mouse_y;

535
Off-Topic / Re: Introductions
« on: August 26, 2013, 08:36:27 AM »
Welcome aboard, Ben. Thanks for the help!

536
This is what happens when people edit code without bothering to check for things such as "does my code still compile?" before committing upstream. I've added .c_str() to the caption parameter Harri passes to the GTK functions. Try compiling now. If that doesn't work, let me know, and I'll set it up so I can fix the rest of them tomorrow.

537
Off-Topic / Re: Do you like this forum software?
« on: August 23, 2013, 07:57:25 AM »
This site is completely integrated into the Simple Machines forum software. The Wiki account system, the EDC, the issue tracker: all of these use the SMF developer API to work with accounts. I don't really feel like recoding them, and I haven't heard any volunteers.

Moreover, "It's ugly" is never reason not to use anything. Ugly can be fixed. We have complete control over the templates, including the private message box. Your problem with the private message system is an option which you are capable of enabling yourself—it just isn't the default. You can enable it by selecting the As a conversation view instead of All at once. As a special note, if you don't save a copy of your message in your outbox (also not the default), it won't display in the conversation. You can enable doing so by default from your PM settings, too.

I'm guessing MyBB doesn't support that, since you've never heard of it before. User preferences aren't really an uncommon feature of SMF, as opposed to in hacked-together, 20KB pieces of forum software I could write myself in a couple of hours.

That said, if you have any legitimate reasons not to use SMF, go ahead and post them.

538
General ENIGMA / Re: Learning to develop?
« on: August 21, 2013, 07:40:09 PM »
1. C++. If you'd prefer to develop a different language plugin for ENIGMA, we'd be happy to support it, but the work would be enormous (Unless you're interested in continuing the existing, but very early, JavaScript port).
2. Git's pretty easy to pick up on. Most of us learned from small tutorials on the internet; I can't find the one I used, but I'm sure the others are just as good.
3. You can start flamewars asking what constitutes "Good coding practice." I can't even tell you "just comment your code well," because lately, the trend has been "self-documenting code," which uses functions so tiny as to be self-explanatory. In the words of my journalism advisor: just try not to suck.
4. It is certainly preferable to use Linux, as the package manager can fetch and set up all your tools for you. However, a good number of our developers use Windows, and MSys-Git comes packaged with the ENIGMA zip.

The basics of Git are pretty simple. The idea is this: everyone has a local copy of the entire git repository, history and all. Because of this, no one versions binaries; doing so causes terrible bloat, as you have all the previous versions checked out at all times. On the plus side, you can commit and use all features of version control locally. Everyone can, even without having repository access. You only need credentials when you're ready to publish your changes.

When you obtain changes from the Internet, it's called a pull. So basically, we enact changes, you pull them. When you publish changes, it's a push.

Our publishing is handled through GitHub. GitHub makes it easy to fork a repository; you just sign in and press the "fork" button. A fork is just a copy of the repository which you own entirely; you are free to make any modifications to it you like (per the terms of the license of the code, which, in our case, is GPL). When you are satisfied with the changes you've made to your fork, you can drop a pull request to the owner of the repository (in this case, us), and after reviewing your changes, they'll decide whether to accept, or pull them.

When I go to commit changes, I usually start by running git status to see what's changed. That way, I can see if I'm about to accidentally commit a file that doesn't belong in the repo. You'll notice the Windows developers use a UI frontend for git, and carelessly commit binaries to the repo all the time. By listing the files before committing them, I usually avoid that. After checking status, I run git add --all and then git reset HEAD <file> for any files I didn't want to add, if any. Usually, those files go in .gitignore, a file listing what files and directories git should ignore. After that, git commit or git commit -m "My commit message" to commit them, and then git push to publish them, if they're ready.

Words of caution: I think the git checkout command is one of the few commands capable of destroying something you've worked on. I have never found a way to undo it.

As far as developing, I don't really have any words of caution for you. Something to note is that if a check needs done to avoid users performing invalid operations on something, we try to confine those checks with #if DEBUG_MODE, so as to avoid slowing the engine down on trivia where the check takes longer than the operation.

539
General ENIGMA / Re: Executable Icon and Description on Windows
« on: August 21, 2013, 03:27:03 PM »
I'd set up a descriptor that allows specifying the output format for the resource file from EnigmaStruct, but it got brushed aside back when MinGW's windres was failing.

Since they've apparently fixed it, as long as you have it working, I don't really care anymore.

540
Issues Help Desk / Re: full screen, scaling.
« on: August 21, 2013, 10:54:23 AM »
You probably want views. They're part of the room editor. The window is automatically sized to accommodate viewport boundaries, and you can display an area of any size in a view of any size: it will be scaled for you automatically.

If you actually want it to be scaled down, use a viewport smaller than your view width/height. Otherwise, just leave the viewport size equal to the view boundaries in the room.