wraitii

That I could agree with. I don't think 0 A.D. at the moment makes enough of a difference that it actually matters. There is a way to fix this with the setup we have, by giving different priorities to different sources, but it needs to be implemented. Given that it was a bug of the Health component however, I think these techs might have no difference between A23 and A24.

This is actually somewhat inaccurate, the order is: Template values Global (techs/global auras/other modifiers such cheats) If any 'replace' is present, it is picked. If multiple 'replace' are present, a random one is chosen. Otherwise, X * mult + additions. Note that the replace behaviour isn't changed from A23. Local modifiers & auras The main difference is that global auras now multiply and add alongside techs, instead of on top of them. I don't think this is obviously better or worse. In practice, since most auras are local, there should be limited difference with A23. It was buggy, and it's not even that it's not possible to revert to it but simply not desirable. I would legitimately disagree with you that modifiers, in general, should depend on the creator's civ. Cheat modifiers, for example, are obviously tied to a player. Techs are a bit of an annoying in-between where, for some of them, they're more like "stuff that should replace template values", and for others, they're more tied to the owner's civilisations. E.g. a better spear-point is probably something that should be carried over on capture, but better training is arguable, and stuff like higher gather rate is probably not carried-over. You focus on structure HP but that's actually about the only place where the A23 bug could be noticed, and to be honest I don't think it's that much of an issue, it's a pretty minor thing all in all. In my opinion, the current situation is very satisfactory. That being said, I agree that it would be nice to make "carry-over" techs possible, but that requires more thinking. This seems like a straightforward template fix. My take is that we went from a straight up bad situation (attacks being broken is horrible) to a not-great situation (ranges varying so much by building obstruction sizes isn't awesome). That being said, I think it's not such a huge concern: areas aren't a perfect metric either, because units are discrete things and you can't really "fill" an aura range with units, it's not how things work. So, I would argue, for most cases, the distance remains rather relevant since it's what will matter for "how long until unit X is in range of Y", and for battlefield tactics I also think you'll find the actual advantage not as big as the maths say. -- In my opinion, though I acknowledge the concerns, none of what you raise here are large enough issues that they must be fixed for Alpha 24.

I have an interest in this, which ought to be obvious given I started this topic in the first place I've not found the time to work on this in ages, but it's something I'm seriously considering for the future, because I very much dislike our current presentation.

I think this is a visual thing, movement remains rather faster in formation. That being said, I think increasing the formation controller turn-rate makes this look much better, so I'll do that.

Yeah that's what I was describing above, it's because the controller rotates and we have pretty bad handling of rotating formations. I'm afraid it's essentially unfixable at the moment, and the movement is still working (maybe even better than with an individual order), so I'm going to call that a "won't fix" for now, unfortunately. You can, if you want, de-activate the default formation feature on those maps.

Can you be a bit more descriptive? Testing right now, it doesn't look great because the formation rotates un-naturally, but it's functional enough. For these maps, you can de-activate the default-formation manually anyways. Mh, that's a good point that I didn't think of. It's unfortunately not that easy because it needs to be synchronised for MP play, I'll see if I can do something not too tortuous.

Hello everyone, This message to inform you that I have merged in SVN the 'default formation' patch, which is a rather substantial behaviour change, though it can be de-activated. In Alpha 23 you have to put units explicitly in formation. In SVN and A24, units will now go into the 'default formation' when walking, and will act as individual when given orders like 'gather' or 'repair'. This is intended to leverage formations for movement, but to avoid issues with specific orders where formations make less sense. The "box" formation is the default. You can change this in your config file, and by right-clicking on a formation icon in-game. If you want, you can deactivate this entirely and go back to A23-like behaviour by choosing the 'no formation' as a default. Modders, you can easily chance which orders get which formation by changing the calls to g_AutoFormation. Since this is all GUI-only, you can mod it locally and still play games with unmodded players, too. Hope you enjoy playing, Wraitii

K, this is starting to make no sense Can you confirm that you've checked: - Your binaries/data/mods folders don't contain the mentioned files (if you're using git, they might be there but not noticed) - Your user mod folders don't contain the mentioned files - The mods you've activated (possibly start with the command line 'mod=public') - You've cleared the cache after checking the above

There is no "gui/gamesetup/Pages/MapBrowserPage/GridBrowser.js" file in the public mod, so there must be something going wrong. Could be the cache.

This is pretty much Rise of Nations. Certainly an interesting idea. _big_ departure from AoE-like gameplay we have right now though. I don't think we'll look into those large gameplay changes short-short term, as it feels to me there's still a bunch of engine work to be done. That being said, the time approaches (on my end anyways). --- Anyways, I'd say the thing I think we mostly need to fix is this...

That someone is me, in fact. 'Requires' specifies level identifiers that are needed to unlock the next mission. So if you have one level that requires two missions, you would write ["mission_a", "mission_b"] instead.

I'm assuming using DE? I moved the grid-browser files from gamesetup to maps/, so you probably have duplicate files now. I think you can just check the diff, let me know if you have trouble.

You should probably wait until I merge D3243, which will make it much easier to change the gamesetup GUI. However, I'll probably not do it in the days to come as it's likely to introduce a few bugs in situations I've missed.

Are you talking about the "virtual" foundation that doesn't block movement? That's in "construction.xml", not foundation.xml

It also happens that the windows auto build was not working these past few days, unfortunately. Anyways, yes, it's something to watch for until we find a better way.

That's https://bugzilla.mozilla.org/show_bug.cgi?id=1644600 Seems the diff is a little buggy then. I'm afraid the system-mozjs won't work on your distribution unless you ask them to patch https://bugzilla.mozilla.org/show_bug.cgi?id=1644600

Thanks for the complete report It seems you were not actually playing on the same revision, because I'm seeing different serialized data as if one of you was playing without rP24429. I think what might have happened is that one was using the GitHub mirror and the other SVN? The GitHub mirror is unfortunately only update every morning, so it sometimes lacks some commits.

@ValihrAnt Would you be able to provide your own los dump? On its own, a single file isn't very helpful. @badosu Can you post the replay also?

To be honest, just switching to a table-like structure would really help. Need someone to get around to actually doing it Feel free to try and make a patch for it!

You must have an "objdump" or "llvm-objdump" program. Possibly LLVM's, possibly something compatible. I'm interested if you can find out more.

I indeed totally missed that 'construction previews' weren't local entities... Thanks for reporting this, it'll be fixed shortly.

No I leave INCLUDE_SOURCE 0 as in SVN

And after a long month of upgrades, I have at last merged SM78 ! 0 A.D. now uses the latest "Stable" Spidermonkey release. The next one will be SM94, I believe, which won't come for a little while still. This version requires "LLVM-objdump" to compile. You will probably need to install LLVM binaries, if you're compiling using GCC (if you're using clang, you probably already have it). Depending on your distro, this could be a in various packages. If you can, update the https://trac.wildfiregames.com/wiki/BuildInstructions with the correct instructions As usual, use this thread to report issues. ---- NB: we know that there is an issue with GCC 7.5. Fixes include upgrading to GCC 8 or applying D3181 from Phabricator.

Are you setting "INCLUDE_SOURCE 1" ? Because if so you shouldn't.

Mh, you're probably correct on that, though the name is not the most important. The distance is still a circle as we approximate range checks for auras, it's just "diagonal size of the obstruction + aura range" instead of "aura range". So yeah, you might need a radius close to 0 for passable obstructions (in fact, it's possible we might want to look at negative aura ranges). I'm going to make a diff adjusting SVN auras, I don't think it'd be too practical at the moment to treat auras specially, but you'll likely have to adjust your ranges to account for "√(width^2 + depth^2)"