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 - Goombert

Issues Help Desk / Re: There was an issue loading the project
« on: January 28, 2014, 06:08:20 AM »
Ugh, that is the result of not updating the action library, I'll fix it in the morning.

Issues Help Desk / Re: There was an issue loading the project
« on: January 28, 2014, 04:38:40 AM »
Looks like it failed to output the reason which was according to output_log.txt the following.

Creating room creation code scope and parsing
scr_init_title ( ) Second pass...
done. collecting variables...
Collecting some variables...
  Calls script `scr_init_title'
 done>scr_init_game ( ) ; scr_init_sound_system Syntax error in room creation code for room 1 (`main'):

When I looked at the code, only the first script was highlighted.
Code: (EDL) [Select]
And sure enough, the script called scr_init_sound_system doesn't exist under the Scripts folder.

Issues Help Desk / Re: There was an issue loading the project
« on: January 28, 2014, 03:27:37 AM »
Alright I just got done implementing some other plugin fixes, I'll investigate and fix this and it will be included in a major plugin/LGM update.

You were correct it was not adding a postponed reference for the room.
Code: (XML) [Select]

The reason was because Room's were missing from the Action Library reading for GMX. I have addressed the issue fully in the following commit.

I have tested this very well and it appears to have resolved the issue now and both of the actions in both objects load and save with the correct room. Please update both LateralGM and the plugin this time as this will include other bug fixes, you can obtain them from the following page.
When you have patched both jar files you need to run git fetch then git pull to have my new compiler callback implemented.

You can also simply update via re-downloading the Windows Portable ZIP.

Developing ENIGMA / Re: Make Directory
« on: January 28, 2014, 02:27:13 AM »
sorlok, give me a minute to make the pull request, and no I just changed the Linux default because I felt the . and lowercase was extraneous and didn't match Windows, but it doesn't matter I'll just commit the version that works, minor aesthetic really compared to the real importance of what we want to implement which is choosing where each project gets outputted too and eliminating the need for temp files, and handling like any other program eg. Visual Studio handles outputting exe's.

Edit: Here is the pull request.

And for future reference, this is the repository where I maintain the MD5 hashes.

Let me know if there are any other issues that stem from this change, there should not be any I have tested this very extensively.

Developing ENIGMA / Re: Make Directory
« on: January 28, 2014, 12:58:13 AM »
See my comments on GitHub.

Also please try manually patching the enigma.jar from the extra packages page.

Developing ENIGMA / Re: Make Directory
« on: January 27, 2014, 11:37:29 PM »
Yes you are it checks the md5 hashes, which I updated earlier.

Developing ENIGMA / Make Directory
« on: January 27, 2014, 06:24:12 PM »

I recently started making some changes to update YAML settings, you can read about that in the following topic.

Along the way I made several bugfixes to the plugin, and also made the ability to set the make directory per-project. This way each game can have a /build/ folder next to its project file, kind of like you see in Visual Studio or Qt Creator where you are asked where you want binaries outputted to. This however holds two problems, 1 the compiler should output its binaries to one single directory, and then link them from wherever your game/preprocessor is written to, the theoretical "build" folder. This does however mean we could do away with use of temporary files, and write the executable directly inside the build folder, and this would stop the creation of many many temporary files that need cleaned up.

This was the ENIGMA commit.
This was the plugin commit with other fixes, including escaping the ENIGMA Settings YAML since it holds the spec header and is subject to it.

This means you will all need to update the plugin next time you update from the repository.
The portable ZIP has not been updated yet.

Developing ENIGMA / Re: YAML Settings Update
« on: January 26, 2014, 10:57:28 PM »
Are you thinking of extensions perhaps? Actually, come to think of it, I should do it for extensions too, because some extensions like XInput and MCI could be defaulted on for Windows as well.

I have now implemented the ability for extensions to only be turned on by default for specific platforms.
Code: (YAML) [Select]

: XInput
: XInput
: Input support including gamepads on Windows and Xbox 360.
: true
: false
: 8/8/2013
: xinputlogo.png

: None
: None
: extension_xinput

This was the commit.

This now allows certain extensions that are required for things like the CD actions to be enabled by default correctly on each platform, allowing the platform specific implementation to remain without the end-user having to ever give a shit or think twice about it.

Developing ENIGMA / YAML Settings Update
« on: January 26, 2014, 10:14:13 PM »
While implementing a new ENIGMA setting I also added the ability to set platform specific defaults to the compiler settings frame. It works as Default-TargetOS where TargetOS is the name of the operating system returned by TargetHandler.GetOS(), an example follows for the Make Directory setting.

If the platform specific default is not found, the generic default is used.
Code: (YAML) [Select]
-Build Options:
: Grid
: 2
: Textfield
: Make Directory
: "./ENIGMA"
: "./ENIGMA"
: Checkbox
: Object Inheritance
: true

I implemented this to the plugin in the following commit.
The settings were implemented to ENIGMA's repo in the following pull request.

When this is merged to the repository I will immediately upload a new version of the Plugin and LateralGM as well as the Portable ZIP that you will need to download the next time you update from the repository.

Issues Help Desk / Re: There was an issue loading the project
« on: January 26, 2014, 07:08:09 PM »
Either that or the project could be corrupted in another way, I'll take a look again in the morning egofree, I am tired at the moment from diagnosing the ICO format issue.

The resources reappearing was an issue in LateralGM when I implemented the recursive deletion I did not have it recursively iterate children of group nodes.
Please update LateralGM and the plugin and you'll be able to delete multiple resources at once properly.

I have also updated the Windows Portable ZIP.

You are good at finding bugs egofree, but hey at least were getting them fixed. Now back to figuring out why it won't compile.

No problem, glad I could be of assistance.

On Windows Vista or later the generated C++ is in C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable

Graphics and Video / issues
« on: January 26, 2014, 03:50:27 AM »
Thanks to sorlok this is resolved and is included in LGM 1.8.6

You can now use converticon icons.


I just want to write this post up explaining why should not be used to convert large icons and images to and from the ICO format.

Upon discovering TKG's icon woes in the following topic, I discovered that the website does not adhere to the ICO file specification.
The ICO file specification states that the 7th byte will be the width of the image when the format is BMP, if the format is PNG the next part is simply the PNG header.

When I investigated I found out that every ICO file with a size layer larger than 192x192 exported from will be essentially broken.

The following is a screenshot of me viewing a 192x192 ICO file from which does match the ICO specification and the width is reported correctly.

The following is a screenshot of me viewing a 512x512 ICO file from which does NOT match the ICO specification and the width is reported as 0.

The following shows what a 256x256 ICO file using PNG looks like. The 7th byte is 0 but that is because that portion starts the PNG header. This header clearly does not match the corrupted version. So that rules out the possibility that LGM couldn't load as a result of the icon using the PNG format, because LGM loads this one fine.

I do not care if Windows and Studio can work with these corrupted ICO files or not. LateralGM will not support them, because they do not follow the specification and there is no way to tell exactly how to read them. Please do not use this site to convert large icon files, there are standards in computing for a reason.

For proof that LGM loads 512x512 ICO files when they are in the correct format, try to use the following icon and it should work fine.

A good image editing software is Paint.NET it is freeware and has a lot of plugins.
There is also GIMP.
Both of these tools can be used to export ICO files properly.

Issues Help Desk / Re: GMX Reader
« on: January 26, 2014, 02:55:09 AM »
To come back to this, I just found a 512x512 ICO file on the internet, which I loaded into a project of mine, and copied and pasted to a GMX project, and both of the projects loaded fine with LGM.

This was the ICO file that worked.

So I went to investigate further the program you used to convert the image, and sure enough it outputs corrupted Icon files when a size layer bigger than 192x192 was exported.
I went there and attempted to convert the following 512x512 PNG of the Death Star to a 512x512 ICO

Then LGM had an exception trying to use it on a project just like the one you are getting, so my advice to you is to find another image converter.

That image converter did not work on ICO files larger than 192x192.
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0
   at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
The reason is because every layer above 192x192 had a size of 0, which most likely means this image converter can't export ICO's at sizes larger than that, I went through and looked at the size of every layer, up to 192^2 was fine.
Something is clearly wrong with that converter, so please, use a different one.

General ENIGMA / Re: ANGLE Project
« on: January 25, 2014, 07:26:35 PM »
Actually, it is much more, this is a full graphics abstraction layer, which means we could remove all of our graphics systems and have all of it just GLES, but it can run in D3D9 and D3D11 mode. So this is exactly why Studio does not allow you to choose your graphics system. I have permission from Josh to implement it, but I am having a bit of trouble building it. This would also mean OpenGL framebuffers would work for people with shitty PC's like polygonz by use of the EGL_ANGLE_direct3d_surface extension.