Warzone 2100 Forums

Are the map data structures explained someplace? I'm sorta undecided between wanting to make a map or have a go at the software behind the map editing. Having a look at the source first, I assume VS2015 (community edition) will behave with this project?

Yes, VS 2015 is a prerequisite for the windows build. Xamarin Studio / Mono run-time if you're using Linux or Mac.

After you fork the repo, restore nuget packages.

That's about it. You should be able to build.

Mac builds require an extra step for .app packaging, just run:

./nant.sh set-dev-env

and it will tweak project files for Mac dev and load correct debuggers under Xamarin Studio. However, there is currently an issue with OpenGL on Mac, which I'm currently working to get rid of. See: https://github.com/opentk/opentk/issues/330 for more info.

Re: Map data structures

Not currently, there's no documentation inside SharpFlame regarding map structs. However, I have made some attempts at making code more maintainable and tad easier to understand. Especially the map parsers. Previously, flame code was doing a ton of string manipulations with +1, +2, +3 offsets, substring, concats, and indexOf code. Parsing like this made everything really hard to understand what was going on regarding map parsing.

In an effort to clean up this, I've written some monadic style parsers. Basically, a Lev,Pie,Grammar parsers are built from a series of smaller parsers. You can find that code here: https://github.com/bchavez/SharpFlame/t ... re/Parsers

In the end, this will allow us to give compiler style warnings like "unexpected character ] at line 4" without much effort.

Re: Architecture Changes

Previously, flame's VB code didn't have any separation of concerns or follow SOLID principals. SharpFlame attempts to introduce SOLID concepts like Inversion of Control and Event Brokers. Additionally, much of the UI components (going forward) are now defined in XAML mark up - which has cleaned up a lot of UI plumbing cruft. Most of the "new UI" is defined here:
https://github.com/bchavez/SharpFlame/t ... pFlame/Gui . The OLD UI is one level up from Gui. As I'm moving forward, OLD code is ported into the Gui folder (using ETO cross-platform UI components), while deleting the old code after porting is done.

• * New Map function working.
  * Windows and Linux CI builds available.
  https://ci.appveyor.com/project/bchavez ... /artifacts

**Warn: Still not ready for testing but for the brave souls that want to go for a crash test.

New Map Working

On a fresh pull down the vs2015 solution doesn't have the right startup project set, which project should it be started with?

- oh, ok, SharpFlame.Gui.Windows, obvs.

The startup project setting is stored in the VS*.suo files (user-specific options) and aren't included in source.

cowboy wrote:
**Warn: Still not ready for testing but for the brave souls that want to go for a crash test.

I will "test" undercover today. Great

The interface looks good. Its a pity, that i cant see, how the generator works. In version 1.29 the interface for the generator-function was very bad. Once you started the generator, you had to open extra tabs for the textures, the layout, the ramps and the objects. The function "water spawns was not in function". Cant wait to see, how the generator will work in this version.

What i dont like are the tilenumbers on the tilesets. They are to large IMO, covering 20% of the tiles. Or try just without the black background.

I started making maps in flame (1.29) to get familiar with the full extent of what you are building with SharpFlame, so now I have a better idea of what its all about. At least now I think I can start diving into your code with a little more clue.
Are you aiming for a full replication of flame to start with, or are you extending the functionality as you go?
There are a few things that I would like to see, should I list them? oh but you insist.. heh

• When placing objects, flame has 3 lists; Features, Structures, Droids. It would be nice to have some extended filtering options here, such as everything relating to scavs, or setting up a player's base, to reduce the switching and scrolling.
• Copy/paste could do with a preview of the clip that is about to be placed, so you can double-check rotations and other transformations before pasting it in.
• The main view in flame crops to a circular view even when you zoom out as far as you can. Is this really necessary? I would prefer it to display the full map area in range when pulling back to review it from on high. If you know what I mean.

Just some thoughts, not sure how far you have planned UI changes.

Right now, in my view, the highest priorities in order are:

1. Complete the migration of all UI components to the new cross-platform ETO UI framework. This means migrating all UI component definitions to XAML.

2. Once all UI components have been migrated to XAML, ensure the implementations backing those UI components are semantically consistent with the original Flame.

3. Next, remove all WinForms references and their old Flame implementations.

4. Final refactoring and retouches of internal architecture and models that were only kept to facilitate the WinForms implementation. For example, there's one global class with static variables called App, that should get nuked and replaced with an IoC'ed version.

5. At this point, we would have a stable code base. Lock as much of it down with unit tests especially map parser and map compiler code. Make CI server run and pass all unit tests before publishing releases. Fix long-standing bugs. Now we can make improvements.

5.5. Work on the Mac OpenGL issue. https://github.com/opentk/opentk/issues/330 ... eventually, we'll get it to work.

-------------------

I'm not extending any functionality right now besides small refactorings of the code base along the way. Only small incremental improvements to the overall architecture. Extending functionality at this point would only add more complexity to an already evolving code base. When we are at stage 5 then it would be a good time to extend functionality of the map editor.

The only feature I removed from the original flame is working on multiple maps at the same time. The entanglement of data structures and object linkage was way too complex under the hood to keep it. Multiple map support over complicated the code way too much the way it was implemented.

There are small UI changes in SharpFlame that help promote usability. For example, some tabs only display UI components relevant to the tooling context. For example, original flame displayed all options on the tab page regardless if they were used or not. In SharpFlame, only some selections would reveal the relevant tool options for the selected context.

The last bit of UI that needs to be converted to XAML is the TextureTab and TerrainTab. I started on the TerrainTab, but haven't finished it yet. https://github.com/bchavez/SharpFlame/t ... i/Sections

The goal of these changes is to simplify the code, make it easy to understand, and more maintainable. Without this fundamental underpinning, extending the editor with new features would be an extremely difficult effort without breaking something along the way.

@montetank:
Regarding the "Map Generator" stuff. I don't know if the map generator is worth keeping. Any thoughts?

BTW, ETO has a great (and free) VS Designer Addin that works with Community Edition:

https://visualstudiogallery.msdn.micros ... 69d4095f81

So, if you're converting UI code, be sure to get it installed as it would help you a lot when writing the xeto XAML markup.

cowboy wrote: The only feature I removed from the original flame is working on multiple maps at the same time.

Will there still be a way to copy a section from one map and paste it into another? That's about the only reason I would want to have two maps loaded at once, otherwise I think you are correct in going with a single map instance. I believe in Windows the clipboard objects can be typed objects, but for others?

As for the generator, personally I found the generated terrains a little over-complicated and lacking purpose. They can make an interesting starting point when I want a new battle arena but lack the initial imagination boost, but they are still lacking in major features, control areas or choke-points, and feel a little wallpapery, so editing and building on a generated map can be fun. Some separated aspects of it would be nice to have, such as selecting an area or multiple base areas, and generating the startup base layouts from a selection of templates.

Frogmorton wrote:
As for the generator, personally I found the generated terrains a little over-complicated and lacking purpose. They can make an interesting starting point when I want a new battle arena......

Agree. So, i use the generator in a different way. I hope you will understand my bad english.
-At first i let make the generator a large map without symmetry. with and height 250 max. Many passages and some flats in middle size. The base area small.
- When the generator finished i try to find a section on the map which looks fine for my idea.
-I paste the bmp-map to GIMP
-No i cut the section which i want out and work with this section in Gimp.
- Finished in Gimp i transpont my heightmap back into flame.
-The bases, terrain, features and oil are handmade.

Without using Gimp or a similar program its difficult to make a nice map. The generator is only a starting help.
NoQs Vid on Youtube inspired me to work with Gimp.https://www.youtube.com/watch?v=rr14Ir4BkGk

BTW-Without Gimp it is impossible to make symmetrical 3-5-7-9 player maps and it solves your copy-problem

Yeah I have found Gimp very useful.
I found the Flame copy & paste option to include objects works ok, so a base layout can be stamped in multiple places, with rotation as well, so that makes it a little easier.

Frogmorton wrote:Yeah I have found Gimp very useful.
I found the Flame copy & paste option to include objects works ok, so a base layout can be stamped in multiple places, with rotation as well, so that makes it a little easier.

You can rotate only the single structures, not the whole layout (except 90-180-270 degrees) and then you have to delete the single structures and again to placed them, because they are not attempt to the players number. Example: command center player 0. Position x= 12 y = 12. If you copy and paste to x= 80 for example and y= 12 then this second command center is not the command center for player 1 but the second command center for player 0. This is a bad minus in flame. You cant attempt the structures to a player after pasting.
Or did you found a way? That would be great

Select as many objects as you want and click the player button in the objects tab.