All Activity

Also read the commit guidelines and you can always check the Wiki. And this is a very user-friendly guide to the basics of Git. The hard data is here: https://git-scm.com/learn

In this case no, it is purely an archeological category. The Frisian pottery is unique to the region and cannot be grouped within the Rhine-Weser or the Elbe traditions. Frisian pottery has its own features and it is spanning a period from the 7th century BC to the 4th century AD. It is highly probable that the original Frisian people has been replaced culturally during the 3rd and 4th century AD. Probably by migrants from the Lower Elbe and Jutland. It is entirely possible that the earliest Frisians spoke an orphan language since it is naive to believe that we are aware of all the linguistic branches of the Indo-European family. It is very likely that some branches disappeared without leaving any traces or legacy. However, it is important to realize that the Nordwestblock theory has its critics. Many of the arguments in this theory are based on an overinterpretation of onomastics. Several experts have already pointed out that many examples presented as impossible to explain using Celtic or Germanic languages are highly debatable. Furthermore, other experts have pointed out that certain features presented as representing a unique substrate in this region are in fact found in other distant regions. Furthermore, it is quite inconceivable to imagine a language that would serve as an intermediary between the Celtic and Germanic languages. The two language families likely diverged several thousand years ago, well before the Iron Age. The most likely scenario is simply an exchange of words, borrowings from one language to another. But that does not fundamentally alter the structure of the language. If it is a linguistic isolate, there is a good chance that it is a language derived from the Italo-Celtic languages.

Perhaps this basic guide will be helpful

The building sections is copied from one of the old design docs; tbh i was mainly focused on doing the units and bonuses. They will probably need rams purely for gameplay reasons (it was decide a while ago that all civs will have them iirc). I suppose they could extrapolate from later rams or use the log ram as with the Germans. https://research.vu.nl/ws/files/42190004/chapter 10.pdf The actual archaic siege methods would be a bit hard to portray through gameplay (although a tech or passive bonus that makes infantry stronger against buildings to somewhat compensate for poor siege is possible) The Olympia ram is probably outside the civ timeframe by some decades; with the relative rarity of rams it's possible there were slightly earlier rams that left no record (Siege engines were sometimes built on site because it was easier than transporting, so it's possible they would be discarded afterwards with perhaps the metal parts being melted down or reused in another siege). Although it might be better to err on the side of caution by giving them only log rams. As for siege warfare in Greek epics, there is a moment where Hector uses a rock to destroy the gates of the Greek camp.

New Version, now with a button "Check for Updates" on the mod selection screen prior to downloading anything ewlse (thanks to @Asher) . Unfortunately, for me everything is green as my mods are all updated already... Could somebode please do some testing? Again R28 is for Version 0.28 and R29 for the new SVN version 0.29 (nightly build). There is also a little user and maintainer documentation. modiomod-changes.md modiomod-r28.zip modiomod-r29.zip

So, how do I make a PR, do I need to be added to a list of editors for the repo?

Ok, got it working!

I just got fed up trying to convince the AI that helots are not Durin's folk, so left it at "some of which clearly need to be improved"

Snow Red and the Seven Helots

OK, and now including a simple colour legend on top. Thanks @wowgetoffyourcellphone ! R28 is for Version 0.28 and R29 for the new SVN version 0.29 (nightly build). Looks like the internal mechanisms changed. There is also a little user and maintainer documentation. modiomod-documentation.md modiomod-r29.zip modiomod-r28.zip

How do I specify which one it should use when building? Actually, I think I figured that out...

@Ultimate Aurelian, just after having a very fast look at that: -"Shield: Hoplon": the term is not hoplon, but aspis (which you used somewhere else). -"Peripteros": this does not mean temple (that's naós*), it's an architectural style. -"Epiteíchisma": this is not any fortification, but one built in enemy territory**. -"Only rams": some guys with a log? The first recorded Greek battering ram is from 427 BC. *Are naós and naûs related? https://www.labrujulaverde.com/en/2026/02/is-a-greek-temple-actually-an-overturned-ship-a-new-theory-revolutionizes-the-origin-of-classical-architecture **That's why "epi" is used. Just fortification would be "teíchisma" (literally "walls", the whole "fort" could be called "phrourion", as in vanilla). You also have proteíchisma (what you build before your fortification, like a smaller wall or ditch) or hypoteíchisma (counter-walls).

Hmm I think I fixed that by using brew clang rather than apple clang for spidermonkey

testing some mechanics, to find a balance between a more numerous and strong legion vs fewer and less organized, and so far it's working!

But, it could just check what mods you currently have, and see if there is a newer version on modio. You could still have to agree to update

@wowgetoffyourcellphone absolutely - currently the script only provides a warning in the map description the user is highlighting if the colour is grey, yellow or red. Difficult to find the space in this densely populated window. May be we should shorten the list output to fewer lines and provide a one-line legend? At the same time there could be more space underneath to show the mod description in full (gets sometimes truncated). My concern is only that the modio.mod is a small convenience helper function only, and integrating it into the game should not trigger a major redesign of the mod.io interface code. @Asher I do agree - but I am afraid this would mean preloading mod.io data whereas currently, the user has to agree to the conditions and the connection first and then intentionally start looking at what is available.

Would this just be in the download mods page? I think it would be nice to have the update checker in the main mod page

Hey, so just tried building it again, and ran into a spidermonkey error again 0:00.67 checking for target linker... 0:00.67 DEBUG: Executing: `/usr/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.sdk -mmacosx-version-min=10.15 -std=gnu99 --target=arm64-apple-darwin -Wl,-ld_classic,--version` 0:00.67 DEBUG: Executing: `/usr/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.sdk -mmacosx-version-min=10.15 -std=gnu99 --target=arm64-apple-darwin -Wl,-v` 0:00.67 ERROR: Failed to find an adequate linker *** Fix above errors and then restart with "./mach build" ERROR: SpiderMonkey build failed

A small ledger telling what the colors are would be nice.

here is my old Archaic Greek design, with some updates (i have a couple unpublished civ designs)

Would you want to help with adding the script to turretholder.js that ejects units on destory?

I agree that this would be a nice addition to vanilla.

I guess because changes happen incredibly slowly... Hopefully the game will progress from being historically themed to be historically based, and maybe one day even historically accurate

Again thanks to @Silier for this great little mod and the idea behind! Not being a SW developer, I asked Claude to help and adapt it to 0.28. Here it is. I also have the version that is said to be working with SVN (currently 0.29) but still have to test it. If it works I will provide it as well. Again - this is not a professional solution and I apologize for using AI help. What I do appreciate is that the change doc created includes the what and why it was changed. I would suggest to include this little feature into the game itself. Here's the exact logic for colour code per line in the mod.io list (from getModIOColor() in the file): Gray — the mod.io listing itself is invalid (the engine rejects the mod entry, e.g. broken mod.json on mod.io's side). You won't normally see these unless you uncheck "Filter valid mods," since that filter hides invalid entries by default. Red — dependencies not met: this mod requires another mod (or a specific version of one) that you don't have installed. This applies whether or not the mod itself is installed. Yellow — installed, and a newer version is available on mod.io than the one you have. (This can only apply to something you already own — the check for "update available" only fires if it finds a matching installed mod.) Green — installed, dependencies met, and your installed version is current (no update pending). White (no color) — not installed, but otherwise valid with dependencies met. The order matters — it's a priority chain, not independent flags: gray beats red beats yellow beats green beats white. So a mod with an unmet dependency shows red even if you already own it and it's up to date; only once dependencies are fine does it fall through to yellow/green/white. One more detail: selecting a mod also shows text warnings in the description panel independent of the row color — "(Warning: Dependencies might not be met.)" and "(Info: Update is available)" — driven by the same areDependenciesMet/isUpdateAvailable checks. modiomod-r28.zip modiomod-changes.md

why's this still in game bruh this shi is fake right? there's no historical evidence that marius really revolutionised the army or whatever