As per Frogboy's request, I'm creating this post so that each community member may list up to 5 items related to modding We (read Modders) each would like to see implemented by Stardock.
1. This does not mean Stardock will ever do anything about making fundamental modding changes to their Elemental franchise. It should simply be seen as a wishlist of things We would appreciate from the developers to make our lives a bit easier during the modding process.
2. We understand that We are an underwhelming minority of the game's users, and We respect the fact that altering modding tools takes labor-hours and thus cash to support. Therefore the issues presented and the changes asked for ought to be reasonable in this respect. However, We are not game developers ourselves, thus We respectfully ask that Stardock try to communicate issues like feasability and impact with us whenever possible.
3. Keep each item as detailed and to the point as possible; including specific examples whenever possible will only help our case.
Sadly, I'll take a wait-and-see approach as far as this point is concerned.
The priority is that the highly skilled modders get what they need to work ... for us ! They made clean lists of what they had asked during months, ok (and thanks in advance for your future work on this !).
I have one request, for my own business. I'm not sure this would help them but it would save me hours :
- give us a way to launch the game in a "test mode", where we could, for example, reload the Mods folder
The game hasn't been released in my own language. Of course you can't guess what I've been able to understand from the observation of the game and from a patient dissection of the files (core and modded). But, understanding all the posts in this excellent forum is just too difficult for me. Knowledge acquirement from the posts of the helpful modders is a pain for me, especially when some functions are broken or can change with patches (in that case, I just think that I didn't understand the poster and I loose a lot of time trying to figure out where I'm wrong). And if they make jokes, I am done.
I just wanted to remind here that some of us (maybe not lots) have to "touch things" because of a lack of fluidity in English.
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!
Rather than muddy the waters, I'm just going to say that Heavenfall and MQPiffle have already struck at the heart of the issues.
I honestly don't know how the folks at Stardock work with the tools they do. The map tool is so buggy it would drive me insane to work with on a daily basis. Surely, these intelligent folks understand what a workaround is, and can recognize when they are doing some ridiculous action (exiting and reloading the game every time you save a map, for example) to make a tool work properly? Sometimes fixing the problem IS time saved, in the long run.
There is excellent feedback in this thread to the developers from other people who have looked through the xml and played with their code at length. Hopefully some of it will have an impact.
All we can do now is hope and wait.
Like we've been doing for the last (almost) three years...
The important ones to me from the other thread:
1. allowing us access to the tile yield formula and cap. I'm aware we can change the tile yield, but there was a hard cap of 9 total resources per tile put in place. I would very much like to alter that number. There was a brief time where spots with resources like 5 materials 3 grain 4 essence were out there. That was the most fun period of the game for me, and from what folks have said in the forums, they very much enjoyed it too.
2. A simple bug, when you lose an essence from a city (scrying pool gets destroyed, or w/e) you can still retain an enchantment that was in that slot. For example : city has no essence. build a scrying pool. Cast Enchanted hammers on city. Destroy scrying pool. Enchanted hammers remains even though the city has no essence. My mod works alot with essence in a city, and this matters for it.
3. Allow calculations to be performed in a broader array of <value></value> tags. (like the exp yield for a building to troops in a city). I would very much like to be able to have governors alter the experience yield for troops in a city they are stationed in. This isn't possible at the moment, but it would be if we could only have a formula in a building granting experience to stationed units. I assume there are other <value> tags that do not tolerate formulas, but someone like mpqfile or havenfall could probably give a more complete list.
Thank you very much for your time and consideration.
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.
This is one of those things that just isn't going to happen. We've requested similar things back in the E:wom days and the official reply was that the overhead (CPU drain) would simply be enormous. It actually makes sense, because when you think about it, there's probably a few hundred thousand game modifiers active in a game. So they probably had to program in a lot of ways to not have to parse through them all every turn in the game. Such as knowing for a fact that equipment gamemodifiers do not ever change. And that trained units do not ever change equipment. And that traits cannot be removed, only gained. And so on.
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.
That sounds logical. It would be nice if we could have it activated for that particular tag though. Or for a broader array of effect, the %chance that a bonus would be given. (it's on the current building that yields xp, if that could accept a calculation, that would give us MUCH more freedom, and the tag wouldn't be resource consuming because it is rarely present)
EDITED TO CLARIFY:The adventurers Guild Uses the <Operator> tag, to give a % chance that an effect will take place. I don't know how wide spread that tag is, but if it is prolific, then it could add a great amount of versatility if it could accept calculations.
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.
Oh, I forgot to add the map maker.
Actually just noticed you also mentioned the map maker.
Seems that the map maker and object sanity must be at the top of the consensus wish list.
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.
Do you mean the governor alters the XP of troops stationed in the same city in which the Governor is stationed, or that a governor alters XP for all stationed troops in all of your empire's cities?
The former would require some new tags, while the latter may be able to be done with what we have.
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.
It would probably be easier for them just to create some new tags, rather than open current tags up to calculation.
Maybe something like this:
<GameModifier> <ModType>Unit</ModType> <Attribute>WhenStationedInCity</Attribute> <StrVal1>XPForAllStationedUnits</StrVal1> <Value>1</Value> <PerTurn>1</PerTurn></GameModifier>
This way they could also use the WhenStationedInCity Attribue to give Governor XP per turn.
<GameModifier> <ModType>Unit</ModType> <Attribute>WhenStationedInCity</Attribute> <StrVal1>UnitStat_Experience</StrVal1> <Value>1</Value> <PerTurn>1</PerTurn></GameModifier>
Anywho, just some random thoughts on the subject.
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.
'Easier' was probably a poor choice of word. And I know nothing about coding. All speculation here.
Any news on that? There's good modding stuff that requires this to work .
1. Ability to edit "Upgrade..." function. I would like to be able to add items/abilities/spells by "upgrading" an already created unit. Example: Mage School building that allows units to "upgrade" to learn "spell x". Upgrade is already a smooth, comfortable function, so expanding its uses could only be positive.
That is it at the moment. As a modder resource, I would like a guide which lists the limits of assigning an attribute to a value. For example, what can I give and not give to player, champion, unit, army, faction, etc. This would clear a lot up.
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.
If stardock is still reading this thread. I've just remembered something that I would like to see implemented, it would make my female henchmen mod more functional for everybody that uses it (I think it was rather popular). You have generic units to be designed in your editor, but only room for 3... could you allow for 1 more...
Currently you have
<GenericUnitType_Male><GenericUnitType_Female><GenericUnitType_Other>
I wouldn't mind seeing another available one like
<GenericUnitType_OtherA>
or something so I can allow people to design both henchmen and henchwomen.
I do understand that the UI may look out of sorts when adding another button (not enough room). So a mild fix there would be nice like a scroll bar if necessary. Just an idea and it would make me feel that I've finally finished adding female henchmen to the game.
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 am adding a new one:
Allow to use A_Additive_Resource tags in trained units. I know for sure that they don't work right now. However, they do work in champions.
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.
There are many great features available to you once you register, including:
Sign in or Create Account
