- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 15 2022
May 14 2022
Thinking some more about this, maybe we'll want the Engine to pass a writable Engine.entryPoint attribute that we set the init() functions to, as a way of expliciting the hardcoding?
I have non-exhaustively tested this and LGTM.
Assuming that we are sticking to the levels, I can see how this has some consistent logic. So that you need a damage receiver to receive damage in the same way as if you have no health component you also can't get your health reduced or as already mentioned, that you only can gather resources from something that actually has a resource supply component.
But I don't have a strong opinion tbh.
In D4575#197726, @wraitii wrote:
- If used in the GUI, we'll need to do some work to expose the init function, unless we have a non-module file to describe page entry points. Something like import { init } from './HotkeysPage.mjs'; globalThis.init = init; works, but it's kind of ugly.
Successful build - Chance fights ever on the side of the prudent.
Tested this quickly today:
- The '.mjs' syntax might be useful to differentiate in the engine. So maybe let's keep that.
- If used in the GUI, we'll need to do some work to expose the init function, unless we have a non-module file to describe page entry points. Something like import { init } from './HotkeysPage.mjs'; globalThis.init = init; works, but it's kind of ugly.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Not useful for PetraAI.
Fix last comments.
Successful build - Chance fights ever on the side of the prudent.
Build failure - The Moirai have given mortals hearts that can endure.
Change #elifdef to #elif defined()
May 13 2022
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.
This is included in D4607 & seems to bug for other people as well (see phosit on IRC today). I think it might be a Python 3.10 thing instead of a mac thing.
Reworked using an upstream patch of mine (but largely the same fixes). Tested to work on my mac.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Minor bug fix
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Addressed the reviews, implemented a very rudimentary "back to normal" mode
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
formatting whitespace, change some let to const.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Default arguments for EjectOrKill, removed VIM from .gitignore
May 12 2022
Test results from Mentula on #0ad-dev with the patch: https://paste.gnome.org/KNeEYmHZZ
and bevore the patch:
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Fixed warnings arc lint didn't show me locally
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Addressed all reviews, except implemeting a rudimental "Back-to-normal"-Mode and the question where to store it
One thing, I think this lacks is recovering, we stay in the emergency state forever, even if we'd win.
One thing, I think this lacks is recovering, we stay in the emergency state forever, even if we'd win.
Something like if we're back to ~75% of the previous population the emergency is lifted?
Maybe?
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
generated with git diff -U9999 instead of git diff --no-prefix -U9999
I don't know what Vulcan is trying to tell me here.
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
Diff has context now.
renamed attacker and attackerOwner parameters to changeSource and changeSourceOwner in Health.RegisterHealthChanged and throughout GarisonHolder.
May 11 2022
Nothing obvious remains as far as I can see.
Potential optimization to the event listener?
git diff --no-prefix -U9999
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Raise error, handle errors in the C++ (fail to autostart)
In D4575#197572, @wraitii wrote:Do you have something specific in mind as to not really interchangeable?? I think they generally are.
In D4575#197559, @smiley wrote:Either /, ./ or ../ at the start I guess. None of those would mean start at the current directory.
In general I'd rather not have a leading / unless it's necessary for disambiguating. In frontend development, absolute paths usually refer to node_modules and the root source directory is aliased to something (I think @ is most common).
However, we don't have node_modules and likely never will, and C++ vfsPath just start at the VFS root in general. I think it makes sense to have three types of paths:
- Absolute paths (from VFS root), no specific syntax.
- Paths that start with ./, which are relative paths.
- Paths that start with ../ any number of time, which are also relative paths.
For the record -> This is intended as a temporary fix that nevertheless won't result in massive technical debt if it remains like that for the next 15 years, which I think is somewhat likely given that despite several tries, nobody's found a much better way yet.
(This adds a proxy to cmpTemplateManager, it doesn't keep a static local template loader. But I do agree with the sentiment that globalscripts shouldn't have to rely on such details. Passing around a function not guaranteed to return the same output is also somewhat meh to be honest, cmpTemplateManager.GetTemplate shouldn't have to mirror TemplateLoader.GetTemplate for things to work.)
[16:38:28] <elexis> try this
[16:38:28] <elexis> 1. revert 26867
[16:38:28] <elexis> 2. add an argument GetTemplate to loadCivFiles and replace Engine.GetTemplate by GetTemplate
[16:38:28] <elexis> 3. pass Engine.GetTemplate in all calls, except the one call in the simulation scripts (survival of the fittest triggers)
[16:38:33] <elexis> minus the question
[16:39:10] <elexis> 4. in survival of the fittest you pass Engine.QueryInterface(SYSTEM_ENTITY, IID_TemplateManager).GetTemplate
[16:40:09] <elexis> alternatively you could also delete the entire TemplateManager component
[16:41:05] <elexis> also notice that still means nonvisual autostart needs a TemplateLoader, so the better approach is actually using if (Engine.GetTemplate) around that const template = Engine.GetTemplate("special/players/" + data.Code); block
[16:41:06] <Freagarach> Well, it validates templates.
[16:41:30] <elexis> Engine.GetTemplate doesnt?
[16:41:38] <Freagarach> Nay.
[16:42:01] <elexis> Gamesettings code doesnt use the civ data you inserted at all
[16:42:11] <elexis> from what I see survival of the fittest doesnt either
[16:42:26] <elexis> so these functions could just skip that Engine.GetTemplate call if Engine.GetTemplate isnt defined
[16:42:44] <elexis> also it seems that this data should not used by simulation or gamesettings (nonvisual) in any case
[16:43:20] <elexis> so thats a oneline JS fix instead of making a second template loader hidden inside a static local
[16:43:51] <elexis> and he is going to introduce another local static template loader for the nonvisual autostart patch that is not needed
[16:44:44] <elexis> so those are quick fixes, I dont know if its good to have that JS function combine the data of two files, or if it wouldnt be better to have it separated into nonvisual and visual data in two files.
[16:45:04] <elexis> (and loaded by two different calls)
[16:45:47] <elexis> (also dont know if it wouldnt be reasonable to just drop JSON at all instead of having XML here then sprinkling some JSON over there and switch back and forth all the time)Won't be possible to resolve files outside of the VFS, when you meant Won't be possible to resolve files like 'gui/something.js'
Reads correct.
Tests can be expanded (by testing _something_ between 0 and Math.PI) but are okay for now.
Its usually unlikely that modules would have to resolve anything outside of their root. However, that doesn't seem to hold true with the structure in gui/ though. Then there is the case of trying to import code from globalscripts. Which would be somewhat messy without absolute paths.
In D4575#197178, @wraitii wrote:In D4575#195007, @smiley wrote:Notice that it won't be possible to resolve out of VFS root.
Definitely the only sane move.
Read-through review:
- I think we should use .js over .mjs in the interest of tooling support, and I'm not convinced that .mjs will actually take off.
- There's a bunch of duplication with LoadGlobalScript & such in ScriptInterface.cpp. I think it's time to merge those together in a single ScriptCompile file or something.
- In particular, there's a question of entry points -> Once we're compiling as modules, we can import submodules, but we can't import modules from non-modules bits.
- Your tests are missing an absolute path, and I think it's broken in the current implementation. I think it should work, and should start from the VFS root as one would expect. Relative paths are quickly unwieldy when you get into folders-of-folders.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Fix filename going out of scope as JS::CompileOptions::setFilenameAndLine does not copy
Use ScriptConversions