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?

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 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.

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.

In case the WZ-game ends in a draw , the game winner will be determined by penalty shoot-out.

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.

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.

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 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?

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.

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

In case the WZ-game ends in a draw , the game winner will be determined by penalty shoot-out.