- User Since
- Jan 24 2017, 12:54 PM (246 w, 4 d)
Tue, Oct 12
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
Sun, Oct 10
Thanks for the patch: here is some quick review, to help you improve the patch:
Sat, Oct 9
The question in need of answering here is: do bridges need to be entities or are actors enough?
Thu, Oct 7
Wed, Oct 6
Works as advertised.
Mon, Oct 4
Idea looks good from screenshots
Sat, Oct 2
Fix an OOS on replay.
Make sure the arguments of some unused AI functions are correct.
Fri, Oct 1
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
Tue, Sep 28
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.
Mon, Sep 27
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)
Tue, Sep 21
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
Mon, Sep 20
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.
Sun, Sep 19
rename a file
All SendGetBoardList needed to be handled got handled.
Sat, Sep 18
Improve the buildingAI situation
Fri, Sep 17
Sep 16 2021
Sep 14 2021
An icon would be used to place on top of the productionQueue items (both in the bottom menu as well as the right hand side of the screen for techs), indicating that the tech is being paused.
Code looks good. String looks good.
Regarding the Leaderboard discussion: notice that the current proposal only requests the leaderboard when opening the lobby. So the traffic is limited to once per session.
Sep 13 2021
The playerlist is changing all the time due to ppl going on and offline. Saving doesn't make sense
I guess unduping the list is required if we ever have the "autocomplete more names" feature.
Sep 11 2021
didn't find more usecases in the vicinity.
Sep 10 2021
I suppose we should set the "center" default to the ModernInput, so that all input fields can benefit.
Was thinking about upgrades but D2652.
A few of the descriptions end with a period. IMO all of them should.
However when the mirage is unmiraged the order is still the parent (which is bad),
I don't think so: when a mirage is unmiraged there is an onEntityRenamed message send, which will change the order in unitAI, so the order should be set correctly in that route. However if a unit is attacking a target which becomes miraged by another entity (i.e. its mirage) then the unit will keep attacking the parent (i.e. the original target). This will probably be very hard to fix.
Sep 9 2021
Tests run correctly, don't see a significant slowdown. Reads correct and complete.
For the fun of it we could add GenericName=Real-Time Strategy Game too
Sounds like a great addition. Now I am not so sure if doing this on the cart houses is good gameplay wise (it renders the up pretty useless if one first loses pop to get a little more, s one won;t need to have more houses to start). I would more see a usecase in towers losing there arrows during upgrade.
grepping playernameText.caption (case insensitive) yields no more instances
Don't align the history filter
Sep 8 2021
While I agree the duplication is bad, making a class from which to inherit comes with another problem: the this.chatFoo and this.chatFooCaption are different in each. Now one can unify this by storing the data under (the non-descriptive but general) this.chatObject and this.chatObjectCaption for all of them and and use that in the common class. But this will mean in the common class, will be using data which is not initialized in that common class. So the common class can only work if it is inherited by something. This sounds even worse. Passing the guiObjects as arguments denies the purpose of the common class (since we need to get the object) and will mean moving guiObjects around in the js, which I am not in favor either.
ssshh, we were working on that, everything on it own time ;) (but yes we should be adding a text_valign option (text_align too but out of scope))
Sep 7 2021
Front doesn;t fall.
Use a GetTextWidth approach instead
Exclude year only change
Notice that this script does NOT apply changes per line, it checks if there is at least one relevant change in the file and then updates the entire file.
Leaving the translator nick is, shouldn't be a problem. We handle them (considering GDPR) the same as any other contributing (not sure if we have the required PP written out, but whatever, we claim legitimate interest do we?). Keeping the year of contributions isn't a problem AFAIK.