A Map Editor

[Raem_Lylar]

deleted

[BlueMaxima]

Here is version 3 of flaManual.

I added a page on the Map Texturer, added extra controls to their respective sections, and fixed up an error or two.

flaManual.pdf

Reuploaded - fixed another error :/

(1.19 MiB) Downloaded 17542 times

[EvilGuru]

Hi all,

I have no idea why there is talk of porting it to Mac/Linux when it is written using .Net and OpenTK. A few weeks back a friend of mine was working on a program to simulate video feedback in .Net and wanted my advice on a few things. The program was written in C# + WinForms + OpenTK. It worked fine on my Linux system with Mono.

There really is no need to 'port' it per se. Mono is reasonably complete and OpenTK is just OpenGL (which is what's important, OpenGL as opposed to DirectX).

Now, it is true that Mono's support for VB is more primitive than its support for C# -- however there is not a huge amount of difference between the two languages and it should hardly be seen as a barrier -- mono is getting/has got reasonable support for VB.

Hence, while it may be necessary to make some small changes here and there I see no reason to port it. If the fact that WinForms is not native under Mac/Linux proves to be a problem then maybe it is worth using the Qt/GTK+ wrappers to .Net (GTK# is very popular) to replace the UI, but everything else (loading/saving, rendering, event handling stays).

My advice: get the code into a repository. Doesn't matter where, but having the source under a source code management system is *extremely* important. Once the project is established it should be a trivial task to find a couple of Mono enthusiasts to help you get it running under Linux/Windows. (Open source VB projects are a novelty and make excellent test cases.) But please, please, don't port. (Unless to C#

Just my extremely devalued, inflation stricken, Eurozone threatened, liberally opposed, £0.02. (Although, such coinage, pre 1998, sells for better-than-face-value price on the open scap metal market...God melt the Queen?)

Polemically yours, Freddie.

[Emdek]

After using .NET for two years (desktop applications and for PDA too) I can say that's not worth using.
There are big flaws like for example locale dependent reading of floating numbers from files (in some locales instead of dot char is used comma, in one locale it will cause to lose part after it in another crash).
Another thing are harder to do translations (Qt has built in framework).
Next are additional dependencies (in case of Qt there might be need to add library for ZIP compression but could be done also using built in functions probably).
Next, slowness, mostly visible on older hardware.
Also, unclear licensing of .NET technology (many, or maybe even all, parts of it are patented).
Etc. etc.

[EvilGuru]

After using .NET for two years (desktop applications and for PDA too) I can say that's not worth using.
There are big flaws like for example locale dependent reading of floating numbers from files (in some locales instead of dot char is used comma, in one locale it will cause to lose part after it in another crash).
Another thing are harder to do translations (Qt has built in framework).
Next are additional dependencies (in case of Qt there might be need to add library for ZIP compression but could be done also using built in functions probably).
Next, slowness, mostly visible on older hardware.
Also, unclear licensing of .NET technology (many, or maybe even all, parts of it are patented).
Etc. etc.

There is a big difference between "worth using for a new project" and "worth porting away from."

If Warzone were to be written today it would, in all likelihood, have been written in C++; but this does not mean that it is worth porting Warzone to C++ (so using the STL, real classes in lieu of our quirky structure scheme, a proper, operator overloaded vector library...).

The locale-dependant interpretation of floating point numbers is inherited from C/C++ (see man strtod or the STL documentation). Completely standard --- and usually what you want.

The slowness may well be a problem today. I'm not sure. It may be .NET is at fault, it may be the OpenGL driver. Either way we can not solve the problem today. In 6 months? Quite possibly. But hardware is a moving target -- in the months it takes us to port/optimise the specification of the average machine has improved.

Virtually every piece of interesting technology, be it the 2D drawing in Qt/Cairo, 3D texture compression, ..., is patented by someone somewhere. Don't worry about it. Certainly not a valid case for not using a piece of technology in an open source program.

If you (or anyone, really) could produce a viable Qt port in a few weeks, then maybe I would agree with you. However, this is the first viable map editor to come into fruition in six years. If it was simple it would've been done already. Any port will be non-trivial and risks forking the development.

So while I may agree with you on some technical points (I, myself, prefer C++ and Qt to .NET, but then again, I am not doing any of the work), I do not feel it is economically viable to fork the application just for this. Lets work on what we have as opposed to what we want.

Polemically yours, Freddie.

[Emdek]

There is a big difference between "worth using for a new project" and "worth porting away from."

Sure, but this doesn't mean that it's always bad idea.

The locale-dependant interpretation of floating point numbers is inherited from C/C++ (see man strtod or the STL documentation). Completely standard --- and usually what you want.

Also when reading and writing XML files? Thats nonsense... It's not compatible with anything outside .NET so it could work as really expected, not for strange kind of backward compatibility...

The slowness may well be a problem today. I'm not sure. It may be .NET is at fault, it may be the OpenGL driver. Either way we can not solve the problem today. In 6 months? Quite possibly. But hardware is a moving target -- in the months it takes us to port/optimise the specification of the average machine has improved.

Yes, .NET is fault, it's architecture (would be useful it would really would be used as it was meant to be...).

Virtually every piece of interesting technology, be it the 2D drawing in Qt/Cairo, 3D texture compression, ..., is patented by someone somewhere. Don't worry about it. Certainly not a valid case for not using a piece of technology in an open source program.

So where is billionaire who patented drawing lines?
But being more serious, .NET licensing is much more complicated topic...

If you (or anyone, really) could produce a viable Qt port in a few weeks, then maybe I would agree with you. However, this is the first viable map editor to come into fruition in six years. If it was simple it would've been done already. Any port will be non-trivial and risks forking the development.

So while I may agree with you on some technical points (I, myself, prefer C++ and Qt to .NET, but then again, I am not doing any of the work), I do not feel it is economically viable to fork the application just for this. Lets work on what we have as opposed to what we want.

For sure I'll not work on.NET platform code, especially VB, sot this in worst case could be duplication of effort but should not have big impact on current work.
It's better to start porting before it will become more complicated, less code to rewrite, earlier done.
And yes, it is really possible to do it even in one week, only depends on how much time I can dedicate to that work.

[Buginator]

Flail, if possible, can you do some simple error checks to prevent this from going on?
Basically, it seems to be possible to place things on top of each other.

Code: Select all

error   |11:05:55: [buildFeature] Oil Resource(25) already placed at (115+1, 120+1) when trying to place Oil Resource(162192) at (115+1, 120+1) - removing it
error   |11:05:55: [buildStructure] Player 2 (AI): is building A0CommandCentre at (113, 38) but found A0CommandCentre already at (113, 38)

[KukY]

Flail, if possible, can you do some simple error checks to prevent this from going on?
Basically, it seems to be possible to place things on top of each other.

Code: Select all

error   |11:05:55: [buildFeature] Oil Resource(25) already placed at (115+1, 120+1) when trying to place Oil Resource(162192) at (115+1, 120+1) - removing it
error   |11:05:55: [buildStructure] Player 2 (AI): is building A0CommandCentre at (113, 38) but found A0CommandCentre already at (113, 38)

I thought Zarel fixed that on my request...

[Zarel]

I thought Zarel fixed that on my request...

I said I was planning on it. :/

[KukY]

I thought Zarel fixed that on my request...

I said I was planning on it. :/

You fixed it. I know.

Oh, wait.

I looked at code changes then, and I remember that you only fixed overlapping features, not structures.

[BlueMaxima]

And units.

[KukY]

And units.

Multiple units on same place are enabled.
But you could only do that in CHEAT mode.
And it wouldn't make the game crash.
And it was in all WZ versions.

[BlueMaxima]

Still.
Very.
Very.
Annoying

[Rman Virgil]

.

I can think of at least two specific instances where this is a very useful design option for map makers who know what they are doing. But I understand where that powerful creative usuage may need to be sacrificed to create a goof-up proof environment.

- RV
.

[Buginator]

I thought Zarel fixed that on my request...

I said I was planning on it. :/

You fixed it. I know.

Oh, wait.

I looked at code changes then, and I remember that you only fixed overlapping features, not structures.

We really should not be fixing things that are clearly wrong... We need to complain loudly for whoever made it to fix it.

That is why the tool should have some simple error checking to prevent this stuff from going on.