The GAM. 0.3 Available now.

[ElimiNator]

Can I inport or open my techs?

[modman]

Yes, even the initial release could do that.  All you do is load it into the editor.

[ElimiNator]

O ya, Is there a release for Linux?

If not I can still do it the bad old way with many bugs

[modman]

Dude, you seriously need to read the first post, OK ?  And if you still have questions, I have answers (but maybe not all of the right ones ).

[silnarm]

Reference copy is a little bit broken...

  On the new tech dialog, there is a drop down list of existing techs, the idea being to chose a tech to copy. This is ignored! The reference copy will be of the tech tree currently loaded. So to make a reference copy in 0.3, load the original tech you want to copy first.

@Eliminator
The graphical glitches when run on mono are certainly a nuisance, I believe the problem is in the winforms implementation.  I was not anticapating this, and it wont be an easy fix, but when I get this mostly complete I will spend some time trying to figure them out. I'm not sure how that will go, using Gtk# instead of winforms would have been the smart thing to do, but I'm not smart , and the gui code is obviously a very large proportion of the code for this, so I don't want to have to port the winforms to Gtk# if possible.

[modman]

I think a new feature for the GAM in late versions should be a preview of the particle projs and  splashes.  Because it is so annoying to have to load an entire Glest game up just to test out on your own units.

[assassin]

Why don't you use the g3d viewer?

[modman]

Because the G3d Viewer only shows the models, not the particle projs, unless I missed something...

[assassin]

Oh yeah. My bad. But it still would be cool is the g3d viewer was part of GAM.

[Omega]

ooh, fantastic work silnarm!

The reason I wanted to make DTDs was because I think that someone, somewhere, may find a use. Besides, they're all done. However, you are right aout certain parts not being expressed right. Of course, it only checks the syntax loosely, but works for both Glest and GAE. It will be with the archive in the new GG. The unit DTD is impossible since too many elements are used across parent elements. Must see if schemas can do better.

[jda]

Can and cannot (!) start GAM in Ubuntu 9.04 Jaunty.

Mono:
- libmono2.0-cil
- libmono-winforms2.0-cil

Running GlestAssetManager.exe:
- From Nautilus: does NOT start.

- From terminal:

  Method A (does NOT start):

Code: [Select]

$ wine GlestAssetManager.exe
install the Windows version of Mono to run .NET executables
  Method B:

Code: [Select]

chmod +x GlestAssetManager.exe
./GlestAssetManager.exeDialog-window "Please select your Glest exe ..." opens.
I point it to /usr/games/glest and get "The GAM could not start" with an "Ok" button which when clicked exits the program.
Terminal says:

Code: [Select]

$ ./GlestAssetManager.exe
Could not set X locale modifiers

Unhandled Exception: System.IO.FileNotFoundException: Could not find file "/home/user/GlestAM.xml".
File name: '/home/user/GlestAM.xml'
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000]
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000]
  at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
  at System.Xml.XmlUrlResolver.GetEntity (System.Uri absoluteUri, System.String role, System.Type ofObjectToReturn) [0x00000]
  at Mono.Xml2.XmlTextReader.GetStreamFromUrl (System.String url, System.String& absoluteUriString) [0x00000]
  at Mono.Xml2.XmlTextReader..ctor (System.String url, System.Xml.XmlNameTable nt) [0x00000]
  at System.Xml.XmlTextReader..ctor (System.String url, System.Xml.XmlNameTable nt) [0x00000]
  at System.Xml.XmlDocument.Load (System.String filename) [0x00000]
  at GlestAssetManager.GlestAMForm..ctor () [0x00000]Notes:
- GAM-0.3.zip contained ONLY the file "GlestAssetManager.exe".
- Before chossing the file, only the first line of the above output was printed out, the rest only comes out afterwards.

$HOME/.glest/glest is a symlink to /usr/lib/glest/glest so I wanted to try that one too. But the dialog-window with the file-chooser stops at/usr/lib and displays no contents to that folder (which do exist however, in large amount, could that amount be the reason for the freeze? It's very very long though...), it actually freezes completely and I have to kill it outside of its own controls.

If you need me to try and run a few more tests, just instruct me!

[silnarm]

Hi jda, I think the symlink should be ok, from the error it seems it couldn't create the xml settings file, or it's creating it ok, but then can't find it! It's looking for the settings in "/home/user/" which I suspect was '/home/$user' and that looks like it got truncated, rather than expanded.

Could you confirm which directory you have GlestAssetManager.exe in?

I usually run it from the terminal with,

Code: [Select]

mono GlestAssetManager.exe&

To run it from Nautilis, you would need to associate mono with .exe files, but you may not want to do that, especially if you use wine.

As to it stalling on /usr/lib I would say your guess is correct, mono-winforms is apparently not so 'complete' as I was lead to believe.

I've got some things to clean up and add, but have been a bit lazy recently I'll make sure to add some more error handling code, especially around the init and settings creation.

[Coldfusionstorm]

when you have worked hard and effectively, its natural to take a little break silnarm

[jda]

Hi jda, I think the symlink should be ok, from the error it seems it couldn't create the xml settings file, or it's creating it ok, but then can't find it! It's looking for the settings in "/home/user/" which I suspect was '/home/$user' and that looks like it got truncated, rather than expanded.

Could you confirm which directory you have GlestAssetManager.exe in?

The directory-name was correctly expanded. It was me who actually replaced my real username with "user" before posting here - yes, I'm that paranoid. 

The problem seems to be with creating the .xml settings file as there is no .xml file in that folder after the GlestAssetManager.exe has been run - nor during execution, before I choose the glest executable's location.
My $HOME permissions are set as 0755 (rwxr-xr-x). I actually tried chmoding it to 0777 (rwxrwxrwx) in case GlestAssetManager was somehow not running with my user's permissions (would be utterly weird but...) but still no file was created.

I usually run it from the terminal with,

Code: [Select]

mono GlestAssetManager.exe&

To run it from Nautilis, you would need to associate mono with .exe files, but you may not want to do that, especially if you use wine.

I didn't even know mono was independent of wine!
Running "mono GlestAssetManager.exe" runs perfectly, even without the file being set eXecutable.
And I can setup Nautilus to have wine as the default file-handler for .exe files and mono as an option, so that's good.

As to it stalling on /usr/lib I would say your guess is correct, mono-winforms is apparently not so 'complete' as I was lead to believe.

So you mean it's possible that mono-winforms stalls in displaying directory-contents with an huge amount of files in them?... That sucks!... 

I've got some things to clean up and add, but have been a bit lazy recently I'll make sure to add some more error handling code, especially around the init and settings creation.

As Coldfusionstorm said, you're definitely entitled to a break!
I myself am actually not really planning on modding anything in the near future, was just curious to see GAM work (and get a little bit more insight into the glest workings)...

[Hectate]

Hey silnarm, I haven't used GAM yet (too busy to mod) but I had an idea (which may be already on your roadmap) for the future.

Since this is the Glest Asset Manager, why not extend it to tilesets too? The basic functions (xml editing) is the same. Really it should just depend on the folder opened (faction or tileset or whatever).

Suggestions:
Tiling preview where the cellmap currently is. (probably would only show one image at a time, but it'd still help some)

frequency error checking (all tiles add up to 1.0, no tiles are at 0 frequency)

Tile frequency auto average/balance/equalize button, select checkbox or lock. (ie, lock 1 at .5 and then put checks on 2, 3, 4, 5 to balance the remaining unlocked percent among them. Put checks on 1 and 2 and then change 3 and the difference is applied to/taken from the checked tiles.)

color preview for day/night with gradient timeline (sliders?) for length adjustment

Open .g3d in viewer program/window (common function for faction creation too)

Open image to edit (ditto)

Support for custom resources and renaming.

Other things will come up too. hopefully it makes sense.

[Omega]

Hectate has a great idea! As well, the XML layout for the tileset isn't as complex as factions (one XML).

To open models in g3d viewer and to open images to edit, it could just 'open externally', in which case it could open them in whatever program is set for that extension (ie: HTML opens in firefox, JPG opens in paint.NET, g3d opens in G3D viewer, or whatever the user sets).

Showing the tiles (the surface textures) tiled wouldn't be too hard, since you already have a method of showing the images, you just need to show them in a  9x9 block!

Of course, no pressure, it would still be a bit of work, but it IS a good suggestion!

[silnarm]

Hey silnarm, I haven't used GAM yet (too busy to mod) but I had an idea (which may be already on your roadmap) for the future.

Since this is the Glest Asset Manager, why not extend it to tilesets too? The basic functions (xml editing) is the same. Really it should just depend on the folder opened (faction or tileset or whatever).

<GOOD Suggestions snipped>

Hi Hectate,  I do indeed intend to get to tilesets.  I was originally going to call it the Glest Mod Manager, but decided on a last minute name change for this very reason   I even have wild dreams of other things beyond tilesets and tech-trees... but never mind about that just yet.

I hadn't actually thought too much about the 'functionality' it might support, so thanks for coming up with some great ideas!

To open models in g3d viewer and to open images to edit, it could just 'open externally', in which case it could open them in whatever program is set for that extension (ie: HTML opens in firefox, JPG opens in paint.NET, g3d opens in G3D viewer, or whatever the user sets).

Launching the G3D viewer from within GAM might be possible, but with the file you want loaded? I don't think that's currently possible, because (iirc) the G3D doesn't accept command line parameters. Can you currently associate files with it and double-click to open them? If not, I guess that wouldn't be much of hack... but I'll need to build a project file for the G3D viewer some time first...

[Omega]

Well, I think that the G3D viewer works fine. For example, I set it as the default program to open g3d via the registry, and it works. However, the MAP MAKER does not...

[wciow]

Can you currently associate files with it and double-click to open them?

Nope, no dragndrop either. Currently the only way to open g3d files is the open command on the menu.

Btw, I think GAM should concentrate on stability before project creep. The current version on Vista is very unstable to the point of being almost unusable.   :'(

[Yggdrasil]

Well, I think that the G3D viewer works fine. For example, I set it as the default program to open g3d via the registry, and it works. However, the MAP MAKER does not...

g3dviewer works here too. Have a tiny patch for the map editor:
http://www1.inf.tu-dresden.de/~s1445051/r238-gae-editor_arguments.patch

This is for gae trunk. Tested on KDE/Linux.

[Omega]

Works for me fine. Just set it either old school or (if you're really advanced) use the Windows Registry:

HKEY_CLASSES_ROOT\extension_type\shell\open\command

where command's key is:
(Default)      REG_SZ        "C:/link/to/g3d_viewer.exe" "%1"

The extension type is the default value given in the extension key (ie: .g3d)

So HKEY_CLASSES_ROOT\.g3d should have
(Default)       REG_SZ        extension_type

Of course, extension_type should be the actual variable, such as 'g3d_file'

FOR EXPERIENCED USERS ONLY! You screw up, you could be screwed!

[silnarm]

Btw, I think GAM should concentrate on stability before project creep. The current version on Vista is very unstable to the point of being almost unusable.   :'(

Well, I'd ask for error messages, but I didn't make it easy to do that... I've made a fix for reference copy, I'll add some some catch all exception handling to write un-handled exceptions out to a txt file and release a 0.3.1, so you can get me some useful info, until then, it's a case of 'works fine for me' I'm afraid

Well, I think that the G3D viewer works fine. For example, I set it as the default program to open g3d via the registry, and it works. However, the MAP MAKER does not...

g3dviewer works here too. Have a tiny patch for the map editor:
http://www1.inf.tu-dresden.de/~s1445051/r238-gae-editor_arguments.patch

Ok, if it's taking command line parameters, we should be fine, I'll just have the user specify where to find the g3d_viewer binary.

Thanks for the map editor patch, haven't looked at it yet, but if it's just to take a file on the command line then it should be fine for windows... now I just need to figure out what branch I added the map editor vc proj to, and go back and figure out the rest of the link problems I had, hmmm

[Yggdrasil]

There is one in the refactor branch.

It works the same way as g3dviewer, so it should work.

[Omega]

What's wrong with the windows version? I haven't tested extensively, but I've seen no crashes.