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.
16
General ENIGMA / Re: 3D Particle Effects
« on: July 26, 2013, 03:57:34 pm »
Hey Robert, you are very welcome to take a crack at it, I am going to be busy catching up with stuff that has been going on as well as writing new tests, fixing bugs and developing/maintaining the new integration testing system.
17
Works in Progress / Re: Raptor blasters
« on: July 26, 2013, 09:19:01 am »
Hi cheeseboy, sorry about the late answer. I have looked into it, and there were a number of bugs in the handling of assignment to hspeed and vspeed which has been fixed (I have also added a test for them, and fixed all the bugs found from that, so hspeed and vspeed should be fully correct from now on 
). Furthermore, you use move_bounce_all, which means the players also end up bouncing off of their booster flames when colliding with stuff 
. The difference in behaviour is because the Precise and BBox versions of move_bounce_all handles a bit differently when the object is colliding with stuff on both its current and previous position. Precise's version is also a bit more precise than BBox.
). Furthermore, you use move_bounce_all, which means the players also end up bouncing off of their booster flames when colliding with stuff . The difference in behaviour is because the Precise and BBox versions of move_bounce_all handles a bit differently when the object is colliding with stuff on both its current and previous position. Precise's version is also a bit more precise than BBox.
18
General ENIGMA / Automated integration and regression extension and library
« on: July 25, 2013, 07:49:28 am »
Hi everyone. I am happy to say that I have created an extension and library for doing automated integration and regression testing. The extension has been committed and is called IntegrationTesting, and the library has been pushed to a branch called integration_testing_develop: https://github.com/enigma-dev/enigma-dev/tree/integration_testing_develop. The test system has been designed such that tests can be run and output results by developers as well as automatically.
In regards to running it automatically, I think it would be a good idea if we also looked into using a Continuous Integration (CI) system. A CI system does a number of different things, but is basically about continuously building a project, running its tests, generating test reports, etc. automatically. For instance, you could make a CI system that builds a given project every time a commit is made to the master branch of the main repository, run all tests with the newest version, generate test reports, and report if there have been any regressions since the previous commit. This makes it really easy to track down when exactly a bug covered by a test was introduced.
There exists a number of existing CI systems. One open-source CI system which seems to be widely used is Jenkins, which is used by Apache, Mozilla and others. I have added an output format for the generated testreport accepted by Jenkins' default JUnit-plugin for parsing test results. It's a bit hacky, since the testing system I have implemented is not based on JUnit, but I believe it should work well enough. If we need another test report output, I can write one for that as well.
I have uploaded the test report and an output version generated from the current tests such that you can see a bit of what it looks like:
Example of the general test report: http://pastebin.com/2756rkG5
Example of a HTML output version: https://www.dropbox.com/s/ycqp8ck13na1e4g/testreport.html
The HTML-version is somewhat simple, but should give a good overview over things.
As for the testing system itself, I decided going with integration testing instead of unit testing. Unit testing is basically testing each small part independently, while integration testing is about testing all or parts of the whole integrated system at once (such as running a game). Given that it is easy to create and run games, and that most of the APIs do not change a lot over time, I decided to make a test the same as a game. In effect, this means that each added test is another game that we test for compiles, runs and obeys some properties (for instance, for a graphical shapes test, if you draw a filled red rectangle, then the color in the center of the rectangle is going to be red).
Since integration tests relies first and foremost on the interfaces and APIs and not on the specific implementation, and that most of our interfaces and APIs do not change a lot over time, this means that the majority of the tests we write now will not need any changes or maintenance in the future. It also means that most tests will be valid for different implementations of the same interface, meaning that if a test is written for the graphics system OpenGL1, it will also be valid for OpenGL3 and DirectX.
The current extension and library should be ready for use, though I would like to get your general approval and comments of the system first. This includes the current feature set, the dependencies, what features ought to be available, etc.
In regards to features, the best links to get an impression of them is the following:
https://github.com/enigma-dev/enigma-dev/blob/integration_testing_develop/integration_tests/README.md
https://github.com/enigma-dev/enigma-dev/blob/integration_testing_develop/integration_tests/format/test_file_format
https://github.com/enigma-dev/enigma-dev/blob/integration_testing_develop/ENIGMAsystem/SHELL/Universal_System/Extensions/IntegrationTesting/integration_testing.h
In regards to dependencies, the testing system currently depends on Python 3.3. The main reason for choosing Python is partially that we already use Python (install.py), and partially that it is a cross-platform and expressive scripting language. The reason for using version 3.3 is a couple of features, including a timeout functionality when running commands outside Python, such as when running a test. I am a bit in doubt whether it is a good idea to rely on Python 3.3 given that it is relatively new, but if relying on Python 3.3 is not a good idea, it shouldn't be too bothersome to rewrite the libraries to be compatible with an older version of Python.
In regards to the near future assuming no major changes to the testing system, I will look at adding desired features to the testing system, fixing bugs in the testing system, writing tests and fixing issues. I will also look at spending time on writing and updating documentation, including on the wiki.
A final note is that running the system now (using [snip]python3 integration_tests/run_and_record_tests.py[/snip] on Ubuntu 13.04) will not give very interesting results, since the plugin needs to be built and uploaded to DropBox (the test system requires the plugin to have some more features, which I have committed to the master branch).
In regards to running it automatically, I think it would be a good idea if we also looked into using a Continuous Integration (CI) system. A CI system does a number of different things, but is basically about continuously building a project, running its tests, generating test reports, etc. automatically. For instance, you could make a CI system that builds a given project every time a commit is made to the master branch of the main repository, run all tests with the newest version, generate test reports, and report if there have been any regressions since the previous commit. This makes it really easy to track down when exactly a bug covered by a test was introduced.
There exists a number of existing CI systems. One open-source CI system which seems to be widely used is Jenkins, which is used by Apache, Mozilla and others. I have added an output format for the generated testreport accepted by Jenkins' default JUnit-plugin for parsing test results. It's a bit hacky, since the testing system I have implemented is not based on JUnit, but I believe it should work well enough. If we need another test report output, I can write one for that as well.
I have uploaded the test report and an output version generated from the current tests such that you can see a bit of what it looks like:
Example of the general test report: http://pastebin.com/2756rkG5
Example of a HTML output version: https://www.dropbox.com/s/ycqp8ck13na1e4g/testreport.html
The HTML-version is somewhat simple, but should give a good overview over things.
As for the testing system itself, I decided going with integration testing instead of unit testing. Unit testing is basically testing each small part independently, while integration testing is about testing all or parts of the whole integrated system at once (such as running a game). Given that it is easy to create and run games, and that most of the APIs do not change a lot over time, I decided to make a test the same as a game. In effect, this means that each added test is another game that we test for compiles, runs and obeys some properties (for instance, for a graphical shapes test, if you draw a filled red rectangle, then the color in the center of the rectangle is going to be red).
Since integration tests relies first and foremost on the interfaces and APIs and not on the specific implementation, and that most of our interfaces and APIs do not change a lot over time, this means that the majority of the tests we write now will not need any changes or maintenance in the future. It also means that most tests will be valid for different implementations of the same interface, meaning that if a test is written for the graphics system OpenGL1, it will also be valid for OpenGL3 and DirectX.
The current extension and library should be ready for use, though I would like to get your general approval and comments of the system first. This includes the current feature set, the dependencies, what features ought to be available, etc.
In regards to features, the best links to get an impression of them is the following:
https://github.com/enigma-dev/enigma-dev/blob/integration_testing_develop/integration_tests/README.md
https://github.com/enigma-dev/enigma-dev/blob/integration_testing_develop/integration_tests/format/test_file_format
https://github.com/enigma-dev/enigma-dev/blob/integration_testing_develop/ENIGMAsystem/SHELL/Universal_System/Extensions/IntegrationTesting/integration_testing.h
In regards to dependencies, the testing system currently depends on Python 3.3. The main reason for choosing Python is partially that we already use Python (install.py), and partially that it is a cross-platform and expressive scripting language. The reason for using version 3.3 is a couple of features, including a timeout functionality when running commands outside Python, such as when running a test. I am a bit in doubt whether it is a good idea to rely on Python 3.3 given that it is relatively new, but if relying on Python 3.3 is not a good idea, it shouldn't be too bothersome to rewrite the libraries to be compatible with an older version of Python.
In regards to the near future assuming no major changes to the testing system, I will look at adding desired features to the testing system, fixing bugs in the testing system, writing tests and fixing issues. I will also look at spending time on writing and updating documentation, including on the wiki.
A final note is that running the system now (using [snip]python3 integration_tests/run_and_record_tests.py[/snip] on Ubuntu 13.04) will not give very interesting results, since the plugin needs to be built and uploaded to DropBox (the test system requires the plugin to have some more features, which I have committed to the master branch).
19
General ENIGMA / Re: License Exemptions
« on: June 28, 2013, 04:52:02 pm »
The issue is definitely not petty. While permissive licenses fits well with some software, in my opinion they do not fit a lot of software. And I believe that ENIGMA is one such case. If there was a lot of excellent FOSS game engines licensed under effectively permissive licenses with feature sets similar to ENIGMA, it wouldn't make a lot of difference if ENIGMA was licensed under a copyleft license or an effectively permissive license, since the theoretical AMGINE based off ENIGMA could just as well be based on one of those other engines. But, given that there aren't really any open-source engines that are close to ENIGMA's feature set, let alone one which is effectively permissively licensed, I think it will make a lot of difference whether ENIGMA's license is copyleft or effectively permissive. If ENIGMA gets an effectively permissive license and someone creates AMGINE, all the work the contributors do will effectively be free work for AMGINE, which could sell the modifications of the ENIGMA contributors, without having to contribute back their own changes and improvements. That would likely result in a considerable reduction in development of ENIGMA, which would widen the gap even further between ENIGMA and AMGINE. In the end, ENIGMA would die out, and its legacy would be yet another proprietary game engine, probably as a commercial competitor to GameMaker with a somewhat different feature set. And that would not serve the users of neither ENIGMA, AMGINE or GameMaker, nor the contributors to ENIGMA.
20
General ENIGMA / Re: Encapsulating EDL types and functions in their own namespace
« on: June 27, 2013, 07:07:10 am »
Yes.
21
General ENIGMA / Re: Encapsulating EDL types and functions in their own namespace
« on: June 26, 2013, 06:39:25 pm »
Hey polygone, sorry about the late response. With the latest commit I think the percentage is about 90% to 95%. In the latest commit, I have gone through all of the files in the Universal_System folder and moved the remaining parts to be moved. One part I didn't moved was instance_id, since that hasn't been fully implemented yet. I added a TODO to it instead, since moving it while fixing it should be easy. There are a couple of subsystems that I haven't moved, due to one reason or another. For instance, I haven't moved the functions in the OpenGL ES graphics system, and I don't think that is an issue; it will need to be fixed later on in any case, and it should be easy to move the functions there then. I suspect that there may be special cases or corner cases that I haven't handled yet, but since the majority of the functions have been moved and tested, and any errors will be encountered as compile-time errors, it should be easy to move them when they are encountered.
22
General ENIGMA / Re: License Exemptions
« on: June 25, 2013, 02:59:43 pm »
So, to summarize, if I understand things correctly there are two main issues that we need to handle:
While I would prefer a solution that does not rely on having an organization to control which interfaces and the like are endorsed/approved or not, I think Josh is right that the clause is necessary. I have thought about potential alternative clauses that would avoid such an organization, for instance by only letting code in EDL be excepted; but then you have the issue of defining EDL, and if you want to make changes or additions to EDL, then you would need an organization to control that, which brings us back to where we started. And if we have to have an organization, I think Josh's proposed exception is a good starting point (as Josh says, we will need to define the concepts more precisely). I do think it would be a good idea to ask others about this, given that none of us are lawyers. There are some websites that deal with open-source games and game development, and I believe there would be people there that would be happy to advise us about this: http://opengameart.org/ and http://freegamer.blogspot.com. Unless we figure something else out, I will post there at some point and ask if anyone has some advice for us.
In regards to who would control the organization, I wouldn't mind it if Josh, IsmAvatar and Gary decides which interface and fork is endorsed/approved. However, if we later decide that it would be a good idea to create a proper organization, we might be forced to change the exception to accommodate that change in who endorses/approves the interface, and that would probably entail asking everyone who have contributed to the engine code to approve a new license. That could become problematic, especially if people have disappeared or otherwise are hard to get in contact with, or do not wish to approve of a new exception. I therefore think that it would be a good idea if we either create a proper organization now, or we change the license in such a way that we can create a proper organization later on without having to ask everyone who have contributed to the engine code.
- The user should always have the choice of whether a given game they create is released as open-source or closed-source.
- Any extensions or modifications to the engine should be open-source.
While I would prefer a solution that does not rely on having an organization to control which interfaces and the like are endorsed/approved or not, I think Josh is right that the clause is necessary. I have thought about potential alternative clauses that would avoid such an organization, for instance by only letting code in EDL be excepted; but then you have the issue of defining EDL, and if you want to make changes or additions to EDL, then you would need an organization to control that, which brings us back to where we started. And if we have to have an organization, I think Josh's proposed exception is a good starting point (as Josh says, we will need to define the concepts more precisely). I do think it would be a good idea to ask others about this, given that none of us are lawyers. There are some websites that deal with open-source games and game development, and I believe there would be people there that would be happy to advise us about this: http://opengameart.org/ and http://freegamer.blogspot.com. Unless we figure something else out, I will post there at some point and ask if anyone has some advice for us.
In regards to who would control the organization, I wouldn't mind it if Josh, IsmAvatar and Gary decides which interface and fork is endorsed/approved. However, if we later decide that it would be a good idea to create a proper organization, we might be forced to change the exception to accommodate that change in who endorses/approves the interface, and that would probably entail asking everyone who have contributed to the engine code to approve a new license. That could become problematic, especially if people have disappeared or otherwise are hard to get in contact with, or do not wish to approve of a new exception. I therefore think that it would be a good idea if we either create a proper organization now, or we change the license in such a way that we can create a proper organization later on without having to ask everyone who have contributed to the engine code.
23
General ENIGMA / Re: The last of the engine compile warnings
« on: June 17, 2013, 02:54:59 pm »
Hey Josh, I fixed some minor regressions in the particle extension, mostly due to the peculiar handling of regions for particles in GM, as well as a fix for the error regarding collision types and data you found.
In regards to the particles:
For destructor, deflector and changer regions, I tested it, and a region of (300,300; 300,300) will not catch anything, while a region of (299,300; 299,300) or (300,301; 300,301) does catch something.
For the emitter, you can get differently sloped line regions by giving wrong values for xmin and xmax, which has also been tested.
I have added comments to those sections due to their peculiar behaviour.
Apart from that, there were only minor errors. I have tested the particles on some different testing games I made during development of the particles extension, and it all looks good.
In regards to the data structure functions:
I had a file containing a few tests for each data structure, and they all passed.
In regards to the mask in the collision system:
The reason it works is that "pixels" is passed in instead of the "collision_data", and for the only collision type that is currently implemented that uses input collision data, namely ct_precise, that is exactly the right collision data to pass in. It would have caused issues when implementing other collision types. I have just committed a fix for it.
In regards to the particles:
For destructor, deflector and changer regions, I tested it, and a region of (300,300; 300,300) will not catch anything, while a region of (299,300; 299,300) or (300,301; 300,301) does catch something.
For the emitter, you can get differently sloped line regions by giving wrong values for xmin and xmax, which has also been tested.
I have added comments to those sections due to their peculiar behaviour.
Apart from that, there were only minor errors. I have tested the particles on some different testing games I made during development of the particles extension, and it all looks good.
In regards to the data structure functions:
I had a file containing a few tests for each data structure, and they all passed.
In regards to the mask in the collision system:
The reason it works is that "pixels" is passed in instead of the "collision_data", and for the only collision type that is currently implemented that uses input collision data, namely ct_precise, that is exactly the right collision data to pass in. It would have caused issues when implementing other collision types. I have just committed a fix for it.
24
Works in Progress / Re: Raptor blasters
« on: June 17, 2013, 10:44:27 am »
Nice WIP, I especially like the sprites, animations and effects. As you say, it is far from done, such as the lack of actual hotness of the lava :- ). I also like that the AI uses the same controls as the player,
In regards to staying inside the view, I think the AI mostly have issues with staying inside the view when it has high hspeed, such as when it is chasing after a power-up. I think that if you let the limit of when it begins going the other way depend on its hspeed (similar to what you do with vspeed and k_jetpack in line 19), possibly multiplied by a constant factor to make it count more, it would be better at staying inside the view even when it has high hspeed.
About avoiding the lava instead of chasing the power-up, I think you are already doing the right thing by letting it depend on vspeed. You may need to multiply that vspeed with a greater constant factor if it sometimes dives into the laving when chasing power-ups. Determining and calibrating a good constant factor may require some testing.
About the bomb avoidance, I think it may be interesting to let it depend on hspeed as well, and also let it differentiate more about which direction to go in depending on which side the player is of the bomb; for instance, if both the player and the bomb is on the left side, and the bomb is to the left of the player, the player should go right, not left to avoid it.
There is also missing an instance_exists before the accessing of the bomb instance, since the bomb instance may not exist.
About the game in general, it would be very nice to have some information about the controls, it took me some searching to find out that 'z' is used for shooting. I also wonder if it would be a good idea to implement some sort of limits or indestructible walls at the top and the side, just to avoid the player and AI from going out there.
In regards to staying inside the view, I think the AI mostly have issues with staying inside the view when it has high hspeed, such as when it is chasing after a power-up. I think that if you let the limit of when it begins going the other way depend on its hspeed (similar to what you do with vspeed and k_jetpack in line 19), possibly multiplied by a constant factor to make it count more, it would be better at staying inside the view even when it has high hspeed.
About avoiding the lava instead of chasing the power-up, I think you are already doing the right thing by letting it depend on vspeed. You may need to multiply that vspeed with a greater constant factor if it sometimes dives into the laving when chasing power-ups. Determining and calibrating a good constant factor may require some testing.
About the bomb avoidance, I think it may be interesting to let it depend on hspeed as well, and also let it differentiate more about which direction to go in depending on which side the player is of the bomb; for instance, if both the player and the bomb is on the left side, and the bomb is to the left of the player, the player should go right, not left to avoid it.
There is also missing an instance_exists before the accessing of the bomb instance, since the bomb instance may not exist.
About the game in general, it would be very nice to have some information about the controls, it took me some searching to find out that 'z' is used for shooting. I also wonder if it would be a good idea to implement some sort of limits or indestructible walls at the top and the side, just to avoid the player and AI from going out there.
25
General ENIGMA / Re: hey plions
« on: June 15, 2013, 02:34:36 pm »
In regards to the issue with the tiles and copying of structs, most of the time the direct assignment is actually correct, since polygone uses it to either just read from the tile, or copy it in again, either after modification of the tile or after the tile in the data structure being deleted.
That said, there are a couple of functions where it indeed is not used correctly, such as [snip]bool tile_layer_hide(int layer_depth);[/snip], [snip]bool tile_layer_show(int layer_depth);[/snip] and [snip]bool tile_layer_shift(int layer_depth, int x, int y);[/snip]. In those cases, the tile struct is copied, the copy is modified, and nothing more is done.
I also think I found a somewhat unrelated bug, namely in [snip]tile_layer_delete_at[/snip]. The issue is that a vector is iterated through (in this case using indexes) while it is being modified (namely, elements are removed from it), and I think in this case it results in that sometimes, elements that should have been removed are not removed. Modifying a data structure while iterating through it can easily be gotten wrong, so great care should always be taken when doing so - or, alternatively, simply avoid iterating through it while modifying it, for instance by creating a temporary vector or the like (though that may not always be performant).
polygone, in regards to point number 2 that Josh points out, the issue is that when you use the syntax:
tile is not a pointer to a struct, but a direct struct. Therefore, the first line copies the original structure. In the second line, the copy's alpha field is assigned 1, and since the copy is not used after that, it basically has no effect. What you want to do instead is to either use a pointer instead, like so:
or use a reference variable, which in this case basically the same as using a pointer but with more convenient syntax.
. Both of the above solutions ensures that you are modifying the original instead of a copy that is not used later.
That said, there are a couple of functions where it indeed is not used correctly, such as [snip]bool tile_layer_hide(int layer_depth);[/snip], [snip]bool tile_layer_show(int layer_depth);[/snip] and [snip]bool tile_layer_shift(int layer_depth, int x, int y);[/snip]. In those cases, the tile struct is copied, the copy is modified, and nothing more is done.
I also think I found a somewhat unrelated bug, namely in [snip]tile_layer_delete_at[/snip]. The issue is that a vector is iterated through (in this case using indexes) while it is being modified (namely, elements are removed from it), and I think in this case it results in that sometimes, elements that should have been removed are not removed. Modifying a data structure while iterating through it can easily be gotten wrong, so great care should always be taken when doing so - or, alternatively, simply avoid iterating through it while modifying it, for instance by creating a temporary vector or the like (though that may not always be performant).
polygone, in regards to point number 2 that Josh points out, the issue is that when you use the syntax:
Code: [Select]
enigma::tile t = dit->second.tiles[i];
t.alpha = 1;
tile is not a pointer to a struct, but a direct struct. Therefore, the first line copies the original structure. In the second line, the copy's alpha field is assigned 1, and since the copy is not used after that, it basically has no effect. What you want to do instead is to either use a pointer instead, like so:
Code: [Select]
enigma::tile* t = &(dit->second.tiles[i]);
t->alpha = 1;
or use a reference variable, which in this case basically the same as using a pointer but with more convenient syntax.
Code: [Select]
enigma::tile& t = dit->second.tiles[i];
t.alpha = 1;
. Both of the above solutions ensures that you are modifying the original instead of a copy that is not used later.
26
General ENIGMA / Re: Start moving in one the selected directions
« on: June 15, 2013, 01:32:48 pm »
It doesn't work for me either. It does not generate any exceptions when trying to drag it, and the action does not show up on the Actions list either, nor show a window for modifying it. When right-clicking, the action does show up on the Actions list, but it does not generate a window either, and it generates an exception. It also generates the same exception when double-clicking the action in the Actions list, and it does not show a window to modify it. The exception: http://pastebin.com/iXv7Sj9c
I am running on Linux, and the version of LateralGM should be relatively recent.
I am running on Linux, and the version of LateralGM should be relatively recent.
27
Issues Help Desk / Re: Move bounce is garbage! How to bounce without getting stuck?
« on: June 13, 2013, 10:54:20 am »
The default movement system and collision handling in GM and ENIGMA can be problematic when having multiple moving objects that should never overlap. The reason is that all objects are moved after the step event, and then after they have all been moved, collision handling is done. Since movement and collision checking/handling is interleaved between objects, you may get problematic results where objects end up on top of each other.
One way to bypass these issues is to do the movement and collision checking/handling manually for the moving objects that should never overlap. For instance, you could have your own variables for hspeed, vspeed and gravity (they aren't difficult to simulate, though they may be a bit bothersome), and then in the step event, move the object, check for collisions, and if there are any, simple move back to a position you know is clear (for instance, the previous position). Because you for each object always ensure that they move and check separately, and that they always end up in a clear position, they will never get stuck on each other. You also know that the position at xprevious and yprevious is clear, because the position starts out clear, and there aren't any objects that move between you moving that object and checking for and handling collisions for that object.
The above technique is seen in functions like mp_potential_step, which moves and checks for collisions at the same time.
I wonder if it would be a nice feature to allow the step event and the collision event to be handled together for each object as an option. That wouldn't make much difference in most cases, since interleaving movement and collision checking/handling is not an issue in most games, but in cases where you have multiple moving objects that should not overlap, it could be a lot more convenient than having to simulate hspeed and vspeed and checking for collisions manually.
One way to bypass these issues is to do the movement and collision checking/handling manually for the moving objects that should never overlap. For instance, you could have your own variables for hspeed, vspeed and gravity (they aren't difficult to simulate, though they may be a bit bothersome), and then in the step event, move the object, check for collisions, and if there are any, simple move back to a position you know is clear (for instance, the previous position). Because you for each object always ensure that they move and check separately, and that they always end up in a clear position, they will never get stuck on each other. You also know that the position at xprevious and yprevious is clear, because the position starts out clear, and there aren't any objects that move between you moving that object and checking for and handling collisions for that object.
The above technique is seen in functions like mp_potential_step, which moves and checks for collisions at the same time.
I wonder if it would be a nice feature to allow the step event and the collision event to be handled together for each object as an option. That wouldn't make much difference in most cases, since interleaving movement and collision checking/handling is not an issue in most games, but in cases where you have multiple moving objects that should not overlap, it could be a lot more convenient than having to simulate hspeed and vspeed and checking for collisions manually.
28
Issues Help Desk / Re: LGM on Ubuntu
« on: June 13, 2013, 08:41:44 am »
It's a bit of a long-shot, but based on this post: http://osdir.com/ml/bsd-port-dev/2011-09/msg00024.html, running LateralGM with [snip]java -Djava.awt.headless= -jar lateralgm.jar[/snip] might work. Do you know if you only get the exception when trying to get LGM to work, or does it happen with other Java GUI software as well?
29
General ENIGMA / Re: Proposal for guidelines on changes to the master branch of enigma-dev/enigma-dev
« on: June 10, 2013, 02:49:59 pm »
Hey Robert, I think you have some good suggestions. I have added a bit to the wiki in regards to the exact steps to replicate on the page about bug reporting, and I have made a new page on working with issues in GitHub. About reviewing changes, that part is actually already in the guidelines on changing.
30
General ENIGMA / Re: Proposal for guidelines on changes to the master branch of enigma-dev/enigma-dev
« on: June 08, 2013, 08:34:22 am »
I have written the guidelines and the policy into the wiki under the page IsmAvatar linked.