Re: A Map Editor
Posted: 22 Apr 2010, 06:10
deleted
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.
Page 19 of 21
Re: A Map Editor
Posted: 22 Apr 2010, 09:00
Re: A Map Editor
Posted: 24 Apr 2010, 22:05
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.
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.
Re: A Map Editor
Posted: 24 Apr 2010, 22:14
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 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.
Re: A Map Editor
Posted: 24 Apr 2010, 22:40
There is a big difference between "worth using for a new project" and "worth porting away from."Emdek wrote: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.
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.
Re: A Map Editor
Posted: 24 Apr 2010, 22:45
Sure, but this doesn't mean that it's always bad idea.EvilGuru wrote:There is a big difference between "worth using for a new project" and "worth porting away from."
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...EvilGuru wrote: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.
Yes, .NET is fault, it's architecture (would be useful it would really would be used as it was meant to be...).EvilGuru wrote: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.
So where is billionaire who patented drawing lines?EvilGuru wrote: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.
But being more serious, .NET licensing is much more complicated topic...
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.EvilGuru wrote: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.
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.
Re: A Map Editor
Posted: 25 Apr 2010, 05:46
Flail, if possible, can you do some simple error checks to prevent this from going on?Flail13 wrote:
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)
Re: A Map Editor
Posted: 26 Apr 2010, 22:46
I thought Zarel fixed that on my request...Buginator wrote: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)
Re: A Map Editor
Posted: 26 Apr 2010, 22:46
I said I was planning on it. :/KukY wrote:I thought Zarel fixed that on my request...
Re: A Map Editor
Posted: 26 Apr 2010, 22:52
You fixed it. I know.Zarel wrote:I said I was planning on it. :/KukY wrote:I thought Zarel fixed that on my request...
Oh, wait.
I looked at code changes then, and I remember that you only fixed overlapping features, not structures.
Re: A Map Editor
Posted: 27 Apr 2010, 00:04
And units.
Re: A Map Editor
Posted: 27 Apr 2010, 09:57
Multiple units on same place are enabled.BlueMaxima wrote:And units.
But you could only do that in CHEAT mode.
And it wouldn't make the game crash.
And it was in all WZ versions.
Re: A Map Editor
Posted: 27 Apr 2010, 23:26
Still.
Very.
Very.
Annoying
Very.
Very.
Annoying
Re: A Map Editor
Posted: 28 Apr 2010, 00:28
.
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
.
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
.
Re: A Map Editor
Posted: 01 May 2010, 03:10
Zarel wrote:I said I was planning on it. :/KukY wrote:I thought Zarel fixed that on my request...
We really should not be fixing things that are clearly wrong... We need to complain loudly for whoever made it to fix it.KukY wrote:You fixed it. I know.
Oh, wait.
I looked at code changes then, and I remember that you only fixed overlapping features, not structures.
That is why the tool should have some simple error checking to prevent this stuff from going on.