All entities are now considered, which is an improvement and enough to lift my concern :)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 21 2020
The design I have in mind is the following:
UnitAI chooses "cleverly" what the unit is doing, other components perform the tasks.
UnitAI should be allowed to let several components perform different tasks (i.e. unitAI could allow a unit to attack and walk at the same moment).
UnitAI can be replaced by BuildingAI, turretAI and whatnot, but all those should be able to access the same "other components" and let them perform the tasks (otherAI components just choose differently what tasks are done)
I think we have to accept the limited flexibility of tooltips for now. It's not like we support switching to a vertical writing system either, so I don't think we really need to think tooooo hard about ordering optional elements.
Fixing that would simply require a stronger translation system which we don't have right now.
In rP23680#42314, @Freagarach wrote:So now trees *are* considered?
In D2738#116283, @wraitii wrote:Are you referring to this concern: https://code.wildfiregames.com/rP22754#inline-3977 ?
Thanks for giving this another look ?
There are 3 types of information: number of builders, time remaining and speedup by extra worker. Currently the time remaining is on the front page, and the other two in the tooltip. IMO if we add the number of buildings to the front page, we should show all 3 in the tooltip (why would 1 piece of information be in 2 places otherwise?)
I like the idea of trying to make unitAI easier to reason about, and thanks for even trying this out :)
That being said, my initial reaction was "no, this isn' t it".
Then I wrote this review saying why, and now... Now I'm less sure. I think you do need to rework some of this, and I'd remove the timer & message thing from there for sure, at least for now.
I think this kind of stuff is something for cheats...
Great to see my work from #3786 continued :)
We don't really care about the CP of dead entities anyway (see L323). (Code introduced in rP21685.)
What is changed now is that there is no message sent that capture points have changed.
Typo fixed in rP23685
Further, the previous code had a bug: GAIA entities would be returned twice. See tests.
In D2177#116257, @elexis wrote:If the idea of the patch is to increase the nr 200 to a greater number, then the idea of the patch is correct, but it's time hasn't come yet if selecting many units is so slow that it delays the game (turn length time just for the selection).
Yeah I understand :) The idea of the patch was to make it a user choice, thus the idea is wrong, as you noticed :)
If the idea of the patch is to increase the nr 200 to a greater number, then the idea of the patch is correct, but it's time hasn't come yet if selecting many units is so slow that it delays the game (turn length time just for the selection).
Anything holding this back? It looks good and still applies cleanly :)
So now trees *are* considered?
Do the TODOs from the above comments.
- Check whether we are allowed to capture.
- Other inline by @Angen.
Thank you, @wraitii! I (gcc-10.1.1-1.fc32.x86_64) have just tried out your updated patch:
svn revert -R * svn up arc patch D2745 cd build/workspaces/ ./update-workspaces.sh -j7 cd gcc make -j7
and can confirm everything builds; the errors mentioned in https://wildfiregames.com/forum/index.php?/topic/28175-unable-to-build-0ad/ have all gone.
Afterwards I did the tests, no problems there:
[0ad]$ binaries/system/test Running cxxtest tests (336 tests)................................................................................................................................................................................................................................................................................................................................................OK! [0ad]$ binaries/system/pyrogenesis
Valid points ^^
- Rebased.
- Use TryMatchTargetSpeed from rP23682.
- Follow at an explicit range.
Thanks, I appreciate this!
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
Entities in a 1 vs. 1 won't cheer, because they're not in the IDLE state when the order to cheer is issued, thus discarding that order.
Updated version. This lets us support Serialize/Deserialize (as in components) on any user-defined JS object (including, of course, components).
The tooltip also states how much you speed up construction when adding another builder, so it *does* show two things?
Thanks for the review and commit @bb :)
- Engine.GetPlayerID() can change during the course of the game using the developer overlay "change player" option.
- Other hypothetical enabled properties could change arbitrarily.
May 20 2020
Note that valuemodifications are equally broken.
There was a bunch of discussion how to display it on the front page. Displaying both was proposed there too, and that seems a sane solution to me too. However to me it sounds odd to display 2 values on the front page and only 1 in the tooltip (the time left is not displayed), I rather have both in the tooltip then.
Successful build - Chance fights ever on the side of the prudent.
Merged inside D2745
Incorporate D2749
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
actually save file after renaming function
rebase and rename function
Successful build - Chance fights ever on the side of the prudent.
move variablesToSerialize to prototype to avoid global as we do not like globals, locale variable as it would be recreated by every serialisation call and declaration in Init as it would be recreated for every entity.
If it needs to be a breaking change anyway, why not to remove the whole logic for generating the actual password by hashing the username and password and instead just using the password as password? Wouldn't this result in the same logic as other XMPP clients use as well?
Successful build - Chance fights ever on the side of the prudent.
Missing dot fixed in rP23679.
Successful build - Chance fights ever on the side of the prudent.
This was a bit trickier than I thought.
Wait for learnings from D2662. (Oh and probably declassify, ought to be done separately if still desired.)
I have tested with different setups.
Successful build - Chance fights ever on the side of the prudent.
As for the front page/tooltip thing, I thing there was quite a discussion about that and thus both would be not bad? Better yet obviously is user choice, shall I make this a config option?
Swap position.
rP23678 can probably be used to fix this?
Successful build - Chance fights ever on the side of the prudent.
- Don't check for 0 speed (`Math.min(1/0, 1) == 1).
- Set SpeedMultiplier also when it would be set to 1 (don't assume people reset it).
Successful build - Chance fights ever on the side of the prudent.
Thanks for the review and commit @bb!
- Oneline new speed.
- Protect against /0.
First off, thank you for the patch! Don't hesitate to drop by on IRC if you have any questions.
I believe another instance of the FArchiveXML.h file should be updated. Requesting changes so it's not forgotten.
Edit: the below fixed by wik at https://wildfiregames.com/forum/index.php?/topic/28183-trunk23664-cant-open-atlas-editor-on-osx-catalina-10154/&tab=comments#comment-396649
somewhat. It's fixable anyways.