hyperion

Can the CI handle it? Do I have to rebase any patch onto master first? Does the committer have to rebase them again when committing? Do I have to manually list any dependencies? What happens if there are changes to master, do I have to rebase them and manually extract and update them again? Well, of course emulating series support is possible to some degree but that doesn't mean it's helpful. If it were arcanist wouldn't be eager to squash commits and 0ad devs wouldn't add semi random changes to existing patches just because the file was already touched or similar. If series support were a first class citizen of the workflow probably 90% of the commits would be split. For example the valgrind patch you mentioned has an "and" in the subject line, acknowledging that it's at least two logical changes squashed. Then look at the corresponding differential in phab and you will notice it could have become a couple more "and" as well. Phab is great for multiple people collaborating on a single change but for a simple reject/accept review it's barely adequate/ the overhead unreasonable. In my perception feeding them one by one or in small batches (they are mostly logically independent) isn't fast but causes the least work for me and reviewers alike over all.

Might be a lengthy vacation, will ping at some point, so even if not fixed anytime soon we can at least know what would need to be done on our side if we choose compressonator. This doesn't sound like much of an improvement. Fixing it to fetch a tarball and apply patches as is done for spidermonkey might be desirable but low priority as long as getting away from it is seriously considered. Moving tinygettext and properly build as external dep with option as system dep sounds like time better invested. If there are other alternatives to nvtt I don't mind looking into them either, but to be clear, I'm still under the impression compressionator to be a good choice for 0ad. Clean api, quality kernels and a whole slew of extras for artists is probably hard to get elsewhere.

I'm currently ahead of trunk by roughly 70 patches. 40-50 are mostly trivial to review and reject/apply, who does it isn't relevant for me. As there is no patch series support in phab this won't be particularly fast anyway. Also I'm not in a hurry either. There are also upstreams to wait for to some degree, so it taking time isn't necessarily bad as long as there is some progress.

@asterix I'm fond of both patches, the valgrind one I used prior to it being committed. The pkg-config one was useless for this task. Beside using cmake in the meantime, there is the issue of the pkg-config premake module needing halve a dozen patches to support cross compiling and being made compatible with pkgconf (an alternate implementation) in combination with a cross root and finally compiling for windows using pkg-config isn't foreseen by the external library search logic either. Further the current premake setup feeds flags to the resource compiler which it doesn't understand and so further adjustments would need to be made. What I did since last update: cherry picked patch for mingw runtime 9.0.0 to support gcc 11 (openal build) switched to gcc 11.2 updated binutils to 2.37 boost updated to 1.77 curl updated to 7.79 After talking with @Stan` I also looked into clang status, cross compiling to windows still can't be considered mature. There is initial pdb support in llvm which probably is desirable and I guess gcc will never have. There is also a very immature resource compiler which would be needed as well. So in a year or two clang is probably a good alternative. He also told me that antivirus doesn't like 0ad and if built with mingw even less, I thought about it and think the injection of startup code into crt before standard program entry might be a possible reason for this. To be honest this is a first seeing this trick. Might giving changing the startup procedure a try. I already started feeding changes back to 0ad, but with @wraitii having barely any time for 0ad currently this might be a lengthy process. So don't expect it being available for general consumption anytime soon.

If taking this as a fact we should conclude any mention of OP is either to have an excuse when loosing or an attempt to hamper any play that doesn't fit into the narrow scheme of what should be legit in the individuals view. If imbalance were an issue we would have mirror matchup settings (civ/map) seen implemented long ago. Also usually cries of imbalance start the day after a release, making it clear there can hardly be any substance to such claims. If balancing was taken serious, ranked games (and maybe others) should be collected and the data evaluated properly. I'm sure statistics will show a different picture in many cases than what people expect. I also second @vv221 claim that all civs playing the same reduces the replayability of the game. This should be obvious to anyone. I would even go as far as to claim imbalance may be desirable for you can easier find an interesting matchup if you can have civ selection slightly favor the weaker player. Well, ofc, if there are millions of players this point becomes moot.

user.cfg is a generated file, based on default.cfg and overrides in local.cfg and later in-game changes of those properties. You may edit user.cfg but honestly backing up or deleting for a reset are the only actions I'd take on it.

The square ones look like rice fields to me, the eyecandy version to me looks more like fish farming ponds designed by Botta. And gravity will always be an issue, maybe restrict rice fields to flat terrain as a malus?

Well, #1554 is marked fixed and #1553 not reproducible, either by @Itms as stated on the bug nor can I. My distribution installs ActorEditor as 0ad-ActorEditor alongside pyrogenesis as 0ad. That line, wherever you came across it, should be deleted me thinks and the bug closed as no longer reproducible.

Hm? Blender and Gimp? Or are you talking about ActorEditor which is part of pyrogenesis and runs on Linux as well? Anyway if it's Linux all you ever need is a text editor.

Of course contributors are more of an investment than getting things done quickly. Experienced opensource coders are not the norm. But there is no need for hand holding either, which you tend to fall into all to quickly.

Just watched the video doing the testing, the obvious result if you throw a one pound stone it will best guns and slings. So we can conclude NO weapon is most powerful. Science the American John Doe way... Anyway, ancient slings were seriously dangerous, just needs quite some practice.

Trusting people to try their best is certainly good. Trusting people are born fully fledged coders and knowledgeable of the ins and outs of the project is bound to not work. The first thing about git is branches are very cheap, commits are very cheap. To test or review I don't need anything committed to master to reduce workload, so there is no need to commit anything to master either. At one point you will have to look at what was done either way, so commits to master can't reduce your workload only increase it unless you don't care about the master branch in the first place. Anyway good to run into such issues now, so you can ponder a workflow for in case of migration.

To used to to svn

Not easy to say without testing but sounds like it might be an improvement, the extra computational cost in most cases should be limited.

Propose an alternative algorithm to pick target. And as @Player of 0AD stated, some intelligent behaviors might well be costly, but could be cheaper than current on as well.

What about the obstruction? Can the enemy still build on top and it's about who starts building first? Could also deduct some resources, like the foundation already costs x% of the total or such.

What do you want to replace and why? Anyway, all I needed was to mogrify some assets and run fontbuilder using always colour in render options and have now a working replacement for nvtt, so no longer restricted to releases respectively already packed mods. Also created some tickets with compressonator to see if what we lack we can get in a future release. I used a somewhat brute method to get compressonator support, I'm sure @vladislavbelov had something more complete in mind For instance I don't offer modders dozen of options on how to treat their textures. For my layman eye they look better on average anyway. I'm not even sure what all those available tuning parameters are about, so everything default. So now I can build 0ad for windows from ground up using mingw, the only things missing are wseh and stackwalking for dumping crashes. Other than that it's fully functional as far as I can tell. If there are bugs they need first be found.

So a zip (ignoring the errors) was created and I ran 0ad with the "new" textures. Some font(s) got messed up, some of the textures auto resized to dimension 2 from 1 look like zebras but otherwise the textures seem of better quality, less washed out. Quality setting used 0.5 (0 lowest, 1 highest), maybe 1 looks even better, might just take forever to compress. Stumbled over another issue, some textures have png and dds in tree, the dds should probably be deleted in this case. binaries/data/mods/public/art/textures/skins/props/cape_hd_black.dds binaries/data/mods/public/art/textures/skins/props/kart_sail_2.dds binaries/data/mods/public/art/textures/skins/props/kart_sail_3.dds binaries/data/mods/public/art/textures/skins/gaia/tree_cypress_a.dds binaries/data/mods/public/art/textures/skins/props/kart_sail_1.dds binaries/data/mods/public/art/textures/skins/props/iber_sail_b.dds binaries/data/mods/public/art/textures/skins/gaia/farming_barley_harvest_a.dds binaries/data/mods/public/art/textures/skins/gaia/farming_wheat_harvest_a.dds binaries/data/mods/public/art/textures/skins/gaia/farming_wheat_harvest_b.dds binaries/data/mods/public/art/textures/terrain/types/desert_forestfloor_palms.dds binaries/data/mods/public/art/textures/skins/props/celt_prop_1.dds binaries/data/mods/public/art/textures/terrain/types/road_roman.dds binaries/data/mods/public/art/textures/skins/structural/rome_ram.dds binaries/data/mods/public/art/textures/skins/structural/kart_trireme.dds binaries/data/mods/public/art/textures/skins/structural/iber_struct.dds binaries/data/mods/public/art/textures/skins/structural/hele_trireme.dds binaries/data/mods/public/art/textures/skins/structural/hele_struct_b.dds binaries/data/mods/public/art/textures/skins/skeletal/pers_isp_e_1.dds binaries/data/mods/public/art/textures/skins/skeletal/rome_ijv_e.dds binaries/data/mods/public/art/textures/skins/skeletal/mace_bronzeshield_pikeman_a.dds binaries/data/mods/public/art/textures/skins/props/head/celt_caratacos.dds

So works on macos, could it be broken on linux only? Will try the update-workspace et al path. Not using mingw for my compressonator experiments. Also 0ad installed by package manager has the same issue. Compressonator is fine with those. Also compressonator is working as replacement already. The issue I face is I can't build public.zip due to skeleton xml files not being found / not readable for some reason. Candidates for issue are pyrogenesis, fcollada, libxml first and foremost. But thanks anyway.

Now it's compressed and my script will pick it up and convert to png so compressonator can open it. The script converts 16 bit png to 8 bit depth png resizes dimension 1 textures converts compressed dds to png All stuff that needs fixing in compressonator obviously, don't fancy working around this in 0ad proper. Still the corrupt dds should be replaced in svn, compressed or not. -- As for generating the public zip, tried with -mod=mod -mod=public, tried with replacing rdb fcollada with 0ad fcollada, tried with system installed pyrogenesis (pristine a25b, no changes by me), tried with mod-packer binary (source below). I always get those skeleton related errors. What am I missing? Btw., source/tools/dist/build-archives.sh doesn't add public either, what do you use to create the release tarball? #include "lib/os_path.h" #include "lib/timer.h" #include "ps/ArchiveBuilder.h" #include "ps/GameSetup/CmdLineArgs.h" #include "ps/XML/Xeromyces.h" #include <vector> void RestartEngine() {} bool g_GameRestarted = false; void QuitEngine() {} bool IsQuitRequested() { return false; } void StartAtlas() {} int main (int argc, const char* argv[]) { timer_Init(); CmdLineArgs args(argc, argv); OsPath mod(args.Get("input")); OsPath zip(args.Get("output")); OsPath cache(args.Get("cache")); CArchiveBuilder builder(mod, cache); std::vector<CStr> mods = args.GetMultiple("mod"); for (size_t i = 0; i < mods.size(); ++i) builder.AddBaseMod(OsPath(mods[i])); CXeromyces::Startup(); builder.Build(zip, args.Has("compress")); CXeromyces::Terminate(); return 0; }

Phew, not just me

Guess I write and archive builder frontend which doesn't expect anything to be installed already. Thanks for clarifying. nvtt didn't chock either. Maybe best effort to recover from broken file headers or so. Maybe someone else on linux can chime in as to what the file command reports for them for metal_desert_small_a.dds. Maybe export as dds and I see if it's fixed for me. (Where did you get a working gimp-dds plugin from, thought that was long dead)

@vladislavbelov Investigated mipmaps framework uses min(w,h) insted of max(w,h) for mipmap min size / count while generating framework always sets DDSD_MIPMAPCOUNT != 0 (1 for no mipmap) already compressed dds need processing or pyrogenesis will chock due to not supported texture format. Converted them to png so I can feed them to compressonator. Also tex_dds.cpp only accepts DXT1 DXT3 DXT5, so no BC5 for normal maps, using BC3 instead. @Stan` Found out what's wrong with metal_desert_small_a.dds, file reports DOS/MBR boot sector, so obviously corrupt dds file. Might want to remove or replace it. Now that I have textures that can be processed with compressonator and pass sanity checks, a few questions wrt packaging: The problem with -mod=mod is you need to have mod already installed where pyrogenesis can find it, doing this during build is not possible, as you are only about to install it. Would have to fix archive build. Can't find the purpose of -md=public in source nor any documentation what it should do, can you elaborate? To build the public.zip I need public mod loaded? Typo or real?

@vladislavbelov, thanks. All those formats which are the same are confusing when getting into it at first. So let's see if I got it right, bc1-5 only for 0ad for now, dxt1 -> bc1, dxt3 -> bc2, dxt5 ->bc3, ati2 -> bc5 Some of my progress: Did resize png of size 1xsomething to 2xsomething and no longer see segfaults. When starting 0ad it fails at tex_dds.cpp:562, looks like mipmap is problematic. Built framework with mingw, only needed minor changes. So no issues from that angle.

git grep "grass b soft dirt 50" binaries/data/mods/public/art/terrains/grass/grass b soft dirt 50.xml:<?xml version="1.0" encoding="utf-8"?> <terrain> <textures> <texture name="baseTex" file="types/grass b soft dirt 50.dds"/> </textures> <material>terrain_base.xml</material> </terrain> binaries/data/mods/public/maps/random/ngorongoro.js:// ["dirta","savanna_wash_a","savanna_dirt_b","savanna_riparian_bank","savanna_grass_b","grass b soft dirt 50","grass1_spring","grass_field","grass1_spring","savanna_grass_a_wetseason","savanna_grass_b_wetseason","savanna_grass_a","new_savanna_grass_a","new_savanna_grass_b","new_savanna_grass_c","steppe_grass_dirt_66","peat_temp"];