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.
1
Announcements / Major Security Bug "ShellShock"
« on: September 25, 2014, 11:33:12 am »
If you haven't heard the news, another security vulnerability probably worse than Heartbleed has been discovered in Bash.
With it, an attacker can craft a very simple http response and have your server run arbitrary code.
As soon as we heard the news, we immediately tested it and updated bash to the latest patched version, just to be sure.
We do not believe our server was vulnerable to these types of attacks, as our apache does not seem to interact with Bash in that way. Our bash was indeed vulnerable, but again, nothing seemed to use it, so no harm there.
Other sites may still be vulnerable. An attack could publish database information, files, and other requests from users. This means that an attacker could gain access to passwords, credit card information, and public keys, even if the server isn't storing them - just from the fact that they are sent over the net to the server at some point.
Standard security precautions are recommended. Change your passwords regularly. Be careful where you enter your credit card information, and frequently monitor your account transactions and statements.
With it, an attacker can craft a very simple http response and have your server run arbitrary code.
As soon as we heard the news, we immediately tested it and updated bash to the latest patched version, just to be sure.
We do not believe our server was vulnerable to these types of attacks, as our apache does not seem to interact with Bash in that way. Our bash was indeed vulnerable, but again, nothing seemed to use it, so no harm there.
Other sites may still be vulnerable. An attack could publish database information, files, and other requests from users. This means that an attacker could gain access to passwords, credit card information, and public keys, even if the server isn't storing them - just from the fact that they are sent over the net to the server at some point.
Standard security precautions are recommended. Change your passwords regularly. Be careful where you enter your credit card information, and frequently monitor your account transactions and statements.
2
General ENIGMA / LateralGM endorsement
« on: December 17, 2013, 11:17:16 am »
As of today, I'm officially endorsing Robert B Colton as the maintainer of LateralGM. My hope is that this will allow speedier development availability to the public due to less administrative overhead from having to go through me.
I'm aware this is a controversial move, but I have made it clear that I am unable to continue maintaining LateralGM due to a lack of time and a refocus of priorities. As a result, with me being the sole maintainer of LGM, it has stagnated and has been unable to compete with the products that it is intended to compete with, while Robert's fork has advanced a whole slew of new features with the future in mind.
Personally, I'm not a fan of Robert's software development methodology, and he has a lot to learn, but his commitment to the product is ineffable and, with me no longer available, I see no other way.
That said, my methodology and intentions with the product are explained in a few places, but I will restate them here in hopes that maybe Robert will listen and lead LateralGM to a solid future and not turn it into vaporware or such.
* First and foremost, LateralGM was created as a tool for dealing with the Game Maker file format. A vast majority of the users of LateralGM look to it as a way to open their GM files, especially their corrupted files. As such, this is the core of our product and it is never to stop functioning. Likewise, if LGM corrupts files, this is a critical failure.
* Secondly and finally, LateralGM has succeeded by learning from the mistakes of other products. This was the driving force behind LateralGM becoming a full-fledged IDE and not just a file-format tool - to deal with the shortcomings of Game Maker.
The reason it succeeded was because I saw where other products failed - such as G-Java and G-Creator. In my opinion, the reason they failed was because they focused on features and not core functionality. They had some fantastic and admirable features that looked very futuristic and fancy, some of which would be awesome to add to LateralGM, but without a solid foundation/core, it was just feature vaporware. As such, LateralGM learned 2 things. First, develop a solid core, and make sure it never breaks. Second, Features are second-class citizens, releases are first:
So declare the set of features you would like to see in a release, and then be ready to declare feature freeze - a time in development when you will introduce no new features into a release and will instead focus on fixing ALL the known bugs before that release. This is extremely difficult, because features are fun and leftover bugs are a pain, but it's also extremely necessary. Leaving bugs behind is what GameMaker does, not LateralGM. That said, some bugs aren't worth fixing, but they are rare.
A release is not "I've made a bunch of features guys, here, have a release so you can check them out." - that's what a prototype is for, and that's what Feature Freeze beta is for. You've made a bunch of neat features, congratulations, now fix all the leftover bugs and THEN you can declare a release.
Are there improvements to this method? Sure. But we don't have the manpower for it. From being in the workplace, I've learned a few things about software development methodologies and releases that more manpower affords you. We can't just truck through releases like they do - we need to buckle down and focus on what we said would be in the current release, or else officially bump it with good reason and update your roadmap.
I miss working on LateralGM and working with you guys. It was a lot of fun. I wish I still had the time to work on it. Maybe some day I will find some time - believe me, I've been thinking hard on ways to factor it in. If and when that happens, I can't say if I'll continue development in my own fork from the old code (where I left off) or if I pick up Robert's code and try to deal with our differences. But one thing's for sure - at this point in time, there's only 1 thing about LateralGM that I care about and that concerns me, and that's the list of open bugs. Those bugs need to be fixed, and if they're not and we keep releasing features, we are headed down the same path as G-Creator.
I'm aware this is a controversial move, but I have made it clear that I am unable to continue maintaining LateralGM due to a lack of time and a refocus of priorities. As a result, with me being the sole maintainer of LGM, it has stagnated and has been unable to compete with the products that it is intended to compete with, while Robert's fork has advanced a whole slew of new features with the future in mind.
Personally, I'm not a fan of Robert's software development methodology, and he has a lot to learn, but his commitment to the product is ineffable and, with me no longer available, I see no other way.
That said, my methodology and intentions with the product are explained in a few places, but I will restate them here in hopes that maybe Robert will listen and lead LateralGM to a solid future and not turn it into vaporware or such.
* First and foremost, LateralGM was created as a tool for dealing with the Game Maker file format. A vast majority of the users of LateralGM look to it as a way to open their GM files, especially their corrupted files. As such, this is the core of our product and it is never to stop functioning. Likewise, if LGM corrupts files, this is a critical failure.
* Secondly and finally, LateralGM has succeeded by learning from the mistakes of other products. This was the driving force behind LateralGM becoming a full-fledged IDE and not just a file-format tool - to deal with the shortcomings of Game Maker.
The reason it succeeded was because I saw where other products failed - such as G-Java and G-Creator. In my opinion, the reason they failed was because they focused on features and not core functionality. They had some fantastic and admirable features that looked very futuristic and fancy, some of which would be awesome to add to LateralGM, but without a solid foundation/core, it was just feature vaporware. As such, LateralGM learned 2 things. First, develop a solid core, and make sure it never breaks. Second, Features are second-class citizens, releases are first:
So declare the set of features you would like to see in a release, and then be ready to declare feature freeze - a time in development when you will introduce no new features into a release and will instead focus on fixing ALL the known bugs before that release. This is extremely difficult, because features are fun and leftover bugs are a pain, but it's also extremely necessary. Leaving bugs behind is what GameMaker does, not LateralGM. That said, some bugs aren't worth fixing, but they are rare.
A release is not "I've made a bunch of features guys, here, have a release so you can check them out." - that's what a prototype is for, and that's what Feature Freeze beta is for. You've made a bunch of neat features, congratulations, now fix all the leftover bugs and THEN you can declare a release.
Are there improvements to this method? Sure. But we don't have the manpower for it. From being in the workplace, I've learned a few things about software development methodologies and releases that more manpower affords you. We can't just truck through releases like they do - we need to buckle down and focus on what we said would be in the current release, or else officially bump it with good reason and update your roadmap.
I miss working on LateralGM and working with you guys. It was a lot of fun. I wish I still had the time to work on it. Maybe some day I will find some time - believe me, I've been thinking hard on ways to factor it in. If and when that happens, I can't say if I'll continue development in my own fork from the old code (where I left off) or if I pick up Robert's code and try to deal with our differences. But one thing's for sure - at this point in time, there's only 1 thing about LateralGM that I care about and that concerns me, and that's the list of open bugs. Those bugs need to be fixed, and if they're not and we keep releasing features, we are headed down the same path as G-Creator.
3
Proposals / Manual, the Button
« on: May 13, 2013, 04:05:51 pm »
I'm starting this topic to discuss viable solutions for the ever-looming non-functional Manual/Help button in LateralGM.
Obviously, the problem is that LateralGM doesn't ship with a manual, so there's not much to open. This could be a temporary thing - maybe some day we'll have a manual to ship with. It could be a permanent thing - the concept of a flat-file manual may be obsolete. Obviously, people still want a button to link to help, although it may not necessarily have to be the traditional Official LGM Manual.pdf/chm.
I think there's a general agreement that an official LGM manual.pdf/chm (offline file) will not be happening anytime soon. It would require a significant community effort to pull it off, and frankly, it's not high priority compared to some of the better uses a community effort could be put towards.
One very attractive option is to somehow link it to the Wiki. I really like this idea, but it does disadvantage our users who work offline. Realize that "working offline" isn't a dinosaur concept - when you take your laptop on a trip, it's not unlikely that you will have long times of being offline, and if you can't figure out the exact specifics of function X, you can't make any progress on a significant aspect of your game.
The other question about this is how will it be displayed? In the default browser? In our own little browser window? (Probably the prior - just launch the default web browser) A lot of the wiki follows a fairly standard convention, making it parsable so that we could potentially present it in whatever way we want (for reference, see EnigmaBot on the IRC, ask him to "!get show_message" or whatever function and he actually fetches and parses the description from the wiki)
Another attractive option is to allow the user to launch their own manual. Many users download a copy of the official GM manual and bring it with them. This comes in a few different flavors (html, cfm, pdf). Plus, some day there may be a similar option for an LGM manual. This is a nice modular idea, but difficult to implement because of all the different possible ways a manual can be represented. Do we just give the user an arbitrary textbox for "execute this command" that gets executed when they click the Manual button?
Of course, you're probably thinking "Couldn't we do both? Wiki for online users, launch for offline". Or some variation of that. Of course, then we'd need to flesh out the details for BOTH options, AND figure out how to decide which one to execute. To give you an idea, when we do the wiki option as the default, we launch firefox (or whatever browser) and it's out of our hands. Firefox launches, goes "oh, gee, I don't have internet. Here, have a nice NO INTERNET page" and that's the end of it - LateralGM doesn't know whether it worked or not. To fix this, we could do a network connection test - send a network ping or something to the wiki, and if that doesn't work, use the offline version.
So yeah, just a couple ideas I wanted to throw out there and see what you guys think. It'd be great if you could come up with some mock-up designs of any UI adjustments (e.g. Settings Panel) that would need to be done to make it a reality. Or maybe just a description of how exactly you'd want it to work.
Opening this to the Public Forum.
Obviously, the problem is that LateralGM doesn't ship with a manual, so there's not much to open. This could be a temporary thing - maybe some day we'll have a manual to ship with. It could be a permanent thing - the concept of a flat-file manual may be obsolete. Obviously, people still want a button to link to help, although it may not necessarily have to be the traditional Official LGM Manual.pdf/chm.
I think there's a general agreement that an official LGM manual.pdf/chm (offline file) will not be happening anytime soon. It would require a significant community effort to pull it off, and frankly, it's not high priority compared to some of the better uses a community effort could be put towards.
One very attractive option is to somehow link it to the Wiki. I really like this idea, but it does disadvantage our users who work offline. Realize that "working offline" isn't a dinosaur concept - when you take your laptop on a trip, it's not unlikely that you will have long times of being offline, and if you can't figure out the exact specifics of function X, you can't make any progress on a significant aspect of your game.
The other question about this is how will it be displayed? In the default browser? In our own little browser window? (Probably the prior - just launch the default web browser) A lot of the wiki follows a fairly standard convention, making it parsable so that we could potentially present it in whatever way we want (for reference, see EnigmaBot on the IRC, ask him to "!get show_message" or whatever function and he actually fetches and parses the description from the wiki)
Another attractive option is to allow the user to launch their own manual. Many users download a copy of the official GM manual and bring it with them. This comes in a few different flavors (html, cfm, pdf). Plus, some day there may be a similar option for an LGM manual. This is a nice modular idea, but difficult to implement because of all the different possible ways a manual can be represented. Do we just give the user an arbitrary textbox for "execute this command" that gets executed when they click the Manual button?
Of course, you're probably thinking "Couldn't we do both? Wiki for online users, launch for offline". Or some variation of that. Of course, then we'd need to flesh out the details for BOTH options, AND figure out how to decide which one to execute. To give you an idea, when we do the wiki option as the default, we launch firefox (or whatever browser) and it's out of our hands. Firefox launches, goes "oh, gee, I don't have internet. Here, have a nice NO INTERNET page" and that's the end of it - LateralGM doesn't know whether it worked or not. To fix this, we could do a network connection test - send a network ping or something to the wiki, and if that doesn't work, use the offline version.
So yeah, just a couple ideas I wanted to throw out there and see what you guys think. It'd be great if you could come up with some mock-up designs of any UI adjustments (e.g. Settings Panel) that would need to be done to make it a reality. Or maybe just a description of how exactly you'd want it to work.
Opening this to the Public Forum.
4
Issues Help Desk / MOVED: Splash functions
« on: May 08, 2013, 01:38:43 pm »
This topic has been moved to Function Peer Review.
https://enigma-dev.org/forums/index.php?topic=1234.0
https://enigma-dev.org/forums/index.php?topic=1234.0
6
Announcements / https (Browser security)
« on: May 03, 2013, 05:26:28 pm »
Basically, the announcement is that I've renewed our self-signed certificate and enabled SSL on this site, meaning that you can now use https for security while browsing and logging into the enigma website, forums, etc.
However, that's hardly in english, so I'm going to dumb it down into something you guys can actually understand and read, and in the process I'm going to show my ignorance of the technologies and probably explain something slightly incorrectly. Feel free to correct me, but I think I will get the gist of it, so...
Http is a great way to send and receive plain text, and maybe even some binary data like images and files. But it's not exactly secure. If you log in over http, the following happens:
You generate some packets with your username and password, and send them in the general direction of the server. This information is pretty much plain text. Along the route, it will go through your network, to your router. Then, your router sends it off to your ISP, and it bounces around the internet before it gets to the server ISP, the server's router, and then the server. At any point along that line, a number of computers can easily "sniff" those packets and see what's in them. Anybody on your network can (connected to your router). Your router can, but they're never set up to, because it's useless information for them to keep storing packets. Your ISP can. After that, it bounces around the internet, where not many people really care about it. Then it gets to our server's ISP, router, and server, where nobody's going to sniff it because we pay good money for that server, so it's going to be secure.
There is encryption, and there's a fairly standard way of doing that, and that's called HTTPS, courtesy of SSL. When you use https, your packets are encrypted at your computer. People can still sniff it, but they can't see what's inside. Eventually it gets to the server, and the server knows how to decrypt the packet because it more or less told your computer how to encrypt it (also, the server sends you back encrypted data, which only you can decrypt, so that's nice. Makes loading a page use a tiny bit more cpu, but hey, encryption ftw).
This is done through the magic of certificates and signing and keys and other stuff I won't bore you with. But the certificate is important to explain because it is "self signed". When the server is telling you how to encrypt it, you want to make sure you have the right server, and that our server isn't just someone pretending to be our server.
We provide a certificate, and your browser needs to trust it, because nobody else can provide our exact certificate, but they can provide their own certificate and pretend like its ours. To prevent this from happening, we can ask some other company will sign our certificate - preferably a company that is known to do good signing. Your browser has a list of a bunch of well-known ones already written in. Which means that if our certificate is signed by a company that your browser knows, it will automatically trust our certificate - there's virtually no chance that you're being phished.
However, we haven't asked some other company to sign our certificate (yet), because it costs money, and some of them (like digicert, probably the best-known one) cost hundreds of dollars. We're not paying that. So we've self-signed our certificate until we can find a cheap signer (we're looking into it and we'll make a decision very soon).
So, if you want to use our website/forums securely, you need to navigate your browser to https://enigma-dev.org at which point your browser should hopefully yell at you and say "This certificate is self-signed! Are you sure you trust this website?!" and you need to decide if you trust it's us, or if you think it's a phisher. Since we just set this up, it's unlikely that anybody phished it that quickly, so I'd say it's fairly safe to trust it. In firefox, this is done by "I understand the risks - Add an exception".
The alternative is to continue sending your password to the server as plaintext. If someone's going to phish, it'll be even easier to steal your password that way, rather than all the hastle of setting up a certificate and stuff like that. So frankly, there's no reason not to trust our certificate - even if it is phishing, because what's the difference?
At any rate, NOTE, if we get our certificate signed by someone else, we'll probably need to replace our certificate. Your browser will automatically recognize that one, so you won't need to take any steps, but the old certificate won't be valid. So you could just wait until then, rather than taking the extra steps to trust our self-signed (possibly temporary) certificate - and we'd understand. It's your choice. Our self-signed certificate is provided for those who want that extra layer of security, especially in their own network (even in the meantime).
I've mainly done this for myself, since I'm on a network with a bunch of people who are network programmers and use packet sniffers on a daily basis.
Anyways, there you go. Now you can use our website through https.
Please make sure you see the Lock icon next to the URL (in firefox at least. Or whatever it is on other browsers) before submitting your password.
Enjoy
-IsmAvatar
However, that's hardly in english, so I'm going to dumb it down into something you guys can actually understand and read, and in the process I'm going to show my ignorance of the technologies and probably explain something slightly incorrectly. Feel free to correct me, but I think I will get the gist of it, so...
Http is a great way to send and receive plain text, and maybe even some binary data like images and files. But it's not exactly secure. If you log in over http, the following happens:
You generate some packets with your username and password, and send them in the general direction of the server. This information is pretty much plain text. Along the route, it will go through your network, to your router. Then, your router sends it off to your ISP, and it bounces around the internet before it gets to the server ISP, the server's router, and then the server. At any point along that line, a number of computers can easily "sniff" those packets and see what's in them. Anybody on your network can (connected to your router). Your router can, but they're never set up to, because it's useless information for them to keep storing packets. Your ISP can. After that, it bounces around the internet, where not many people really care about it. Then it gets to our server's ISP, router, and server, where nobody's going to sniff it because we pay good money for that server, so it's going to be secure.
There is encryption, and there's a fairly standard way of doing that, and that's called HTTPS, courtesy of SSL. When you use https, your packets are encrypted at your computer. People can still sniff it, but they can't see what's inside. Eventually it gets to the server, and the server knows how to decrypt the packet because it more or less told your computer how to encrypt it (also, the server sends you back encrypted data, which only you can decrypt, so that's nice. Makes loading a page use a tiny bit more cpu, but hey, encryption ftw).
This is done through the magic of certificates and signing and keys and other stuff I won't bore you with. But the certificate is important to explain because it is "self signed". When the server is telling you how to encrypt it, you want to make sure you have the right server, and that our server isn't just someone pretending to be our server.
We provide a certificate, and your browser needs to trust it, because nobody else can provide our exact certificate, but they can provide their own certificate and pretend like its ours. To prevent this from happening, we can ask some other company will sign our certificate - preferably a company that is known to do good signing. Your browser has a list of a bunch of well-known ones already written in. Which means that if our certificate is signed by a company that your browser knows, it will automatically trust our certificate - there's virtually no chance that you're being phished.
However, we haven't asked some other company to sign our certificate (yet), because it costs money, and some of them (like digicert, probably the best-known one) cost hundreds of dollars. We're not paying that. So we've self-signed our certificate until we can find a cheap signer (we're looking into it and we'll make a decision very soon).
So, if you want to use our website/forums securely, you need to navigate your browser to https://enigma-dev.org at which point your browser should hopefully yell at you and say "This certificate is self-signed! Are you sure you trust this website?!" and you need to decide if you trust it's us, or if you think it's a phisher. Since we just set this up, it's unlikely that anybody phished it that quickly, so I'd say it's fairly safe to trust it. In firefox, this is done by "I understand the risks - Add an exception".
The alternative is to continue sending your password to the server as plaintext. If someone's going to phish, it'll be even easier to steal your password that way, rather than all the hastle of setting up a certificate and stuff like that. So frankly, there's no reason not to trust our certificate - even if it is phishing, because what's the difference?
At any rate, NOTE, if we get our certificate signed by someone else, we'll probably need to replace our certificate. Your browser will automatically recognize that one, so you won't need to take any steps, but the old certificate won't be valid. So you could just wait until then, rather than taking the extra steps to trust our self-signed (possibly temporary) certificate - and we'd understand. It's your choice. Our self-signed certificate is provided for those who want that extra layer of security, especially in their own network (even in the meantime).
I've mainly done this for myself, since I'm on a network with a bunch of people who are network programmers and use packet sniffers on a daily basis.
Anyways, there you go. Now you can use our website through https.
Please make sure you see the Lock icon next to the URL (in firefox at least. Or whatever it is on other browsers) before submitting your password.
Enjoy
-IsmAvatar
7
Announcements / Thanksgiving Holiday Updates
« on: November 25, 2012, 10:18:53 pm »
Most of you probably haven't noticed this yet, because most of you don't bother to use the Tracker since it was quite broken - but Josh and I have put a little elbow grease into a new bug tracker idea to replace the old Bugspray system that broke after the last SMF update. We're happy to present it to you as a little Thanksgiving present. You can view it by clicking the Tracker link up top, as usual.
The new tracker utilizes the Github Issues system, and all old tickets will hopefully be migrated soon as well.
But wait, does this mean you'll need a github account to report a bug? And why do we bother to emulate it here, rather than just having a redirect?
No, that's where it gets clever! We've hooked up your forum/enigma-dev accounts to this system, so as long as you are logged in here, you can post or comment on issues without needing a github account. Technically, our old friend EnigmaBot posts on your behalf, but we try to keep that as transparent as possible so it doesn't look like every issue/comment was posted by EnigmaBot! One little quirk of this system is that posted issues created through the bot will have a [u###] in the title. This is just to help EnigmaBot to link your enigma-dev account.
If you do have a Github account, you may click on the link to Github and post/comment that way, if you'd prefer, or you can use our system and let EnigmaBot post on your behalf. When viewing issues here, anything posted by a github user will have their username italicized, and will link to their github profile; enigma-dev users will appear non-italicized, and will link to their enigma-dev profile. In the future, we may invest in linking accounts — ie, your ENIGMA account will keep track of the name of your GitHub account if you can prove your ownership thereof. In the meantime, you'll just have to put up with some issues and comments being from GitHub while others are from the forums.
Josh writes:
On a separate note, I cleaned up the forums a bit. You'll find the avatars section in your profile offers a default set of avatars again. If you don't have an avatar set, I encourage you to pick one as it makes skimming the forum and identifying people easier. Do not be surprised if I start assigning octocat to people.
Now, on to parser progress.
The "basics" are "working." This includes correct lexing around comments, macros, etc, which means that anything that works in C++ works in ENIGMA. However, I want far more than that, and so I've begun a specification page for features of EDL beyond those of GML. You can find the page on the wiki here.
Moreover, I am going to be maintaining an information page regarding adding export languages to ENIGMA. That page can be found here.
If there is anything you would like to see in ENIGMA which is not covered on that Wiki page, post about it here. I am in the process of adding some of my bullet points from the proposals board.
Hope those of you who had Thanksgiving celebrations enjoyed yourselves.
The new tracker utilizes the Github Issues system, and all old tickets will hopefully be migrated soon as well.
But wait, does this mean you'll need a github account to report a bug? And why do we bother to emulate it here, rather than just having a redirect?
No, that's where it gets clever! We've hooked up your forum/enigma-dev accounts to this system, so as long as you are logged in here, you can post or comment on issues without needing a github account. Technically, our old friend EnigmaBot posts on your behalf, but we try to keep that as transparent as possible so it doesn't look like every issue/comment was posted by EnigmaBot! One little quirk of this system is that posted issues created through the bot will have a [u###] in the title. This is just to help EnigmaBot to link your enigma-dev account.
If you do have a Github account, you may click on the link to Github and post/comment that way, if you'd prefer, or you can use our system and let EnigmaBot post on your behalf. When viewing issues here, anything posted by a github user will have their username italicized, and will link to their github profile; enigma-dev users will appear non-italicized, and will link to their enigma-dev profile. In the future, we may invest in linking accounts — ie, your ENIGMA account will keep track of the name of your GitHub account if you can prove your ownership thereof. In the meantime, you'll just have to put up with some issues and comments being from GitHub while others are from the forums.
Josh writes:
On a separate note, I cleaned up the forums a bit. You'll find the avatars section in your profile offers a default set of avatars again. If you don't have an avatar set, I encourage you to pick one as it makes skimming the forum and identifying people easier. Do not be surprised if I start assigning octocat to people.
Now, on to parser progress.
The "basics" are "working." This includes correct lexing around comments, macros, etc, which means that anything that works in C++ works in ENIGMA. However, I want far more than that, and so I've begun a specification page for features of EDL beyond those of GML. You can find the page on the wiki here.
Moreover, I am going to be maintaining an information page regarding adding export languages to ENIGMA. That page can be found here.
If there is anything you would like to see in ENIGMA which is not covered on that Wiki page, post about it here. I am in the process of adding some of my bullet points from the proposals board.
Hope those of you who had Thanksgiving celebrations enjoyed yourselves.
8
Announcements / Email server fixed
« on: April 04, 2012, 08:34:32 pm »
Our resident webadmin, sirmxe, has finally gotten his personal matters together long enough to log into server, uninstall and then reinstall the exim mail service, and then log back out (hopefully).
That said, the mail server works now, and some of you may or may not have suddenly got a few emails from it that it still had on queue.
That said, the mail server works now, and some of you may or may not have suddenly got a few emails from it that it still had on queue.
10
Announcements / Main Progress [Stalled because we can't Git]
« on: February 11, 2012, 07:21:46 pm »
Just wanted to let you all in on a little update since we have moved to Git.
Rusky and RetroX have been infinitely helpful in getting us all up-to-speed in how-to-git, as well as getting the git in a semi-desirable state. That said, though, our git professionals seem to have been stretched to their capacities, so our developers are having a little bit of trouble figuring out how to install/build the latest ENIGMA rev from scratch. We're basically just waiting on our Git pros to update this page for us: http://enigma-dev.org/docs/Wiki/Install:Git ... Namely, lgm16b4.jar and enigma.jar were (intentionally) omitted from the repository, which makes it very difficult to run, because not just any version of those jars will work.
In the meantime, progress has been largely disjointed. For instance, Josh and I have been tweaking JoshEdit (which has its own git that we do know how to work). Josh also continues work on his new One Parser To Rule Them All. I've been catching up on other items on my Todo list, and will probably be working on some much needed upgrades to LGM's Room Editor soon. I've also figured out how to get EGit working in Eclipse, so I've been switching all my projects over that already use git. The IRC Bot has gotten several very nice updates to make understanding git revisions easier and such. There's been some slightly renewed interest in JEIE, so I might poke at that a little bit (at this point, the core is all there, it just needs a UI). TGMG has reported that 90% of the 64digits examples compile (with a blank function template for all currently unimplemented functions - primarily intended to test the compiler/parser), so that's always nice.
So that's why ENIGMA progress seems to have slowed to a crawl and no new builds are being made available - because we don't know how. But a lot of the side-branches are being filled in, so I expect that once we do figure out how, progress will explode. Until then, if you're looking for progress, look at the border projects, like JoshEdit and EnigmaBot and such.
For those of you trying to just do a standard install for using ENIGMA, you should be able to follow the normal Install page, which will give you one of the most recent builds we could get our hands on, with automatic updates disabled (which will probably be the norm from now on)
Rusky and RetroX have been infinitely helpful in getting us all up-to-speed in how-to-git, as well as getting the git in a semi-desirable state. That said, though, our git professionals seem to have been stretched to their capacities, so our developers are having a little bit of trouble figuring out how to install/build the latest ENIGMA rev from scratch. We're basically just waiting on our Git pros to update this page for us: http://enigma-dev.org/docs/Wiki/Install:Git ... Namely, lgm16b4.jar and enigma.jar were (intentionally) omitted from the repository, which makes it very difficult to run, because not just any version of those jars will work.
In the meantime, progress has been largely disjointed. For instance, Josh and I have been tweaking JoshEdit (which has its own git that we do know how to work). Josh also continues work on his new One Parser To Rule Them All. I've been catching up on other items on my Todo list, and will probably be working on some much needed upgrades to LGM's Room Editor soon. I've also figured out how to get EGit working in Eclipse, so I've been switching all my projects over that already use git. The IRC Bot has gotten several very nice updates to make understanding git revisions easier and such. There's been some slightly renewed interest in JEIE, so I might poke at that a little bit (at this point, the core is all there, it just needs a UI). TGMG has reported that 90% of the 64digits examples compile (with a blank function template for all currently unimplemented functions - primarily intended to test the compiler/parser), so that's always nice.
So that's why ENIGMA progress seems to have slowed to a crawl and no new builds are being made available - because we don't know how. But a lot of the side-branches are being filled in, so I expect that once we do figure out how, progress will explode. Until then, if you're looking for progress, look at the border projects, like JoshEdit and EnigmaBot and such.
For those of you trying to just do a standard install for using ENIGMA, you should be able to follow the normal Install page, which will give you one of the most recent builds we could get our hands on, with automatic updates disabled (which will probably be the norm from now on)
11
Proposals / Advanced Code-Based Object Editor
« on: November 30, 2011, 05:04:52 pm »
One of the popular proposed changes for LGM has been to get rid of DND for the more advanced users, and replace it with a quick-and-easy code editor. I'm a big fan of this myself, and while designing the Object Editor, I consciously added an extra area of code for dealing with said 'advanced mode' once a design was fleshed out.
The reason it hasn't happened yet is primarily just that - a design has yet to be fleshed out. Hence the purpose of this topic. I'd like to summon the community forth to discuss and design the new Advanced Object Editor.
So open up your MS/Kolour Paints, your GIMPs, and your InkScapes, and put forth some ideas. Include multiple images to demonstrate any non-obvious content that hides (e.g. if you are going to keep the DND panel, but just hide it until they press a button, indicate how it would look with and without the button pressed, and how that would interact with the code editor).
Currently, as a reminder to you guys of a somewhat hidden feature, if you double-click in the ActionsList (the third panel, between Events and DND Pane), a Piece of Code DND action will be added, and the editor for that is shown. This is nice, but it would be nicer if this could be entirely built in for advanced users.
My first thought was to just replace the DND pane and Actions List, but the Properties and Events panes (1st and 2nd panes, respectively) restrict horizontal space.
Idea 1: Combine the Properties and Events pane? (tabs maybe?)
Idea 2: Combine the properties and events into a Toolbar? This could be too cluttered.
Idea 3: Events could use a combo dropdown box, although that might be a step down from what it is now.
Idea 4: Have buttons to show/hide the properties/events. Properties could even potentially be made into an additional dialog box.
Just throwing some ideas out there to get you started.
The reason it hasn't happened yet is primarily just that - a design has yet to be fleshed out. Hence the purpose of this topic. I'd like to summon the community forth to discuss and design the new Advanced Object Editor.
So open up your MS/Kolour Paints, your GIMPs, and your InkScapes, and put forth some ideas. Include multiple images to demonstrate any non-obvious content that hides (e.g. if you are going to keep the DND panel, but just hide it until they press a button, indicate how it would look with and without the button pressed, and how that would interact with the code editor).
Currently, as a reminder to you guys of a somewhat hidden feature, if you double-click in the ActionsList (the third panel, between Events and DND Pane), a Piece of Code DND action will be added, and the editor for that is shown. This is nice, but it would be nicer if this could be entirely built in for advanced users.
My first thought was to just replace the DND pane and Actions List, but the Properties and Events panes (1st and 2nd panes, respectively) restrict horizontal space.
Idea 1: Combine the Properties and Events pane? (tabs maybe?)
Idea 2: Combine the properties and events into a Toolbar? This could be too cluttered.
Idea 3: Events could use a combo dropdown box, although that might be a step down from what it is now.
Idea 4: Have buttons to show/hide the properties/events. Properties could even potentially be made into an additional dialog box.
Just throwing some ideas out there to get you started.
12
Announcements / New LGM Backend Map/List
« on: November 20, 2011, 02:54:58 pm »
As of LateralGM r549 and ENIGMA r944 (and later), a new LGM backend system has been put in place. The prior system made heavy use of hard-coded lists for each resource type, which was not modular - meaning that it was causing difficulties for adding new resource types (like Overworlds and Definitions et al). The new system completely modularized this so that everything is put in a map, and may either be a non-instantiable resource (like Game Info) or instantiable (like Sprites). The former system didn't include non-instantiable resources in the map, so this is somewhat new territory.
That said, since this is somewhat new territory, we are proceeding with CAUTION. Although I have tested this pretty thoroughly, it's still hard to anticipate all the potential problems this could cause. Please back up your important games before using the new revisions. Please keep an eye open for any resources behaving strangely - including Game Settings, Game Information, and Enigma Settings. One hypothetical example of behavior that would be considered strange: "I press new game, and look at my Game Settings, and it's set this one way. I press new game again, and look at Game Settings, and now the settings are completely different." So keep an eye out for anything like that that might happen.
Also, this warning applies to the next several revisions as well:
1) Oftentimes revisions will update unrelated stuff, so any existing bugs will not necessarily be corrected.
2) Work is going to continue in this modularization in order to bring us new resource types (like Overworlds and Definitions) based on this new backend (which now allows us to do this). Some of the bugs I may have introduced may be hidden, but will be brought forward and made more visible with these new changes.
On the other hand, it's entirely possible (and likely) that this change was so smooth that it caused no new bugs or issues.
Either way (TL;DR version):
1) It's always good practice to back up your games, ESPECIALLY when using LateralGM/ENIGMA.
2) LateralGM is becoming more and more modular, which means that we're really starting to open the doors for new resource kinds.
3) If you notice a bug or strange behavior, as always, report it.
That said, since this is somewhat new territory, we are proceeding with CAUTION. Although I have tested this pretty thoroughly, it's still hard to anticipate all the potential problems this could cause. Please back up your important games before using the new revisions. Please keep an eye open for any resources behaving strangely - including Game Settings, Game Information, and Enigma Settings. One hypothetical example of behavior that would be considered strange: "I press new game, and look at my Game Settings, and it's set this one way. I press new game again, and look at Game Settings, and now the settings are completely different." So keep an eye out for anything like that that might happen.
Also, this warning applies to the next several revisions as well:
1) Oftentimes revisions will update unrelated stuff, so any existing bugs will not necessarily be corrected.
2) Work is going to continue in this modularization in order to bring us new resource types (like Overworlds and Definitions) based on this new backend (which now allows us to do this). Some of the bugs I may have introduced may be hidden, but will be brought forward and made more visible with these new changes.
On the other hand, it's entirely possible (and likely) that this change was so smooth that it caused no new bugs or issues.
Either way (TL;DR version):
1) It's always good practice to back up your games, ESPECIALLY when using LateralGM/ENIGMA.
2) LateralGM is becoming more and more modular, which means that we're really starting to open the doors for new resource kinds.
3) If you notice a bug or strange behavior, as always, report it.
13
Announcements / Back from a little downtime.
« on: September 17, 2011, 07:49:52 pm »
We experienced a little downtime recently where most pages displayed either an SMF Database error or the header displayed funky like it didn't load fully. This mostly only affected enigma-related or database-dependent pages, as other pages hosed on the server worked fine.
The prior problem was caused by a database corruption which may be related to the latter problem.
The latter problem was someone wrote the header in a non-html5 compliant way.
We've repaired the database and made the header compliant, so this issue should be fully resolved.
We apologize for any confusion caused during this time, but we're glad to announce that we're back up and going strong.
Special thanks to sirmxe for figuring this out and fixing it.
The prior problem was caused by a database corruption which may be related to the latter problem.
The latter problem was someone wrote the header in a non-html5 compliant way.
We've repaired the database and made the header compliant, so this issue should be fully resolved.
We apologize for any confusion caused during this time, but we're glad to announce that we're back up and going strong.
Special thanks to sirmxe for figuring this out and fixing it.
14
Ideas and Design / Replacing Plugin Workdir (and possibly LGM's)
« on: June 16, 2011, 08:09:02 pm »
This topic is mostly for RetroX, but other people are always welcome to contribute.
Currently Enigma's plugin to LateralGM, affectionally named The Plugin (written in Java by yours truly) has a WORKDIR variable which resolves to LGM's WORKDIR, which resolves to LGM's jar directory. The question is, why do we need the jar directory?
LGM uses WORKDIR for the following:
ENIGMA uses LGM's workdir for the following:
ENIGMA uses its workdir for the following:
Point is, the plugin does need to know ENIGMA's directory somehow, and in a cross-platform fashion. The simplest thing I could think up and implement at the time was "hmm, everything can just go in one program directory, so I'll just look at LGM.jar's directory". For some other directories that I can work with, consult Java.
Here is a listing of directories and other things that I can get using Java's "System.getProperty()" method, if it helps any, but please only use these directories in a cross-platform manner. For instance, do not assume that settings can be stored in `$user.home$/.lgm/` because that's a unix-only manner, and does not reflect for Windows (and probably doesn't for Mac either). Also, avoid trying to get the current Operating System as much as inhumanly possible - there will be a system that you did not account for.
Currently Enigma's plugin to LateralGM, affectionally named The Plugin (written in Java by yours truly) has a WORKDIR variable which resolves to LGM's WORKDIR, which resolves to LGM's jar directory. The question is, why do we need the jar directory?
LGM uses WORKDIR for the following:
- Finding Plugins
- Finding DND Libraries (lib/lgl files)
- For some reason, to populate gmlkeywords.properties from a file outside the jar, if one exists (probably for external override)
ENIGMA uses LGM's workdir for the following:
- To populate Enigma's WORKDIR (EnigmaRunner.WORKDIR = LGM.WORKDIR, more or less).
- To ensure that EnigmaUpdater knows that the program needs a restart when LGM is updated. (this could be replaced with a direct jar lookup)
- For some reason, it calls `make` to build enigma, and then locates enigma dll, in this directory. Not sure why. Will try to replace with ENIGMA's workdir now.
ENIGMA uses its workdir for the following:
- Not yet, but it should be used to call `make` to build enigma, and then locate the enigma dll, in this directory (see a couple lines up).
- Finding the "Compilers" directory
- Finding available API systems in "ENIGMAsystem/SHELL/"
- Provide a directory for ENIGMA's dll to run system commands in (via callback), e.g. Exec()
- Provide a directory for Subversion's Working Copy
- Finding "settings.ey" - a temporary thing that Josh and I set up for the EnigmaSettings pane.
- A directory to quicksave/quickload "definitions.h" (Can pretty much be scrapped, especially once the new file format is available)
Point is, the plugin does need to know ENIGMA's directory somehow, and in a cross-platform fashion. The simplest thing I could think up and implement at the time was "hmm, everything can just go in one program directory, so I'll just look at LGM.jar's directory". For some other directories that I can work with, consult Java.
Here is a listing of directories and other things that I can get using Java's "System.getProperty()" method, if it helps any, but please only use these directories in a cross-platform manner. For instance, do not assume that settings can be stored in `$user.home$/.lgm/` because that's a unix-only manner, and does not reflect for Windows (and probably doesn't for Mac either). Also, avoid trying to get the current Operating System as much as inhumanly possible - there will be a system that you did not account for.
| java.class.path | Java class path |
| java.library.path | List of paths to search when loading libraries |
| java.io.tmpdir | Default temp file path |
| java.compiler | Name of JIT compiler to use |
| java.ext.dirs | Path of extension directory or directories |
| file.separator | File separator ("/" on UNIX) (not necessary, because new File(directory, child) handles this for us) |
| path.separator | Path separator (":" on UNIX) |
| user.name | User's account name |
| user.home | User's home directory |
| user.dir | User's current working directory |