The following are not errors:
* SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
This is not an error. It is a warning thrown by Enigma.jar, warning you that it's not able to update itself if you don't have SvnKit. Of course, Enigma doesn't need to update itself.
* Unable to load plugin: SvnKit.jar: null: Missing plugin entry point (LGM-Plugin)
* Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)
These are not errors. They are warnings thrown by LGM indicating that it can't load those files as LGM Plugins -- because they *aren't* LGM Plugins! Basically these are just reminders to the devs that we shouldn't just throw every darned file we need access to in the Plugins folder >_<
A few other notes
LateralGM branched between the Trunk and a branch called Versioning. This branch allowed me to develop better GM7 and GM8 support, which is necessarily unstable since it's incomplete (hence the 'branch' status). This allows stable development and more finalizations to be done on the trunk to allow it to finally become LGM1.6 release, while development continues for the Versioning branch (Which is not a necessary part of the 1.6 release).
Due to Enigma having very high demands on experimental and progressive features, I was forced to take Enigma off of the Trunk and into the Versioning . branch (See Versioning Disclaimer). As such, there may be some bugs, especially pertaining to GM7 or GM8 files. Do feel free to report any bugs you come across either here or on the LGM forum, but do realize that it may just be something I'm still working on.
Due to a change in the support of the file format, there have also been some important changes to the information that I eventually pass off to Enigma (the structure of the information doesn't change. Think of it like a captcha - you read numbers in an image, and then type them in the text box. Now imagine that the captcha uses a different, fancier technique, but still displays the same numbers, so you still type the same numbers in the text box. LGM is the captcha. The structure passed into the DLL is the textbox). This new information may cause some incompatibilities (like it may be harder to read the captcha).
Versioning Disclaimer: Notice, I'm not saying I switched to the Versioning branch because that's where I can just dump all my experimental and broken features. The features I implement are very well thought out, and implemented fully, not broken. However, they are progressive in the nature that they change the way LGM works internally, and in very progressive ways. Before making such changes, I always think them out as thoroughly as possible and think of what it could possibly break - as well as using some nifty Java/Eclipse tools to look up references to the code to see what all could break - and then I test that to ensure that it has not broken. So again, these features are not "experimental" or subject to breaking LGM - I'm not running with scissors. They are just progressive because they change LGM in ways that I am not yet ready to change the Trunk. Think of the trunk as a conservative, if you will. It just wants to work and get things done, even if it means ad-hoccing stuff. But it'll keep trucking along in its old ways until either it gets to release, or it becomes overcome by the progressives (e.g. I merge the branch back in)
@freezway: I don't have access to a 64 bit system, and I don't know if Josh does either. If you could, see if you can't isolate the cause to a small change - like if adding an object causes the seg fault.
I would have liked to have had a session where, instead of saying "omg, something works, now let's run with it and see if we can compile games", we could have instead done a full print out of as much information as possible from a game obtained through the dll, just for testing. Then we'd try out passing in different variations of resources - like just one room, and then multiple rooms, and then just one object, and then a room and an object - etc. As it stands now, it's very difficult to debug a seg fault or a crash, because nothing is isolated. We're just running with it and saying "zomg, something failed somewhere, but we did 200 things, so we don't know where."
* SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
This is not an error. It is a warning thrown by Enigma.jar, warning you that it's not able to update itself if you don't have SvnKit. Of course, Enigma doesn't need to update itself.
* Unable to load plugin: SvnKit.jar: null: Missing plugin entry point (LGM-Plugin)
* Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)
These are not errors. They are warnings thrown by LGM indicating that it can't load those files as LGM Plugins -- because they *aren't* LGM Plugins! Basically these are just reminders to the devs that we shouldn't just throw every darned file we need access to in the Plugins folder >_<
A few other notes
LateralGM branched between the Trunk and a branch called Versioning. This branch allowed me to develop better GM7 and GM8 support, which is necessarily unstable since it's incomplete (hence the 'branch' status). This allows stable development and more finalizations to be done on the trunk to allow it to finally become LGM1.6 release, while development continues for the Versioning branch (Which is not a necessary part of the 1.6 release).
Due to Enigma having very high demands on experimental and progressive features, I was forced to take Enigma off of the Trunk and into the Versioning . branch (See Versioning Disclaimer). As such, there may be some bugs, especially pertaining to GM7 or GM8 files. Do feel free to report any bugs you come across either here or on the LGM forum, but do realize that it may just be something I'm still working on.
Due to a change in the support of the file format, there have also been some important changes to the information that I eventually pass off to Enigma (the structure of the information doesn't change. Think of it like a captcha - you read numbers in an image, and then type them in the text box. Now imagine that the captcha uses a different, fancier technique, but still displays the same numbers, so you still type the same numbers in the text box. LGM is the captcha. The structure passed into the DLL is the textbox). This new information may cause some incompatibilities (like it may be harder to read the captcha).
Versioning Disclaimer: Notice, I'm not saying I switched to the Versioning branch because that's where I can just dump all my experimental and broken features. The features I implement are very well thought out, and implemented fully, not broken. However, they are progressive in the nature that they change the way LGM works internally, and in very progressive ways. Before making such changes, I always think them out as thoroughly as possible and think of what it could possibly break - as well as using some nifty Java/Eclipse tools to look up references to the code to see what all could break - and then I test that to ensure that it has not broken. So again, these features are not "experimental" or subject to breaking LGM - I'm not running with scissors. They are just progressive because they change LGM in ways that I am not yet ready to change the Trunk. Think of the trunk as a conservative, if you will. It just wants to work and get things done, even if it means ad-hoccing stuff. But it'll keep trucking along in its old ways until either it gets to release, or it becomes overcome by the progressives (e.g. I merge the branch back in)
@freezway: I don't have access to a 64 bit system, and I don't know if Josh does either. If you could, see if you can't isolate the cause to a small change - like if adding an object causes the seg fault.
I would have liked to have had a session where, instead of saying "omg, something works, now let's run with it and see if we can compile games", we could have instead done a full print out of as much information as possible from a game obtained through the dll, just for testing. Then we'd try out passing in different variations of resources - like just one room, and then multiple rooms, and then just one object, and then a room and an object - etc. As it stands now, it's very difficult to debug a seg fault or a crash, because nothing is isolated. We're just running with it and saying "zomg, something failed somewhere, but we did 200 things, so we don't know where."