For those of you who aren experienced modders, much of which follows is just preaching to the choir. But for those of you new to modding, you may find this useful..
As some of you know, FE development was led by modders. Derek Paxton and Jon Shafer are best known for their Civ 4 mods (Fall From Heaven in Derek's case). As for myself, I got my modding start with Civ 1, MOM, Total Annihilation, and so on. My love of Civilization 1 ultimately led to writing Galactic Civilizations.
And this brings me to the frustrating part of modding: the limited lifespan of the mod. I eventually got to know Total Annihilation so well that had they made a Total Annihilation 2 with a derivative of their original engine I'd been already set up to do crazy cool stuff. But that didn't happen (and don't talk to me about TA:K).
So our approach has been to approach Elemental from the perspective of it being a platform that mods can be built with for years to come. Many of the mods that worked with War of Magic work, with slight changes, with FE. That's because WOM and FE are built on the same platform which we call Kumquat.
Kumquat is a relatively new engine and we have land-based strategy games scheduled to use it and upgraded versions of it for the next several years -- and not just Elemental universe games. So the skills and understandings of what you get from modding FE will lend itself to more modding.
We also plan to support both Nexus Mods and the Steam workshop as we go forward in ways that make what we have today seem very primitive.
The point being, the age old issues of short-lifespan mods is something we are hoping Kumquat addresses. We looked at Kumquat as a platform that modders can use to create increasingly ambitious mods. I can't promise source code or scripting support yet. Resources are tight, but we will be supporting this underlying platform and the expansion of its capabilities until *at least* 2017.
If you played WOM in 2010, consider what FE is like in 2012. Now, consider what Kumquat will be like in 2014.
When this becomes a reality I will probably get a bit more active on the XML end again. Right now I am content to work on things the patches do not affect until we can quit modding the core directory (technically you can do this for most things now with a LOT of work) or the patches slow down.
Like tiles!
I found those who help them selves are more likely to do something cool with the information you give them. I run a modding site and I have rule on it "no time wasters" because I often find my self in that exact same position and waste days or weeks helping people that are unable or unwilling to take any steps for them selves. In the end I either make their mod for them, or they do not make it at all.
You have to be crewl to be kind, and just tell them straight they are never going to make anything and should give up.
Those who try usually post a lot more info and its easy to tell they have tried and failed and easy to point them in the right direction too. Even if they are completely lost, the fact they have tried is enough to prove they are worth helping.
The problem I've been running into is that if I, say, replace the factions or something (key word: replace) and put that XML in the mods, they don't necessarily get picked up. The way it should work is that anything you put in the mods directory would replace any objects that are in the main directory IF use mods is on.
I consider that a bug.
Aye! Get out yer whip and get 'em to fixer up *please*
After turkey haha!
I agree that FE needs a scripting language, in addition to the xml. We have 4 levels of modding- editors, xmls, scripting, and basic languages. Each take more work/knowledge, but can produce better results, with the basic language producing the game itself. While it's expected that 90% of the work will be invested in the editors and xmls, sometimes (due to bugs, or "bad" game design for the mod, unavailable ) a modder will need to bypass that, using the scripting.
Looking ahead, FE modding will die relatively fast without modding, simply because the platform will not allow change. Making a different game (such FFH compared to civ) will be quite hard.
That being said, FE is still a very good platform for fantasy based mods, and good job with that.
Welcome to my world. The problem with the starting positions is most likely because you have hit save or created a blank new map. You get one shot on your first map to place tile modifiers like start poistion/blockable etc and have the graphic appear on the map in cartographer. That is one of the tertiary problem of it not refreshing/reloading assets.
Rivers are their own can of worms I would just play with the river tool, alot. There are serious problems if you want to create really long rivers it breaks down after 10-15 and places wrong bends, ends/starts, etc. You can manually edit but remember to reload the client after you modify a file outside the client.
Whatever the function is that runs on the client_startup event that reads the files from the mod directory into memory needs to either
a ) Be called on all asset creation and save events
b ) Place a button in all the editors called "reload assets" or "reload mod directory"
c ) both
*above here is the reason for the quote I think that would fix your problem and a whole ton of other problems. The rest are the things I would fix next, Note I have not really used particle forge.
Next step should be to add undo functionality with a reasonable buffer with a button in each editor and hotkeyed to the standard ctrl-z, a droper/copy and paste function would be really nice as well. Actually lets just say required since if you are looking at a canned asset, like a goodie hut, and wnat to find a particular object looking it up is a nightmare we need dropper/copy.
Cartographer needs
1) The wand tool will only select a landmass for stamp save appx 1 time in 15. You right click-deselect left click with the wand for another attempt and you will either get a stamp saveable land mass, all other tiles except the landmass highlighted, a CTD.
2) Rivers above 10-15 tiles in length will start to choose the wrong river segment.
3) Removing a river creates a black tile effect that removes the river but leaves the tile marked as a river tile and trying to rerun the river over those tiles will cause the wrong segment problem, saving the map with the overwritten old river tile causes malformed xml.
4) Starting position, blocked tile, and other tile markers will not show after you have saved a map or opened a new map, nor will it save to the xml (although I believe it will show the tiles status in the tooltip while not displaying the letter marker, like the S for the start position), you basically get one shot when you first open cartographer to use the tool to place these modifiers to see them on the map and have it save the information to the xml correctly.
5) Stamps/maps/tile modifiers and especially goodie huts need some sortability. Right now finding an asset is a process of sorting through extremely long lists with default orders that make no sense.
6) Stamp save options are meaningless. Every canned stamped is saved with the "place on any tile" and the stamp size. As far as I can tell the other 20 or so options are depricated, and totally confusing, esepecially since in the XML this is saved as a "Rules" number and not a named element wiith a value that is human readable.
That's why I could never get it to work. Damn infuriating is what this is. When making a map, you kinda expect to be able to reposition certain things... well all things really. I couldn't get a start position to ever get placed, at all. After becoming aggravated, I saved it with random starting points thinking I could at least edit them after they were randomly placed, and nope. Couldn't move them whatsoever.
I also grew frustrated and irritated with a few other quirky behaviours, threw up my hands in frustration, and moved on. I've used a lot of map editors/makers throughout the years, and this is one of the most irritating/frustrating/aggravating ones.
I was interested in trying, so I threw one together too -- spears that deal fire damage over three turns with a fire attack scalable to unit size. It's doable it seems.
I'm guessing the reason Werewindlefr's head almost exploded is because they didn't want it to be a special ability. There's a huge difference, after all, between just rightclicking someone or having to fiddle around with a special skill. It might sound like a small thing but if you have 5-10 units that you have to repeat the process for in every battle it gets tiresome. Not to mention the unknowable - how the AI would handle it.
No special ability, it just works with the strike. I'm not trying to be an ass, it's doable.
Could you post your code? The problem we are having is specifically with ranged attacks, which are in contention for buggiest function of the year come awards night. MeleeAppliesSpell does not work on ranged attacks. A melee unit is a whole different can of worms. But maybe you found a way around it? And are you talking about caster unit size or target's unit size. We of course want the caster for this.
The upshot is we want a fire staff to do a poison like damage we would call burning. But you can't get the spell to recognize any other number than 1 for the caster's size. Eventually we gave up because it culminated in a week of failed modding and some demoralization. The next week we were able to mod the entire magic tree for Gilden in less time. On a cost/benefit assessment, it makes more sense to resign staff attacks to a very narrow function and get some greater faction diversity. IMO, adding elements to the strategic level is twice as important as tactical. It actually will affect both sides and really we have a near perfect combat balance, if not the full variety we wish to create.
With spears, it's easy, and I have made many cool melee triggerd abilities. However, I said staves. As in ranged weapons. And it doesn't work since there is no meleeappliesspell equivalent and 'ranged attacks' abilities don't work that way.
I agree with you there.
Sure, I'll be happy to post. I only found a solution for melee, not ranged. I did use MeleeAppliesSpell and just multiplied the defendable damage by TroopCount -- a workaround, but it does scale with troop size. Seeing the effects can be difficult, because it didn't seem onsey-twosey ratings were really cutting it -- that's why I have the x5 multipliers all over the place. A good alternative to a hard number could be a UnitLevel multiplier of some kind.
<SpellDef InternalName="Burning_Additive"> <DisplayName>Poisoned</DisplayName> <Description>Unit takes x Fire damage per round for three rounds</Description> <FormattedDescription>Unit will attack with %d fire damage for 3 turns.</FormattedDescription> ... <IsCastable>0</IsCastable> <GameModifier> <ModType>Unit</ModType> <Attribute>DefendableDamage</Attribute> <AttackStat>UnitStat_Attack_Fire</AttackStat> <Duration>3</Duration> <Effect>T_BurningHands_Particle</Effect> <SoundFX>Spell_Fireball_01</SoundFX> <PerTurn>1</PerTurn> <IsForFormattedDescription>1</IsForFormattedDescription> <Calculate InternalName="Calc" ValueOwner="CastingUnit"> <Expression><![CDATA[[Unit_GetTroopCount] * 5]]></Expression> </Calculate> <Calculate InternalName="Value"> <Expression><![CDATA[[Calc] * 5]]></Expression> </Calculate> <Calculate InternalName="ValueForFormattedDescription" ValueOwner="CastingUnit"> <Expression><![CDATA[[Calc] * 5]]></Expression> </Calculate> </GameModifier> <AIData AIPersonality="AI_General"> <AIPriority>5</AIPriority> </AIData> <HitSoundFX>Spell_Fireball_01</HitSoundFX> <HitSoundFX>Spell_Fireball_01</HitSoundFX> </SpellDef>
I don't think there's anything else I need to post -- the rest is just weapon and item defs.
As for ranged weapons... I'd like to give it a shot, but I see the limitations you mention.
Oh, I gotcha -- I was under the impression you wanted to melee strike with staves.
No, I want spells and activated abilities that scale with the number of units in the group, and nothing else. And in FE, it's impossible.
You're quite right.
I'm just wondering, since I didn't test it myself-
Is it possible to add group size a set variables? So a group of 1 will have a=1, group of 4 will have a,b,c,d=1.
Then, make the ability call a number of gamemodifier, each with the damage*N. If N=0, it has no effect.
In practice we will have 8 (or according to max group size)-
gamemodifier*a
gamemodifier*b
gamemodifier*c
gamemodifier*d
Each with the chance to hit, miss, crit, fizzle, just as if we did this with propper scripting.
I've never tried it, but it's an idea worth looking into.
There are many great features available to you once you register, including:
Sign in or Create Account
