leper

https://trac.wildfiregames.com/wiki/Mod_Layout has the answers. Adding maps/scenarios.DELETED, maps/skirmishes.DELETED and maps/random.DELETED files (empty, though the content doesn't matter) to your mod should do what you want.

Not without code changes. Mostly just extending the xml schema, then checking for that in cmpAttack.PerformAttack's melee attack branch and calling cmpDamage.CauseSplashDamage if it exists (and with the right parameters).

Try the .js file.

binaries/data/mods/mod/gui/modmod/*. Patches welcome.

(The somewhat hacky solution that will just cause issues once you have to upgrade from A22 would be to change the order of the entries in g_DamageTypes in gui/common/tooltips.js) For 33. that will work for random maps and quite a few skirmish and scenario maps, though some of those specify the color explicitly. I might have a diff somewhere that removes a few of the explicitly set colors that are the same as the current default.

source/lib/sysdep/ might have some secrets. No clue how you ended up at some of those "results" though.

Components (which is why they are sometimes called cmpSomething) can either be C++ or JS (or C++ interface with JS implementation). So in that specific case you should be looking at files in source/simulation2/components/, specifically CCmpVisualActor.cpp. For some more information about components read up about entity-component systems (in general and [1] and then possibly the docs about how to write those (which are not only useful for that, but might also help understanding how to use them if you are looking for slightly more details). The rough idea I had (as a follow-up to D842) would be to reuse cmpPosition in cmpVisualActor's Update to get whether we are currently floating, and if yes switch to "swim" instead of "walk". Also note that changing C++ code will require a rebuild of the engine, see [3]. [1] https://trac.wildfiregames.com/wiki/SimulationArchitecture [2] https://svn.wildfiregames.com/docs/writing-components.html [3] https://trac.wildfiregames.com/wiki/BuildInstructions

https://code.wildfiregames.com/D864 for the flight path thing.

(Oh, how I like writing posts again because the forums have issues.) Now inside pre tags, interpret bbcode yourself, the forums apparently cannot. [quote] 2. Is there a way to change how quickly a specific projectile vanishes after it hits the ground? I have a few magic based attacks in the game that linger around on the ground too long after they hit. Some I need to vanish instantly like lightning bolts. [/quote] The delay is hardcoded in cmpProjectileManager (C++) currently, however you could pass an additional parameter from cmpAttack to cmpDamage's MissileHit and call RemoveProjectile there even if it was a miss. [quote] 3. Is there a way to control the flying arc of certain projectiles? Some of my magic based attacks should not be arching through the air like arrows. My lightning bolt attacks should fly in a straight line at targets. [/quote] Needs a small JS change in cmpAttack (and to the schema, and the templates that need a different gravity value) to allow passing a custom gravity value to LaunchProjectile. This would also allow things like mortars or ICBMs. [quote] 4. This was brought up earlier, but what file controls animation sets and definitions? The file that controls things like "Idle", "Walk", "Run", Attack_Ranged" etc. I can't seem to find any file that defines these and I'd like to create a swimming and spawning set for animations. [/quote] Available animations are defined in the actors. When those get used is handled by some intersection of cmpUnitAI and cmpVisualActor. [quote] 5. What file defines and controls damage types like Hack, Pierce, etc? I'd like to add a Magic damage type and resistance to. [/quote] cmpArmour and cmpAttack. Though neither of those is very nice to extend currently. That doesn't mean that you cannot extend it, but it is quite likely to require more work to maintain than should be needed.

(Maybe someone should move all the topics that are neither guides nor tutorials out of this forum.) Researched technologies apply to entities (or templates). That part of the code knows of no difference between units and structures (or other categories you might want to think about), as is true for most of the rest of the code. I'm not quite sure what you are asking, but if you want two (or anything that is greater than 1) entities with different available things you will need different templates for those. I guess you could either provide two different fortresses in the builder list, or provide only one that makes use of the upgrade component to change into the other (or into one of the specialized two).

No. See the TechModifications wiki page for a list of all possible things a technology can change. Modifying technologies or entity lists (that can e.g. be built) is both confusing to users and creates a lot of possibilities for hard to detect bugs and increases the complexity of the whole code. What you could do (which is a workaround if you consider modifying technologies something important) would be to provide autoresearch technologies that require both the defense tower tech they mimic (for siege towers) and the siege tower tech. That should have the exact same effect, without having to modify technologies. It does however increase the amount of technology files you have to create and maintain (since a change in the defense tower tech also requires you to update the siege tower tech).

Looks ugly just like the forums. What's the point of having washed out colours and low contrast text on something that is mainly about content only, and not about looking fancy? If we are going to change the theme for just one thing I'd vote for the forums.

https://code.wildfiregames.com/D842 should take care of the floating at a certain depth part. (No tickets, since others also didn't create any :P) About animations it should need a new anim (and names for those), and either using the animation overrides for the walk animation from JS (though we might have to check the current position a lot), or extend cmpUnitMotion to check if cmpPosition is actually floating at the moment (and maybe taking care that that check doesn't mess up the plane).

Right, this works for ships because those extend below ground, but for units that would need work. Care to open a ticket on trac for that? I suppose we should just add a floating depth so that units walk up to a certain depth and only then start floating at that depth. Making the animation differ if the unit swims shouldn't be to hard given that cmpVisualActor's Update already accesses cmpPosition. All of that is going to need C++ changes though, so you will have to start using the development version.

That error looks a lot like you are using http instead of https when doing a checkout. Also git users that don't know about git-svn...

So why didn't you apply in that thread (https://wildfiregames.com/forum/index.php?/topic/22476-open-position-social-media-manager/, probably not visible to people not part of the team)? We are currently evaluating one candidate, at least that's what I deduced from reading some posts. Not that that would prevent doing the same for other candidates (or possibly sharing the responsibility), though you might want some other opinions on that. Regarding your github issues post, and given that I tried replying to that twice (screw those forums) you are missing https://trac.wildfiregames.com/wiki/WikiFormatting and that Github uses pagination (and you not specifying a smaller value for trac), trac having custom fields and keywords ("tags"), and switching to be mostly an issue of trading some drawbacks against others. And now I do sort of hope that the forum doesn't eat this reply, since I'm not going to write something close to this again.

Regarding 25. just let both techs provide the same thing, then require that thing for some auto-researched tech that does the actual phasing. (You might want to look at tech files in both the public mod and a few other mods (or old versions of the public mod that did use that.)

<Position> <Floating>true</Floating> </Position> might also be useful.

It does appear like lightdm/SDDM/whatever starts dbus, while just using startx/xinit doesn't do that. And for some reason something (driver/library/etc) uses dbus, which runs into some issue.

You need to add a few lines to simulation/data/placeablesFilter.json. I do however dislike that we do have to explicitly specify most things there, so I guess we should change the code to either allow recursive inclusions, or invert the logic and only specify things (using wildcards) that should be excluded. I think I prefer the latter option. When saving there's two tabs "Scenarios" and "Skirmishes", select the latter and save.

The biggest trade gain is trading with an ally over a long distance (though you only get a part of the traded value at the ally's market). Cycles for traders are done in the wip code for the Silk Road map, however there is no gui support for creating such cycles.

But before anyone changes something to be wrong (assuming that we consider title case for buttons to be the correct thing) you should be aware that I only mentioned both of those because they are right next to each other.

That's just proper application of title case, and it seems most software products do use it for things similar to what we use those buttons for. If you want inconsistencies pointed out you might want to look at "Report a Bug" and "Translate the game" in that last image of yours.

All of this sounds a lot like what Collada was about a few years ago. If someone does all the work and thus allows us to drop that bundled FCollada (which we are "maintaining" in the sense that we try to not make it fall apart) that would most likely be appreciated, however the current state of support for that format seems a bit light right now.

Exept solving a different issue that doesn't apply in every detail doesn't help, but pointing that out seems to be nonsense. Ah well, I guess doing research first seems to be a strange way of operation, same as first asking questions instead of providing "complete" "solutions".