Leaderboard

hi people, you are going off topic again, please stick to the topic

As you probably know A24 has been in development for over two years and thousands of revisions have been committed. Rumour has it it is nearing completion, which is great! Numerous things have been improved and releasing for a wider audience is certainly welcome. However, some mechanics are fundamentally different in A24 than they were in A23. Things I'm most concerned about: Firstly, the way technology modifications are applied. Technologies (and civ bonuses) are supposed to be permanent, auras (and team bonuses) temporary. In A23 the order in which modifications were applied (@fatherbushido) was: template values technology replaces technology multiplications technology additions aura replaces aura multiplications aura additions In A24 this is changed to (@wraitii, please correct me if I'm mistaken): template values technology and aura replaces technology and aura multiplications technology and aura additions To me, the old order made a lot more sense than the new. Moreover, things are fundamentally different for captured entities (as spotted by @Freagarach). As you may know, civic centres have 3000 health by default; brit and gaul structures have −20% wood cost, build time, and health; athen, mace, spart structures have +10% health. In A23, if you're playing athen and capture a brit centre, it still has 2400 health when it's your brit centre. In A24, on the other hand, a brit centre has 2400 health before it's captured, but 3300 health after it's captured by athen—and vice versa: an athen centre captured by brit immediately jumps from 3300 health to 2400. This is really counterintuitive. Modifications ought to depend on the entity's civ, not the owner's civ. When an entity's ownership changes, it should keep the values it had before. Now I was told the A23 code was buggy and it's no longer possible to revert to it. That may be true, but the current situation is not satisfactory either. Secondly, range computations have changed too. In A23, all ranges were computed from the entity's centre. Because structures have much higher footprints than soldiers, this meant archers could easily hit structures with the same attack range, without those able to shoot back, which was certainly undesirable. To address that, attack and aura ranges are now calculated from the circle around the entity's obstruction (i.e. increased by the obstruction radius). However, territory influence and vision ranges are still calculated from the centre, which means a centre's attack range of 70 actually extends beyond its vision of 90. Furthermore, structures tend to have footprints slightly larger than their obstruction sizes. Because footprints can be circular but obstructions are always rectangular, this means that for rectangular structures the obstruction radius is smaller than the footprint radius (as it should be), but for circular structures (e.g. brit fortress), the obstruction radius is in practice larger than its footprint radius, which is wrong, and means higher minimum and maximum ranges. Moreover, auras affect all relevant entities, so what matters is the area covered, not merely the distance (unlike attacks). The new calculation method (from the obstruction radius instead of the centre) means that a small difference in the obstruction size can easily result in a difference in free aura area much larger than the total obstruction size. Again, these are the things I'm most concerned about. Other people may see different things. If you spot something else in the development version that seems fundamentally wrong (compared to A23), please post here too.

I actually like the HUD being centered. It keeps all the info I need right there in the middle of the screen. I felt some eye strain shifting my eyes from corner to corner with the edited versions.

That's not to say there won't be midweek games ever again, but it was hectic this week with a full house. I managed to work it to have three whole weeks off over the Christmas period, the final week - this week just gone I was supposed to be on my own, and would have done commentaries for about the next four weeks plus a tutorial and two Mods videos. Instead, I have my son staying with for all of the lockdown, likewise my partner, my washing machine died and spent the week trying to relentlessly flood my kitchen - and next week I've got to find out how working from home and simultaneous home schooling of a ten year old works!!!!!!!!!! But there should always be some Sunday content, promise

I'm pretty sure I wrote a patch for that earlier in this thread, or perhaps in another thread. IMO it's definitely a better way forward. Show information that's relevant contextually, not just 'show information'.

That skeleton xd

I like new farming with more animals in A24

I like where this is going. It would certainly improve familiarity for JavaScript developers if we use a more common unit test framework rather than something in-house. I would suggest a few alterations so as to increase the value of the unit test: Run it from the command-line rather than from a browser. This will make it easier to run from Jenkins and extract the results in an automated fashion, and it'll be easier that way for developers to continue to (also) run it as part of "make test". The actual code is not meant to be run inside a web browser, which means trying to make it work there including file tracking and loader mechanisms, would significantly limit future developments and add on-going costs, without actually benefiting the game or code quality in any way. There's also the risk of false positives from tests passing inside a browser, but not in the actual game due to differences in environment. Run it using the SpiderMonkey engine (the mozjs engine that 0AD uses) and not V8, Chrome, or Node.js. There are significant differences in how these engines work internally, also with regards to syntax features and quirks etc. There is no need to run it in a different engine, that's kind of like testing a Firefox extension inside Internet Explorer. I believe a unit test is a test where you control (or inject) any and all dependencies and only act and observe a single subject (e.g. a class, module, or method). Thus not causing side-effects in global state elsewhere, and not causing dependencies to be implicitly pulled in. An integration test is where e.g. you act on and observe multiple subjects, and where e.g. you may let your application's entry point implicitly construct its dependencies and inject them, rather than doing so implicitly. In complex code bases, to achieve this, we often mock the dependencies and/or not load the primary engine, but to me this is by no means a logical requirement for something to be considered a unit test. When testing a Library class, it seems perfectly valid to me to test that by injecting an array of (stateless) Book objects into its constructor, and then only calling Library methods and observing its return behaviours. If Book is not stateless or if Book is difficult to instantiate, then it may be easier to mock it, but otherwise that would needlessly reduce the accuracy of the unit test. Likewise, I don't see an issue with exposing the Pyrogenesis engine to the unit test. Its native methods are conceptually no different from the native methods of the JavaScript runtime's own utility methods, so long as we use them within the spirit of a unit test. Beyond that, duplicating a lot of code would be busy work with little to no added value, unless for some reason we can't figure out how to load the engine, in which case we'd take on that added cost as a way to make unit tests possible at all. I think it's quite feasible to pull this off. We can decouple the current test target, and load a test framework like Jasmine there. We can also add code coverage reports by instrumenting the code first through Instanbul, and extracting data afterward. Then after the run we can use Node.js tooling to produce nice web pages as build artefact to visualise the code coverage reports. We can make compiling and importing the Pyrogenesis engine optional, so that we have a fast "make" target for unit tests, and a slower one for integration tests, but otherwise use the same JS engine, test framework, and code coverage pipeline. I'll try to put together a proof-of-concept over the next couple weeks to show what I have in mind.

More 4v4 action to feast on! Happy Sunday!

I believe this would be negated somewhat if template values were used for these things instead of "cleaner" auto-researched techs.

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.

@Angen wrote a patch to allow changing it from within the game: https://code.wildfiregames.com/D3037 It probably could use @bb_'s graphics options clean up: https://code.wildfiregames.com/D3034 And some small gui patches I wrote and would appreciate feedback on: https://code.wildfiregames.com/D2247 https://code.wildfiregames.com/D2568 https://code.wildfiregames.com/D2985 https://code.wildfiregames.com/D3268 https://code.wildfiregames.com/D3295 https://code.wildfiregames.com/D3311

SHOOT ME NOW

@Boudica and @JC (naval supremacist): If you want to have an argument with basically only you two involved I suggest you do so in a private conversation rather then to flood a thread with off-topic and insulting posts. And if you don't ... just don't

I was talk years ago with Micheal in a topic, we can follow the path of Forgotten Team

The migration has been finished; the new dedicated server is in use for all our online services. The old server will be cancelled on the 13th of January (first possible date). I'll securely wipe the harddisks before that date.