User Details
- User Since
- Dec 21 2016, 1:38 PM (281 w, 6 d)
Yesterday
Mon, May 16
God this code is a mess.
Sun, May 15
This one should work
Still learning lua
Fix cross-compilation, run with ARCH/HOSTTYPE=x86_64
Proper fix this time
Will be invalidated by D4646, which seems easier given the rest of code changes, and since this is old/stale I'll abandon directly.
For Demo purposes, add a RunThreaded function to run some threaded javascript. This highlights that a web-worker like API is doable, but doing it efficiently would take a little more thought.
Rework, upgrade & make actually functional.
Sat, May 14
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.
Fix last comments.
Change #elifdef to #elif defined()
Fri, May 13
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.
Wed, May 11
Raise error, handle errors in the C++ (fail to autostart)
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.
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.
Tue, May 10
Always load the network JSI functions.
Think this approach is workable, will let freagarach take over :)
Hm, hadn't though of loot. Your right, that's more annoying.
I think we found a better idea, see comments in the fixing diff that ended up being committed.
As for some knowledge drop:
Mon, May 9
C++ changes only, CC
For reference, AoE 2 added a ranged/melee unit recently: https://www.youtube.com/watch?v=rvJdOKktoMA
The switching is not automatic but manual.
As I pointed out in the forum, 0 and undefined aren't actually equivalent anyways. The formula we use is:
effectData.Damage[type] * Math.pow(0.9, resistanceStrengths.Damage[type]). You'll notice that Math.pow(0.9, 0) is 1, whereas Math.pow(0.9, undefined) is NaN, as one would expect. Thus a guard must be added, and thus there is an obvious difference.
Sun, May 8
High-level comments:
- I think this is something we should move towards. It's saner than our current code in the GUI IMO, and could lower load times and sort out the common mess somewhat efficiently.
- I think you'll need to have the module cache at the ScriptInterface level but I would need to check the SM docs
- We have a question for loading whole directories, but maybe we should treat it as an implicit import * as FILENAME from FILENAME.js
- We need to consider how to handle hot reloading as well.
Commonalize code, maybe fix serialisation issue, am confused by why it seemed to work before.
remove Civilisations.js, failed to notice that.
- Move gamesettings from gui/gamesettings/ to gamesettings/. This moves attributes as well.
- Move autostart files from gui/autostart/ to autostart/. Note that gui/autostart/ still exists as it's used in the tutorial button from the main menu.
- Implement a placeholder autostart/entrypoint.js in the mod mod.
- Rename the JSI_VFS functions to be explicitly about their function: the ability to write and the potential restricted folders.
- Load the full autostart/ folder instead of just the entrypoint script to allow easier extensions in mods.
- Don't require autostart when using --autostart-client in non-visual mode.
spaces
I think we've largely agreed that long-term, the proper fix here is to implement a templateLoader-level ListTemplates(TemplateType) function, and use different root elements (<Entity>, <Technology>, <Civilization>).
Fri, May 6
Mon, May 2
Sun, May 1
Gonna raise a concern, I've convinced myself this needs to be mostly reverted. See https://code.wildfiregames.com/D4630#196827, rephrased below:
I've considered smiley's comments that this should just take a template. But trying to do that was super awkward. This had got me thinking that rP26298 was essentially the wrong move.
Sat, Apr 30
Might be worth abandoning the diff then, but I seem to generally agree.