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

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

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

Quote
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'):
2

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

1878
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]
        <functionname>action_another_room</functionname>
        <codestring></codestring>
        <whoName>self</whoName>
        <relative>0</relative>
        <isnot>0</isnot>
        <arguments>
          <argument>
            <kind>11</kind>
            <room>title</room>
          </argument>
        </arguments>

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.
https://github.com/IsmAvatar/LateralGM/commit/22d6fd2bfc5fd5aff7a6fcaedf06916eb912c03a

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.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
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.
http://enigma-dev.org/docs/Wiki/Install:Windows

1879
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.
https://github.com/enigma-dev/enigma-dev/pull/632

And for future reference, this is the repository where I maintain the MD5 hashes.
https://github.com/enigma-dev/ExtraPackages

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.

1880
Developing ENIGMA / Re: Make Directory
« on: January 28, 2014, 12:58:13 AM »
See my comments on GitHub.
https://github.com/enigma-dev/enigma-dev/issues/631

Also please try manually patching the enigma.jar from the extra packages page.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages

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

1882
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.
http://enigma-dev.org/forums/index.php?topic=1736.0

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.
https://github.com/enigma-dev/enigma-dev/pull/628
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.
https://github.com/enigma-dev/lgmplugin/commit/d21f29c3867ccbb072cb9b24214edf9291d7ea29

This means you will all need to update the plugin next time you update from the repository.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
The portable ZIP has not been updated yet.

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

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

Name
: XInput
ID
: XInput
Description
: Input support including gamepads on Windows and Xbox 360.
Default-Windows
: true
Default
: false
Build-date
: 8/8/2013
Icon
: xinputlogo.png

Depends
: None
Dependencies
: None
Implement
: extension_xinput

This was the commit.
https://github.com/enigma-dev/lgmplugin/commit/56e826deda0d57200da5a79ccc4167f21cadf3c1

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.

1884
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:
    Layout
: Grid
    Columns
: 2
    -make-directory
:
        Type
: Textfield
        Label
: Make Directory
        Default-Windows
: "%PROGRAMDATA%/ENIGMA/"
        Default-Linux
: "%HOME%/ENIGMA/"
        Default-MacOSX
: "./ENIGMA"
        Default
: "./ENIGMA"
    -inherit-objects
:
        Type
: Checkbox
        Label
: Object Inheritance
        Default
: true

I implemented this to the plugin in the following commit.
https://github.com/enigma-dev/lgmplugin/commit/1f6071e1cf91c70a5c31a115cea60a397ef369f5
The settings were implemented to ENIGMA's repo in the following pull request.
https://github.com/enigma-dev/enigma-dev/pull/628

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.

1885
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.
https://github.com/IsmAvatar/LateralGM/commit/b63cf18a1efdf5607bafbe453a39feba607250fe
Please update LateralGM and the plugin and you'll be able to delete multiple resources at once properly.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages

I have also updated the Windows Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows

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.

1886
No problem, glad I could be of assistance.

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

1888
Graphics and Video / converticon.com issues
« on: January 26, 2014, 03:50:27 AM »
Thanks to sorlok this is resolved and is included in LGM 1.8.6
https://github.com/IsmAvatar/LateralGM/pull/146

You can now use converticon icons.

* IGNORE THIS POST IT HAS BEEN FIXED *

I just want to write this post up explaining why converticon.com 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.
http://enigma-dev.org/forums/index.php?topic=1700.msg16563#new
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.
http://en.wikipedia.org/wiki/ICO_%28file_format%29

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

The following is a screenshot of me viewing a 192x192 ICO file from converticon.com 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 converticon.com 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 converticon.com 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.
https://www.dropbox.com/s/4y9ygbm7mqai6fy/DeathStar512.ico

A good image editing software is Paint.NET it is freeware and has a lot of plugins.
http://www.getpaint.net/
There is also GIMP.
http://www.getgimp.com/
Both of these tools can be used to export ICO files properly.

1889
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.
https://www.dropbox.com/s/qc58z4kizehqy9h/512icon.ico

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.
http://converticon.com/
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.
Quote
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.

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