flaME -- The Warzone 2100 Map Editor [pre 1.10 thread]

[ninjatoast]

Vista.

I'm expecting someone to say 'Well that's your problem' now.

[macuser]

what version of the .net runtime environment do you have (you need ver 4) if you don't have it just google .net runtime 4.0

[ninjatoast]

No idea what version I have, but I'm installing 4.0 now, hopefully it will work.

Edit- Nope, still not working. I'm going to try re-downloading.
Edit 2- Still not working.

[macuser]

hmm try downoading the modified ver of flaME that I wrote for mac/linux and run that on windows. you may have a few problems with minor features on windows but it *should* take care of your problem since it is based on a prev release of flaME.

[ryanpearl50]

Hey i'm having trouble with making like a Campaign map, when I compile the map, i don't know what to put in the "Type:" box, can anyone help out or should i just not worry about it?

[Flail13]

flaME wont make a campaign on its own. You will need files for unit stats, ais and .wrf and .lev files to point the game to your map. Multiplayer maps are easier.

If you still want to try it, according to Per,
Campaign "Time" should be 2.
For campaign "Type":
0 - Initial scenario state.
1 - Scenario scroll area expansion.
2 - Stand alone mission.

[Buginator]

Being able to handle map names without the useless Sk- is a more resilient design in any case. And it is one more line of code.

As far as I know, Warzone is already able to do this. However, whether or not FlaME should be able to save in such a format is a whole other question.

Hmm ? We want flaME to dump out a header of the flaME version on top of the addon file, and to drop everything but skirmish, since the other game modes are not used anymore.

Once that is done, then flaME don't need to prefix "Sk-" to the map name. There is no need for it at all.

Four disadvantages:
1. Two different map formats will be floating around.

Why is this a disadvantage ? flaME can re-compile maps if need be, and since we don't support the old modes anymore, I don't see this as a issue at all.

2. Savegame compatibility will be broken.

Yeah, but, again, since all new maps can be recompiled, having to redo a skirmish game again isn't that big of a deal.
The level loading code is ... and odd the way it was done. If the savegame has all the map info needed, then why does it even bother trying to load it again ?

3. Either we'll have to write code to remove the "Sk-" anyway, or users will have to deal with a map list with some maps containing "Sk-" and some maps not, and will go around asking what the difference is.

That isn't that big of a issue either. The patch in trac removes the Sk- prefix so it would be unseen.

4. I'm not familiar enough with the netcode to say this for sure, but I think if one person had a "Sk-" version of a map and one person had a no-"Sk-" version, they could crash if they tried to play together.

Yeah, it will fubar, but as long as it can find the correct (unique) name, it shouldn't be a issue...and a trivial fix.

5. We lose compatibility with EditWorld, unless we add even more hacks to that. We also lose compatibility with old versions of FlaME.

It would mean people with EditWorld would need to recompile map with Flame. No real problems here either.

And the advantage is a slightly cleaner map format, and (if you include disadvantage #3) less code to remove "Sk-" in-game (I note we already have code to remove "Sk-" in the map transfer code). I just don't think it's worth it.

Why spit out more info than what we support ?
Again, there is no valid reason for flaME to do this anymore, besides the more or less trivial points that you pointed out.

[Zarel]

Why is this a disadvantage ? flaME can re-compile maps if need be, and since we don't support the old modes anymore, I don't see this as a issue at all.

Oh, I was operating under the assumption we were going to continue supporting old mods.

In that case, there is one huge problem here:

Recompiling maps is far worse of a burden than committing like a six-line patch.

Demanding that users recompile all their maps just because you don't want to add a tiny change to the code is... mind-boggling.

Savegame compatibility would indeed be a small problem compared to map compatibility, but that's not because savegame compatibility is a small problem, it's because map compatibility is a huge one.

That isn't that big of a issue either. The patch in trac removes the Sk- prefix so it would be unseen.

Oh, so we are committing that patch, then? Then why do we need to remove "Sk-" from new maps?

Yeah, it will fubar, but as long as it can find the correct (unique) name, it shouldn't be a issue...and a trivial fix.

I think not changing anything is an even trivialer fix, and has an added advantage of not having to change anything.

Like I said above, if we are committing that patch, there is pretty much zero advantage to making this change.

It would mean people with EditWorld would need to recompile map with Flame. No real problems here either.

...

......

.........

...it... it's like you hate users or something.

Please, go ask any of the EditWorld users if they would like to recompile with FlaME for virtually no reason whatsoever.

Why spit out more info than what we support ?
Again, there is no valid reason for flaME to do this anymore, besides the more or less trivial points that you pointed out.

Oh, feel free to drop the data for multiplay maps. Dropping support for 2.0.x isn't as big of a deal (though, it would save maybe 20 bytes, and would make testing more difficult since you'd have yet another map format to test. One of these days, I will teach you to factor "costs" into your cost-benefit analyses).

On the other hand, snipping the "Sk-" off of existing maps can cause quite a few problems. You may call them "trivial", but they would be considered huge problems in comparison to the actually trivial benefits of snipping off the "Sk-".

[ryanpearl50]

Thanks!!!

[Buginator]

Why is this a disadvantage ? flaME can re-compile maps if need be, and since we don't support the old modes anymore, I don't see this as a issue at all.

Oh, I was operating under the assumption we were going to continue supporting old mods.

In that case, there is one huge problem here:

Recompiling maps is far worse of a burden than committing like a six-line patch.

Demanding that users recompile all their maps just because you don't want to add a tiny change to the code is... mind-boggling.

Savegame compatibility would indeed be a small problem compared to map compatibility, but that's not because savegame compatibility is a small problem, it's because map compatibility is a huge one.

What old mods we talking about ?
The users will NOT have to change anything, this is only for new stuff.

Again, the only change flaME will do is drop the SK- prefix, and NOT write out the unsupported game types that we don't support.

That isn't that big of a issue either. The patch in trac removes the Sk- prefix so it would be unseen.

Oh, so we are committing that patch, then? Then why do we need to remove "Sk-" from new maps?

Unsure. I can go either way on this, having some maps labeled 'Ski-blah' vs Blah don't really bug me that much, but there is no need for the 'Sk-' prefix anymore.

It would mean people with EditWorld would need to recompile map with Flame. No real problems here either.

...
......
.........
...it... it's like you hate users or something.
Please, go ask any of the EditWorld users if they would like to recompile with FlaME for virtually no reason whatsoever.

No... the only time they (the author of said map) would need to do this, is if they want to have a map name without the 'SK-' prefix. (If we don't have the strip patch) Heck, I will even check if I can hack the binary again to remove the need for this.

Why spit out more info than what we support ?
Again, there is no valid reason for flaME to do this anymore, besides the more or less trivial points that you pointed out.

Oh, feel free to drop the data for multiplay maps. Dropping support for 2.0.x isn't as big of a deal (though, it would save maybe 20 bytes, and would make testing more difficult since you'd have yet another map format to test. One of these days, I will teach you to factor "costs" into your cost-benefit analyses).

On the other hand, snipping the "Sk-" off of existing maps can cause quite a few problems. You may call them "trivial", but they would be considered huge problems in comparison to the actually trivial benefits of snipping off the "Sk-".

There is a valid reason, we don't need the data, and the 'Sk-' prefix is useless.
Warzone can still read in the other game types, but we don't use then, so why bother reading it in the first place?

You are blowing the requested changes in flaME way out of proportion, we can't even load pre 2.3 savegames with the current binary, and we don't support 2.0-2.2.x anymore.

One more time, nothing is going to break if (when ) Flail13 makes the requested changes in the next version.
The users will just see some maps with the "Sk-" prefix in front of some maps--if we don't do the patch, and not see "Sk-" at all with the patch.

In short, Flail13 needs to add a flaME version banner (+ $(current date & time), and $author) to the addon file.
Don't bother with the Sk- prefix, or the unsupported game types.

[Zarel]

What old mods we talking about ?

Whoa, that part of my post didn't make any sense at all. Probably because halfway through writing it, I realized I had misinterpreted what you were saying. Let's just ignore that part of my post.

Unsure. I can go either way on this, having some maps labeled 'Ski-blah' vs Blah don't really bug me that much, but there is no need for the 'Sk-' prefix anymore.

No, I mean, why do we need to remove "Sk-" from the map format?

No... the only time they (the author of said map) would need to do this, is if they want to have a map name without the 'SK-' prefix. (If we don't have the strip patch) Heck, I will even check if I can hack the binary again to remove the need for this.

In other words, the only time map authors would need to do this is if they wanted to create a standard map.

Or are you actually proposing that we support two map standards without advocating one over the other?

There is a valid reason, we don't need the data, and the 'Sk-' prefix is useless.

"Useless" is a good reason to remove data if it is easy to do so.

"Useless" is not a good reason to remove data if it results in two map formats to support, and all the hacks and additional testing that entails.

Warzone can still read in the other game types, but we don't use then, so why bother reading it in the first place?

Who says we need to read it in? We can skip them in Warzone.

You are blowing the requested changes in flaME way out of proportion, we can't even load pre 2.3 savegames with the current binary, and we don't support 2.0-2.2.x anymore.

Yes, but supporting two incompatible map types for pretty much no reason... the mind boggles.

One more time, nothing is going to break if (when ) Flail13 makes the requested changes in the next version.
The users will just see some maps with the "Sk-" prefix in front of some maps--if we don't do the patch, and not see "Sk-" at all with the patch.

Okay, so, what the disadvantages and advantages are depend on two questions: Will we do the patch? And will we ever drop support for the old map format? For the following analysis, I will assume the answers are 'yes' and 'no', respectively.

You are correct in that nothing will break. But nothing will be fixed, either. The only change will be all the disadvantages of supporting two map types, and none of the advantages.

I wish to again list the disadvantages, now that I have a stronger idea of what we're doing:

1. More hassle for EditWorld mappers if they want to use the new format, to convert their maps in FlaME (not to mention all the people who use EditWorld because they can't get FlaME to work)
2. More hacks in the code, to work around the netcode incompatibilities of the two map formats
3. Savegame incompatibility of the new map formats
4. More hacks in the code, to support two map formats
5. More testing, to ensure regressions don't occur in the map format you didn't test

Okay, I fully admit, these are somewhat small disadvantages, but they are huge compared to the actual advantages, which are:

1. Save about 20 bytes in the map format.

No, I can't think of another. "No need to process information we don't use" is invalid, since we still have to support map formats in which the useless information is still there.

"Okay," you say, "So then we will eventually drop support for the old format."

Well, then, that does add another minor advantage: The ability to simplify the code by around six lines. This also adds a huge disadvantage: DROPPING SUPPORT FOR THE OLD MAP FORMAT.

"But that's not a problem," you say. "We'll have a converter."

At that point, I just stare at you and ask how an external converter that needs to be called manually, would be superior to leaving in approximately six lines of compatibility code in the game itself.

I could understand this change perfectly, if we rolled it into a new map format to support stuff like 5-player maps, or larger map sizes, or whatever, and so we were forced to drop support for the old map format, and so the overhead of supporting two map formats would not apply. But by itself? The overhead of adding a new map format is negligible compared to its benefit.

[Buginator]

Unsure. I can go either way on this, having some maps labeled 'Ski-blah' vs Blah don't really bug me that much, but there is no need for the 'Sk-' prefix anymore.

No, I mean, why do we need to remove "Sk-" from the map format?

Besides the map creators having a whole 3 extra letters, and other than it isn't needed ? Nothing.

No... the only time they (the author of said map) would need to do this, is if they want to have a map name without the 'SK-' prefix. (If we don't have the strip patch) Heck, I will even check if I can hack the binary again to remove the need for this.

In other words, the only time map authors would need to do this is if they wanted to create a standard map.

Or are you actually proposing that we support two map standards without advocating one over the other?

I don't understand why you think this is a new format. It is not. Not even close.
It is only a unique name change, nothing else. I can't make this any more clear.

There is a valid reason, we don't need the data, and the 'Sk-' prefix is useless.

"Useless" is a good reason to remove data if it is easy to do so.
"Useless" is not a good reason to remove data if it results in two map formats to support, and all the hacks and additional testing that entails.

it is NOT A NEW FORMAT!

Warzone can still read in the other game types, but we don't use then, so why bother reading it in the first place?

Who says we need to read it in? We can skip them in Warzone.

Eh ? It still must parse it...

You are blowing the requested changes in flaME way out of proportion, we can't even load pre 2.3 savegames with the current binary, and we don't support 2.0-2.2.x anymore.

Yes, but supporting two incompatible map types for pretty much no reason... the mind boggles.

No, what boggles the mind is how you think this is supporting two incompatible map types, when the only thing that is changing is the unique name. That is it, nothing more.

One more time, nothing is going to break if (when ) Flail13 makes the requested changes in the next version.
The users will just see some maps with the "Sk-" prefix in front of some maps--if we don't do the patch, and not see "Sk-" at all with the patch.

Okay, so, what the disadvantages and advantages are depend on two questions: Will we do the patch? And will we ever drop support for the old map format? For the following analysis, I will assume the answers are 'yes' and 'no', respectively.

The map *format* will not change. Stop assuming that, and you will see the light.

You are correct in that nothing will break. But nothing will be fixed, either. The only change will be all the disadvantages of supporting two map types, and none of the advantages.

I wish to again list the disadvantages, now that I have a stronger idea of what we're doing:

I don't think that is the case at all. You are confusing a unique name change with a format change.

1. More hassle for EditWorld mappers if they want to use the new format, to convert their maps in FlaME (not to mention all the people who use EditWorld because they can't get FlaME to work)

Again, there is NO NEW FORMAT.
It is a unique name change, that is all. I don't know of any people who can't get flaME to work, but I know lots of people that can't get EW to work.
Either way, again, the game will still read the compiled map from EW just fine.
There is no change to this. The unique map name will still be named "Sk-"+mapname just like always.
If the map creators don't want that, then they use flaME to recomile the map.

2. More hacks in the code, to work around the netcode incompatibilities of the two map formats

Read the code again, if 'Sk-' is there, then it strips it, if not, it don't.

3. Savegame incompatibility of the new map formats

It will ONLY break if the map isn't there anymore. This is nothing new.

4. More hacks in the code, to support two map formats

... repeat after me, there isn't two map formats.

5. More testing, to ensure regressions don't occur in the map format you didn't test

.. Um, yeah... besides it NOT being a new map format...

Again, you are confusing a new map FORMAT with what is going on, the FORMAT of the map is still 100% the same.
The difference is ONLY the unique name change.

[m1ndgames]

Hello!

I hope anyone can help me: Flame suddenly stopped working

Error:
Unhandled exception:
Requested GraphicsMode not avaiable. SetPixelFormat error: 87.

Code: Select all

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
OpenTK.Graphics.GraphicsContextException: Requested GraphicsMode not available. SetPixelFormat error: 87
   at OpenTK.Platform.Windows.WinGLContext.SetGraphicsModePFD(GraphicsMode mode, WinWindowInfo window)
   at OpenTK.Platform.Windows.WinGLContext..ctor(GraphicsMode format, WinWindowInfo window, IGraphicsContext sharedContext, Int32 major, Int32 minor, GraphicsContextFlags flags)
   at OpenTK.Platform.Windows.WinFactory.CreateGLContext(GraphicsMode mode, IWindowInfo window, IGraphicsContext shareContext, Boolean directRendering, Int32 major, Int32 minor, GraphicsContextFlags flags)
   at OpenTK.Graphics.GraphicsContext..ctor(GraphicsMode mode, IWindowInfo window, Int32 major, Int32 minor, GraphicsContextFlags flags)
   at OpenTK.WinGLControl.CreateContext(Int32 major, Int32 minor, GraphicsContextFlags flags)
   at OpenTK.GLControl.OnHandleCreated(EventArgs e)
   at System.Windows.Forms.Control.WmCreate(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.UserControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
flaME
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Owner/My%20Documents/Downloads/flaMEv1-05/Application%20Files/flaME_1_05_0_20/flaME.exe
----------------------------------------
Microsoft.VisualBasic
    Assembly Version: 8.0.0.0
    Win32 Version: 8.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Runtime.Remoting
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
OpenTK.GLControl
    Assembly Version: 1.0.0.201
    Win32 Version: 1.0.0.201
    CodeBase: file:///C:/Documents%20and%20Settings/Owner/My%20Documents/Downloads/flaMEv1-05/Application%20Files/flaME_1_05_0_20/OpenTK.GLControl.DLL
----------------------------------------
OpenTK
    Assembly Version: 1.0.0.201
    Win32 Version: 1.0.0.201
    CodeBase: file:///C:/Documents%20and%20Settings/Owner/My%20Documents/Downloads/flaMEv1-05/Application%20Files/flaME_1_05_0_20/OpenTK.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

I googled the error of course but it didnt help me... my desktop is set to 32 bit and i didnt made any change to the system afaik, worked with flame 2 days ago.

\edit:

i tried to use flame on linux using mono, but flame cant load the tilesets so i cant use it -.-

(Error loading Arizona Tileset: 5;)

[Buginator]

Hello!

I hope anyone can help me: Flame suddenly stopped working

Error:
Unhandled exception:
Requested GraphicsMode not avaiable. SetPixelFormat error: 87.

That means, that it could find the correct bit depth (or maybe a invalid resolution). Try 32bit desktop.

[Mysteryem]

Currently creating with the arizona tileset and I noticed that brown and sand don't blend together when using the terrain painter:

My suggestions for improvement:

1. Team-coloured buildings and units or team-colouring the text that appears over objects that you hover over with the mouse.
2. Red terrain to only include the highlighted red tiles and a new Pink terrain paint which includes the highlighted pink tiles:
   
3. Ability to flip the selection along an axis.
4. Do not set all triangles for water type tiles, or at least the option not to do so. (changing the tri direction on some water tiles which have a gradient will often glitch them in-game)
5. Manual triangle setting.
6. More control over objects with the mouse, for example: clicking and dragging an already selected object moves it and right clicking on an object opens its properties.
7. When making a selection, the option to use a grid instead of a rectangle:(excuse the crappiness)