Sadly, I'll take a wait-and-see approach as far as this point is concerned.

exporting randomly generated maps as scenarios enyone? We love sharing our stuffs.

and, positioning starting positions on those scenarios.

That is so simple and needed, why isnt it already on??please!

All we can do now is hope and wait. 

Like we've been doing for the last (almost) three years...

Oh, I forgot to add the map maker.   I have found it easier to use the particle effects editor than it is to use the map editor.  I really wanted to make unique stamps, but after 2 hours of fiddling trying to figure out how to place a monster in my stamp, I gave up.  If the tools aren't bugged, then a good tutorial on how to use them is 100% in order.

And in reality you can do quite a lot with a SpellDef.  It doesn't have to be a 'spell' per se. 

It would be an improvement if they they made more GameModifier ModTypes and Attributes possible.

I think HF touches on a pretty good point here.  We're probably best sticking to stuff that is probably an easy fix.... or things that are really a major issue (object sanity, map editor issues).  

There's loads of stuff that would be cool to have... but targeting the stuff that will give the best value for money so to speak is probably the way to go at this stage.  Adding calculations to all/more tags would probably be a lot of work. 

well, that's why I was saying add calculations to one more tag, that is already in use.   It would add alot of functionality, for minimal coding changes, without increasing overhead noticeably.

The city they are stationed in.   It would be doable by causing the governor to add a resource to the city, and allowing a building to calculate that into how much exp to yield to troops stationed there, or the odds of it yielding experience per turn.

As it stands, neither of these tags tolerate calculations. 

I have no idea which would be easier.  I think adding calculations to the <Operator> tag would add the most versatility for the least effort, as I would hate to ask for new code that would help pretty much just my mod.   but I honestly have no idea what their spaghetti looks like on the inside.  Any of these solutions would be helpful.

Any news on that? There's good modding stuff that requires this to work .

As far as the cartographer's table goes, it would be really useful to have the ability to Modifier+click on a tile and see everything that's in that tile, maybe even with an XML code preview in the right pane.

When you go adding stuff to the map that's fine and dandy but it would be nice to see what you have actually placed, parameters and all.  This has the added bonus of giving the developers some immediate debug feedback to see if the map tool is actually doing that particular object properly or if it needs tightening up.

1. Consistency for all xml files. As specified in https://forums.elementalgame.com/434780/page/1/#3344779 thread.

2. Change race/unit folder structure so that each faction has their own unit folder where those faction specific units will be stored. I mentioned that in the linked above thread.

3. Ability to chose operator for values. Needed if I want to change, say, production per material to be -10% instead of a flat value. I'd just specify % and use -10 value.

4. Have a comprehensive documentation for modders where you can find all the possible game variables, modding options and tutorials in one place. It would help newcomers a lot. Searching this forum only goes so far.

I guess I'm not really buying the 'massive overhead' argument r.e. allowing more calculations by modders.  The stuff I wanted to mod back in the day (hp calculations and such) doesn't need to be recalculated constantly; once per turn would have been more than sufficient.  Any stat changes that would happen during a turn (such as an item that relies on a stat calculation for some effect) really could wait until the start of the next turn.

The game is keeping track of a lot of stuff anyways (literally tens of thousands if not millions of calculations a turn), so a handful of additional calculations really wouldn't bring the house of cards down, as long as they aren't being recalculated every couple of seconds.  Variables that 'store' whichever calculation you just did would remain the same until the start of the next turn, at which point a new calculation could be made.

That's how I'd compromise on this.

Also, 'fudging' with SpellDefs seems to be 'the long way around' to attempt certain things, so if you could have more 'persisitent' methods to access some variables, hence lowering the calculation overhead and streamlining the code, this would help. 

I haven't tackled E:LH modding yet, but I know I was having a lot of frustration trying to get certain things to work in E:WOM, as I'd have to define things in multiple places/files that really should have been able to have been done in one spot in an ideal world.  Once the dust settles r.e. LH, I'll look at this again and see if I can articulate this more clearly, but as far as I can tell, not too much has changed since E:WOM file/tag handling wise so I'm probably pretty much still on the mark here.

As for what I'd like to see, I'd absolutely love to get at some of the underlying base calculations.  I see some new tags in the ElementalDefs.xml, which might be interesting to play with, but how attack versus defense calculations is what I'm specifically wanting to play with.  Most people don't care about this, but how this is implemented can have dramatic effects on how combat works in YOUR mod.  And knowing exactly how these calculations are done can go a long way towards understanding how to balance whatever items and such you are considering for your mod framework.

For example, in the TripleA project, you can set the number of sides of the dice used in combat, as well as define bonuses, in rather specific ways in some cases (such as terrain giving a +1 to defense for scout units as an example).  Sure, this is a little apples and oranges, but the point is that since TripleA has so many options r.e. modding, it makes it more interesting to play around with, hence the large number of non WWII scenarios that have been made for that project to date.

The more access us modders are granted to a game engine, the more interesting things some of us can accomplish with it.  And it helps if we don't need a bunch of special tools, so the more that can be included in the Defs file, the more we can tweak and experiment.

Anyone that uses mods should already understand that user mods don't always work as expected.  But since Elemental isolates these (for the most part) to the Mods folder, simply uninstalling a broken mod should solve any issues if some modder didn't have his math straight or whatever.

Plus, us modders like to 'break the rules' a bit, and do things that the developers may have not even thought of.  So the more flexible a game is, the easier a time we have to do this, which keeps us more interested in attempting mods in the first place, which by definition is trial and error.  And the less we are able to do, as Heavenfall pointed out in another thread recently, the less interest we have in trying.

And a 'bible' of variables, tags, and such in Elemental would be nice.  Sure, we can try to divine these out of the .xml files, but I'm still guessing at some of the variables even today. 

For example: I had to peruse multiple threads to find out why a CDATA calculation I was attempting wasn't working, and that this issue is still an issue.  I was trying to do a Def calculation with a percentage of the Con stat adding to Def, tied in with an item, that was persistent, which kept coming up 0.  Heavenfall explained why the calculation wasn't working (generally only work within Spelldefs), but it would have been nice to know up front what the options were, instead of trying to glean them out of the .xml and wasting hours on the research.

Another thing that can be incredibly frustrating for modders is when we've incorporated a feature into our mod, that is disabled/drastically changed in later patches.  This can seem rather punitive at times, and makes people less willing to keep modding when the rules keep changing.  In fact, this is why I ended up stopping my work on my E:WOM mods, because of the large number of files I was working with in my mods, and said changes affecting my work: Which files did I change again?  And what changes did I make?  And will they still work?.  I don't enjoy redoing things multiple times, and losing features along the way.  Now that E:WOM is pretty much 'abandoned', at least I can count on what's left (after the 'gutting' of sorts) not changing.  But I'm afraid to do much with E:LH when it is released BECAUSE I see several changes coming in the next few months, and I need to know where things 'end up' before I will feel comfortable attempting anything new.

Yeah, I got off on a rant there, but I enjoy modding games, and felt the need to share my frustration r.e. Elemental modding to date.

The goal should be as much flexibility that is feasable, so that more mods are created.  More mods being made should add to the replayability of a game, which adds to the value of a game overall.

To summarize, what I'd like to see is:

1) More calculations made available to modders.  Limiting the number of times a calculation is made (once a turn or whatever) should keep CPU overhead within reasonable limits.

2) A 'Bible' explaining how the underlying calculations are done.

3) Access to more of the underlying calculations, so we can adjust these if we so choose for our mods.  Changes restricted within the mod folder, of course.

4) A Wiki or whatever of all terms/tags used in Elemental, where they are found, and how they work.

5) Work towards consolidating/streamlining terms/tags in future versions of Elemental where possible.  Why change 3 files when it can be done in 1?  This won't always be practical, but it'd be nice to not have to search/modify dozens of files to make a specific change/add a new effect or item.