Utility: Dom3 Unit Maker v1.07

[lch]

P.S.: Since I'm getting the Dom3 server monitor tool ready for Linux / Mono, too, and there is the same trouble as here: Probably the best way of getting the full path for a file is to use Path.Combine. Example code:

Code:

---

using System;

using System.IO;

public class Test {

 public static void Main(string[] args) {

  string s = Path.Combine(Environment.GetEnvironmentVariable("HOME"), "test");

  Console.WriteLine(s);

  Console.WriteLine(File.Exists(s));

  Console.WriteLine(Directory.Exists(s));

 }

}

---

I didn't have any experience with C# so far, but it sure is nice, I must admit.

[Gandalf Parker]

For some reason that doesnt work on my linux system.

Personally, since you have a config file asking for a path to a file, Id just add another option for the path seperator.

Or if I were to do a test I think it would be something like this.
can I see
./program.cfg
or do I have to look at
.\program.cfg

[lch]

Gandalf, have you installed Mono? What does "mono --version" tell you?

If you have installed it, then running "mono Dom3UnitMaker.exe" should work for you without problems, except for lots of "Unimplemented: Control::set_AutoSize(bool)" messages.

[Gandalf Parker]

I didnt have mono installed, I do now.
And then I realized that the problem I had was with one of Ballbarians programs.

Im mostly waiting for the map generator. I dont have much need for the unit builder personally.

[lch]

Gandalf Parker said:
And then I realized that the problem I had was with one of Ballbarians programs.

Which one? I see that he hands out the source code to his programs, too, so I could take a look at it. Even though he's programming in BASIC. Who the hell still programs in basic?? [img]/threads/images/Graemlins/Cold.gif[/img]

I had a quick look and I see that he already has some form of support for *nix in his code, although he missed a couple of occasions. I haven't programmed BASIC in, like, ever, but since it's little more than batch programming it shouldn't make any trouble. Just say what you need.

Im mostly waiting for the map generator. I dont have much need for the unit builder personally.

Well, as I wrote in the other thread it already works with Wine. You said that you don't want emulators on your server or something, but if you didn't know what Wine stands for: WINE Is Not an Emulator. It's an alternative implementation of the Windows API, you should rather compare it to Mono: open source implementations of native Windows DLLs. paradoxharbinger could probably even compile his Windows program for *nix via winelib without any changes to the source code, too. Although I'd encourage a rewrite under C# because it looks like a really nice programming language with lots of useful classes.

[Gandalf Parker]

lch said:

Which one? I see that he hands out the source code to his programs, too, so I could take a look at it. Even though he's programming in BASIC. Who the hell still programs in basic?? [img]/threads/images/Graemlins/Cold.gif[/img]

Heehee. You dont want to get me started on this. But a short answer is that I probably caused that. Most of my cgi's, linux scripts, windows batch files, and map utilities still get written in basic. Its an important part of my administration tools. Not nearly as dead as people think. (by the way, dominions was originally written on an Atari in Basic altho it is in C now).

I had a quick look and I see that he already has some form of support for *nix in his code, although he missed a couple of occasions. I haven't programmed BASIC in, like, ever, but since it's little more than batch programming it shouldn't make any trouble. Just say what you need.

Yeah thats what I think happened. Ive been meaning to write him about it. Its on my list. My long LONG list.

Well, as I wrote in the other thread it already works with Wine. You said that you don't want emulators on your server or something, but if you didn't know what Wine stands for: WINE Is Not an Emulator. It's an alternative implementation of the Windows API, you should rather compare it to Mono: open source implementations of native Windows DLLs. paradoxharbinger could probably even compile his Windows program for *nix via winelib without any changes to the source code, too. Although I'd encourage a rewrite under C# because it looks like a really nice programming language with lots of useful classes.

The mono thing convinced be because of the command line example you gave. I just run the command with mono in front of it. My impression of wine was that you ran wine, and then ran things in that environment. But it has been a long time since I looked at it so I might be foggy on it.

[lch]

Gandalf Parker said:
The mono thing convinced be because of the command line example you gave. I just run the command with mono in front of it. My impression of wine was that you ran wine, and then ran things in that environment. But it has been a long time since I looked at it so I might be foggy on it.

Nope, with Wine it's just the same: "wine something.exe". Then all calls to the Windows API get handled by Wine. Since the mapgen makes some calls to the VisualStudio C++ DLLs over fairly new interfaces, Wine has problems to load them correctly (it tells the program "nope, you don't have this"), but if you use the DLLs which I linked then that problem has been taken care of.

I do agree that it would be nice to get away from crutches like Wine and get more cross-platform code from the beginning, though, even though it works via Wine. But fortunately we already have a positive response to that.

[paradoxharbinger]

hmm... might be useful, but relative paths are plenty for what im doing

thanks for the tip on the path separator character

also, should have expanded weapon and armor lists soon