- User Since
- Jan 24 2017, 12:54 PM (261 w, 10 h)
Tue, Dec 28
rename elevationBonus => yOrigin
Add constants for NEVER_IN_RANGE and ALWAYS_IN_RANGE ranges
Mon, Dec 27
Thanks for the patch. Code looks good for me.
Sun, Dec 26
Another mapName fix
Dec 26 2021
some comment improvements
I thought only some let => consts were breaking my patch.
Why didn't that error out?
Dec 25 2021
code reads like being fixed. Didn't test
Lobby server only called for the list on login, and update (and on opening the board).
Front doesn't fall, seems correct.
Seems fixed. Notice that when leaving a game without resigning, the option to go to the summary is not there, which is good.
Oct 31 2021
I just pressed exit in the menu during the game (not at the end) as a client (so non-host) in an MP game. Obviously one should test the case too what happens at the end of the game for clients.
Happens when pressing exit as a MP client
Oct 19 2021
Actually what happens is supposed to happen: pressing ctrl (or better the noCapture hotkey) triggers the attack to prefer noCapture, while without the hotkey pressed it will prefer capture. Pressing the (no)projectile hotkeys results in preferring (no)capture. The Capture preference takes precedence over the (no)projectile. So if one attacks a building with the (no)projectile hotkey pressed, one prefers Capture and (no)projectile. However since there is no (no)projectile with capture effect in most cases, it will just default to capture. When pressing noCapture + (no)projectile it will try to do noCapture +(no)projecile which usually result in the damaging attack with(out) the projectile. The key is to realise that wanting capture and (no)projectile are independent properties.
That being said, this probably should end up in loading tips and hotkey descriptions.
Attempt to respond better on attacked. Should be tested (also remove a leftover "Melee" hardcoding)
Please Freagarach linting Ltd.
Oct 17 2021
Agreeing on the change. Lobby policies need date update and patch needs a rebase. But reconstructing the patch is easier.
also nulls in AI (instead of undefined)
more details: https://code.wildfiregames.com/D368#182749
Oct 12 2021
Works as advertised. Looks good (apart from a little rename I can do while committing)
The Ishtar Gate of Babylon has only one name and the name is always nicely centered.
XD I was testing stone mines... Works nevertheless
Sorry, I think my second idea was better. Using the getTextSize is good in many occasions, but not ideal here. Sorry to put you one the wrong hook here. From a user perspective the proposed patch seems to work.
Please don't introduce an OOS....
concern fixed by rP25914
Oct 10 2021
Thanks for the patch: here is some quick review, to help you improve the patch:
Oct 9 2021
The question in need of answering here is: do bridges need to be entities or are actors enough?
Oct 7 2021
Oct 6 2021
Works as advertised.
Oct 4 2021
Idea looks good from screenshots
Oct 2 2021
Fix an OOS on replay.
Make sure the arguments of some unused AI functions are correct.
Oct 1 2021
Add the acceleration in the gui and some more balancing (slightly easy the case for siege, but make elephants and catafalques a bit slower again (they were missed in last iteration))
Well that's the point, why we can't really use the messages. The sender of the message has no clue what the components will do with it. Also this message triggers the globalEntityRenames. So if we were still transferring data on the message, other entities might see a partially transferred ent (now I am not entirely sure of the order of the global vs local messages, but we shouldn't rely on that order in the first place). Also we simply don't know in which order the components are called. As we see some components depend on others, so we always will need to enforce some order.
Other findNearby functions already have a visibility check.
Ideally we did be reusing the gamesettings for this gamesetup too, that would fix any default. I guess we should be using the autostart gui page and the json we fill here through that. Feel free to investigate, certainly out of scope though.
Works as advertised
Sep 28 2021
Fix call-to-arms cursor
Even if unlikely not impossible. So we will be dependent on a few persons who have the code. Also this doesn't save all comments and discussions.
Why give away the sovereignty we have?
'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/
Phab will keep running as long as we keep it running on our servers. Also I saw there were efforts to fork it.
Also sovereignty is essentially kept per the first point.
The first point doesn't keep our sovereignty at all.
Sep 27 2021
How is this required to reduce the stress on the CI? Keeping 20-odd files in our svn repo won't hurt that much. If we want the bots to ignore these files, let them (though we have the bots for a reason so we better use them when we need to).
Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code? What if gitHub puts restrictions on what we do, do we then abide? Why give away the sovereignty we have? Why let the codebase fall apart, literally?
Now some third party CI might be free, probably many proper things we currently host ourselves are going to be expensive (now the SPI reports says we don't have to worry to much about our finances, I think we can spend our money better)
First reason is that while development of the lobby is linked, it actually lives its own life and evolves at a different pace and to my despair it's not actually completely versioned
Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.
We have files in our repo which haven't been touched in the last 10 years or so and files which are changed every month or so. That is completely fine. So if these files are developed evolve at a different pace: fine. What is the problem? I suppose during CF we shouldn't change the lobby bots either (if there are bugs with them, we need to lift CF for them: fine). Even the more reason to keep them in the same repo.
This is actually a good step towards the engine split.
Splitting the engine doesn't mean having several repo's. In fact we shouldn't have the engine in another repo than the vanilla game or anything else we develop related to 0ad. If we want to split stuff we need to work with directories within the repo: having a separate directory for tools like this within our repo is perfectly fine with me, storing it in source might indeed not be ideal.
Even if we need several repo's, we should host them ourselves.
There is no trac phabricator/instance
If you mean to track tickets/ make comments on pull requests you can do that too on Github.
So we as developers need to look at yet another place for patches, instead of keeping everything in one place.
Unlike all the other tools this one is actually used in production .
So are the translation scripts and probably others too.
You missed the intro.txt (see some ticket I recently created)
Sep 21 2021
In any code we are going to need two checks, so this is probably the cleanest way to dupe the call.
I would side with Stan that a getter should be named GetFoo(). Otherwise seems good and greps complete.
Improve the statusEffect handling (removes 2 todo's)
Front doesn't fall, no difference on my system
Sep 20 2021
Some balancing on the different units: make infantry and animals accelerate faster and ships and siege slower
I see two different cases, how we with the proposed code produce the error:
- A component on a mirage is queried which is not present in the parent. In this case, there is no problem at all, we should just return null.
- A component on a mirage is queried which is present on the parent but isn't fogged. Now there are some sub cases
- The mirage shouldn't have the component since the mirage isn't expected to have that component (e.g. a mirage doesn't shoot arrows so it doesn't have a buildingAI).
- The mirage shouldn't have the component since it has its own (e.g. selectable): we probably should be returning the mirage's own component then (having both a miraged and an own version sounds weird and buggy).
- It should have been fogged: if someone calls QueryMiragedInterface, the calling code will probably not function correctly or at least do something different than expected. Any proper review will check if the requested component is actually miraged if it should be. Since we cannot distinguish this case from the previous, we cannot really error in this case
I really only see one usecase of the other default: if there are no compatible mods available. However in that case it would be much better to write that instead of the list of available mods. Just write like No compatible mods available,. Try to disable some mods or download new mods online.
I see the issue, but don't like this solution (since "rating" says more about game type than player), nor I have a better solution.
Sep 19 2021
rename a file
All SendGetBoardList needed to be handled got handled.