aeonios

Ok keep in mind I only changed the terrain shader, and as you can see it's only models that still have the weird black effects showing up so it worked. The downside is that the bit I removed is what gives the shadows a smooth, gaussian-like falloff. I need to figure out what part of it is screwing up. Try this, same thing: terrain_common.fs

I have a suspicion. Try dropping this into mods/public/shaders/glsl: terrain_common.fs

Hmm. What kind of graphics card are you using, what OS and what drivers? EDIT: Also, did you recompile pyrogenesis?

It's not a directory. It's a file in mods/public/shaders/effects/postproc. It should be called HDR.xml, with those caps.

check that directory. The file name is probably wrong. For some unknown reason tortoiseSVN is a piece of crap and can't handle things like name changes properly.

Yes I noticed that when I was digging around in constraints. I also incorporated it into the constructor function. This. I dunno. A lot of the maps aren't exactly popular and some basically never get played at all. Ardenne forest does get played occasionally but I've never seen anyone play alpine valley. The disadvantage of having too many map scripts that nobody plays is that nobody will be willing to use random map selection since they don't want to roll a bad map. One of my biggest goals in improving random maps is to get rid of the bad ones so that it's no longer an issue. For ardenne at least I think it'd be fair to let the users decide if they still want to play the old one after seeing the new one. For the time being I could change the name to Ardenne Mountains or something. That's neither here nor there. It's only the generic maps that actually use the default biomes from rmbiome. Maps representing specific regions can't really do that. Also a lot of the newer maps representing specific regions aren't particularly random and often aren't even very playable, even if they do look pretty good. I think that's something that should be avoided rather than encouraged. I'm all for adding region-specific scripts though. I've considered trying to make a greek acropolis type script, maybe one for bactria and probably a better indian jungle type map.

Probably not more expensive than MSAA. We're talking 50% more memory and bandwidth to read/store normals vs 300% more for a multisampled texture. The depth/normals test also provides an early exit for FXAA which ought to reduce the memory bandwidth it uses, probably, and definitely reduce compute costs.

No. We're still on feature freeze for bugfixes for issues people are having with a23. Also some people are still experiencing crashes when glsl is enabled, which we can't fix so I need to revert the 'prefer glsl' option before it can be committed. I haven't gotten there yet. Any AA will be a serious pain to implement and MSAA is particularly expensive since it makes every anti-aliased texture 4x as large. I'm considering implementing a variant of FXAA using depth and normals to exclude any non-geometric edges. That will also be a pain to implement since it requires writing normals which the shaders currently don't do and which requires an extra texture target that we don't have set up. Any sort of AA also has to consider water reflections and refractions which use separate textures which makes things an even bigger pain. I'll probably get around to it eventually but I have more important things to do right now that are less difficult to implement.

https://code.wildfiregames.com/D1486

Well yes, and it's also pretty good at producing playable maps the majority of the time. Most maps never become strictly unplayable and for the few that have the potential it's still rare and easy to avoid for the most part. Judging by your screenshots that seems considerably more difficult with your method. Actually it is possible to expand regions, using an appropriate border constraint. ChainPlacer also expands its region by placing circles of various sizes (down to 1 tile if desired) at the borders of its region, and in some cases produces shapes very similar to YPatchPlacer. I'm not really sure how the cost compares between the two. Well slope can be expressed either as a vector or as a scalar, each of which conveys different information about how the underlying mesh varies over space. One or the other might be more useful depending on what you're trying to do. Also with regards to noise, there are professional terrain programs such as terragen and world machine that create terrain maps using basically nothing but specific sorts of noise. I don't see that as being a drawback, but rather something that should be put to good use. Diamond-square makes nice maps as is, at least for base terrain, and can be more or less randomized or customized as you care for it to be. Of course it doesn't do everything, but I'm specifically looking for something new and useful. I dunno. I've been playing around with the fractal painter and I wasn't able to get anything more than pointy lumps with a few sharp edges, a rather far cry from the nice mountains I was hoping for. I played around with the params quite a bit and they still don't make any particular sense to me. I never got anything even vaguely resembling your screen shots, although YFractalPainter was the only one I really messed with. Perhaps. I've at least seen the screen shots of anEgyptianOasis, but I still only barely understand how that script works (and I have no idea whatsoever how it creates mountains or anything else with terrain). I've also seen a lot of weaknesses so far, like the sharp vertical edges at the boundaries of the YFractalPlacer's hills, and various other sorts of artifacts (some of which produce unplayable maps), but I have yet to see any particular strength that could be further developed. That's not to say there aren't any, just that if they are then I don't understand them or how to use them at all. And that's coming from someone with a fair amount of technical expertise. Well yes, but random map scripts aren't something that a layman can or ever will create. That's just how it is. If a layman wants to create a map they use atlas. That's what it's for. If you want to create a random map script then you need some level of technical expertise and there's no way around it. We can of course make it easier to use, for people who do have some level of technical expertise, but that's it. There's no way to dumb things down any further than that without degrading the quality of the maps it can produce or the level of customization that is currently possible. If you don't have a basic understanding of how a pseudo-RNG works, or if you can't figure out how javascript works, then you can't make a random map script. And that's fine, because it's a difficult thing to get good, playable, balanced maps that don't look like they were scraped out of a garbage can using a script. It's something that people with no technical expertise would have little to no chance at doing one way or the other. I mean even world machine, the easiest to use pro terrain making program that has a GUI interface to all of its script components, is extremely difficult and complicated to get good results with. In fact it'd probably be simpler with a js interface like we're using.

Personally I think the ideas presented here were awful in general. There were a few good ideas and a lot of really, really bad ones that would have serious unintended consequences that would basically destroy the game. I think the game could definitely be made less eco intensive, and more friendly to fighting rather than sitting in base ecoing up to p3. I think reducing housing cost both in terms of resource costs and the effort needed to constantly spam them would be beneficial. I think that allowing the construction of eco buildings outside of territory would make the game less rigid and eliminate a lot of the nonsensical things people currently have to do to reach resources on some maps. Aside from that though, better not to fix something that ain't broke.

Are you saying that you can determine, with only two bitwise operations, if a tile lies at least x distance from the nearest tile of a particular tileclass? Or that it lies between at least x and not more than y distance from a particular tileclass? If you can then it'd be fairly miraculous. That's also the sort of constraints that are very commonly used when generating maps. Now I don't completely understand how all your placer functions work, or what would make them better than existing placers, so maybe there is a motivation for doing things the way you've done them. I have yet to see the results they produce so it's difficult to make any judgments at this point. On the other hand g_Map is in no danger as long as you don't mess with anything the engine needs, which isn't a whole lot. This is the engine export function: Engine.ExportMap({ "entities": this.exportEntityList(), "height": this.exportHeightData(), "seaLevel": SEA_LEVEL, "size": this.size, "textureNames": this.IDToName, "tileData": this.exportTerrainTextures(), "Camera": g_Camera, "Environment": g_Environment }); Adding a TOmap as an extra internal structure would not affect this in the least. If I understand correctly, your placing/road algorithms work like a sort of flood-fill pathfinding expansion. That's interesting but it still leaves a lot of questions. Well in order for it to be useful it either has to do something that the existing placers can't, or it needs to do the same thing much faster, or be easier to use, or offer some other advantage. Otherwise it's just duplicate code. As I don't really understand what it actually does or how it works I can't really make any judgements on it. And of course I'm not the only person working on random maps, but I am in fact doing significant work on it. Our players want better looking, better balanced maps, and I'm doing my best to deliver on that for a24. I'm trying to understand your work to see how it fits into those goals, so that I can usefully integrate it if it is and to fight tooth and nail to have the code accepted if necessary. The interest people have shown in your work is evidence that it's at least something in the right direction. In terms of performance, that's great on paper but if you can't produce the same or better results to the maps people are playing now, then it's a moot point. At this point I've gotten your fractal painters working and have been messing around trying to get good results with that, but it's still only a part of the whole package. It's hard to make a case for something that I haven't even got working, let alone understand the usage of. Eh, I'm not just hacking at the library without any understanding of how it's used. I've been actively working on making map scripts, and have done improvements for at least 3 different maps now. A lot of the work I've done on the library has been to make life easier for that. Map scripting isn't exactly something you can do without at least some degree of technical expertise, but I have been trying to make it more idiot-proof and less demanding in terms of needing to know exactly what every function expects as input. If you want to see the sort of thing I've been working on I could either dump it into a mod (assuming that the mod's files will override the default ones, I guess) or you could pull my patches from phabricator: https://code.wildfiregames.com/D1501 and https://code.wildfiregames.com/D1497 although fair warning the map script isn't up to date since there's a feature freeze I haven't bothered. I'll probably update it later today though, and maybe add my ardenne forest remake since that's pretty well cleaned up now.

Well that's good to know. I think the only difference is that paint() should take an area as input. It's a pretty simple fix. Creating a new painter isn't really a major overhead, and usually you only create a painter once per major job. Like if you wanted to paint mountains, you'd probably create a painter for that, create all your mountains, and then discard it. You wouldn't create a new painter for each mountain. Of course if you have two different functions creating two different types of mountains, then each would create its own painter, but that's a minor detail. I suspect that the biggest overhead for map generation is actually checking constraints, which may be O(n*m) where n is every tile being written to and m is every point owned by every tileclass that needs to be checked for the constraints. If tileclasses were reduced to a single tilemap with one allowed class per tile, then checking constraints could probably be reduced to near constant time. There are actually two ways that can already be used to achieve that with current rmgen. The first is constraints and the second is to use placement within an area. Both methods can be combined as well. The only thing it doesn't support is using slope or height in constraints, but it would be pretty trivial to extend constraints to support that. I've also extended the library with a function that allows you to get an area from a set of constraints, making it easy to increase the success rate of operations which would otherwise fail heavily due to restrictive constraints. With all of that I'm not really sure if the TOmap is really necessary. Getting stuff included in rmgen isn't really that difficult. The fractal painters could be added immediately with just a little bit of cleanup and updating. The other stuff would probably need to be reformulated, which would be more work but that ultimately depends on how much of it is actually needed.

After sifting through the library I've sort of begun to understand how your painters and placers work now. The painters I can mostly understand although I haven't figured out what kind of values it expects for all the params. One thing that does bother me is that the fractal painter seems to expect a roughly circular area when placing. What then would happen if you fed it a non-circular area, like say a long wavy region produced by a path placer? As is it might be difficult to integrate usefully with existing rmgen library utilities. While I'm not sure if that's actually an issue or not, the interface is also nonstandard for painters. The area param should be moved to paint() and the 'nochiasm' param should be moved to the constructors. Beyond that I'd have to play around with it to see what it can do. For 'nochiasm' I can sort of see and appreciate how that works, but it also lacks a 'modify' type functionality like the current elevation painters offer, which is useful if you don't know ahead of time what the base elevation will be (for example when using diamond-square for initial terrain randomization). The placer interface is terrible. In the map you do some sort of weird raw loop to create a "monts" zone and some others which I don't really understand the point of. Reimplementing constraints and things from scratch in an even less intuitive fashion is less than ideal. It'd be better to extend the RandomMap prototype with that kind of stuff. Personally I don't really like how the current tileclass system works, since each tileclass is effectively defined as a random bag of points, which is particularly inefficient for checking constraints later on and also means that a given point may belong to more than one tileclass, which is kind of bad when you're creating a map by painting layers. However constraints are very convenient, or at least the interface for them is (which I've submitted a patch to improve even further). The current (rmgen) implementation doesn't handle slope hardly at all, which could definitely be improved as well. I can certainly see the usage of the road creating function although I can't really tell if it auto-flattens terrain to create a path if there isn't already one, but that would be nice. It seems like something that would need a lot of tuning but it's definitely a cool feature. The existing road function sucks. I cannot really figure out the purpose of the YPatchPlacer, or how it differs from any other sort of placer. Cramming all that stuff in with the TOMap doesn't make much sense. The TOMap should have its own interface, and the placement/road functions should have their own, possibly moved into gaia_terrain or wherever happens to be most appropriate.

I figured out why the text looks screwy. The block of space around the text is using low alpha, so it's actually transparent and the map shows through.

One other thing, I think the extra buttons in lobby chat should always be visible. Having them only be visible on mouseover makes them hard to find. It's also kind of annoying to have them pop up and move the chat input strip suddenly upward.

Nobody uses a22 anymore either. I think your fractal placers and painters have the potential to produce much better looking mountains, lakes, continents, etc than the current library allows for. I think with a better interface and integration with other library functions it could/should be included for a24. The usage in anEgyptianOasis was kind of raw and lower level than what random map designers ought to be exposed to. Even the rmgen interface in a23 is a bit junky and I've been working on improving that and making it easier/more consistent to use.

IMO that should be true for all siege weapons. Capturing them takes twice as long or more than just killing them. For siege towers it's even worse since in order to be useful they have to be garrisoned, and if they're garrisoned then they're uncapturable. I think a better idea for siege towers is to give them the ability to capture buildings. They should have a low base capture rate, but gain a large bonus per garrisoned unit, like 2 or 3 times the usual capture power of the average unit. That'd be cooler, a lot more historically accurate, and would make them actually useful as siege weapons, which they supposedly are but currently they're more or less useless against buildings since they barely do any crush damage.

Text is still broken for pause/waiting screens. Also, if you select units during pause the selection circle doesn't update. If you had a unit selected before pause, the selection circle stays locked on it regardless of what else you select. Also a request: when in observer mode it'd be cool if you could see the resource/pop stats for the player(s) whose units you have selected automagically.

It doesn't work with a23. InitMap and ExportMap have been converted into methods in a23 using the RandomMap prototype so trying to call those functions fails. I have no idea what they used to do so I can't really replicate it either.

Hmm. I think I can sort of see where you're coming from with wanting to represent the map data as a collection of objects containing point/height/slope rather than just an array of height data. That would certainly allow you to treat map points more uniformly when performing various operations and current support for slope-based operations is very poor to say the least. On the other hand I don't really understand how you're trying to create entire maps from scratch in a single pass using fractal/viscosity type logic. The current rmgen functions are fairly easy to understand when reasoning about geometry, although also fairly limited for doing certain other things. I'd like to see an example of a real (playable) random map made using this method and the sort of code/calls that you'd use to produce it. It's easier to understand things when you have a context to go on. Since this may in fact offer a significant improvement over the generic rmgen method I don't really want to overlook it as a possibility, and I am working on improving random maps for a24.

A lot. Since it's on average about a year between releases that's a lot of time to get stuff done though. I plan on starting with graphics and random maps and then moving into multiplayer performance and fixing/improving other multiplayer issues, and then maybe improving gameplay in a few important ways. I'm intending to make a24 a really big improvement over pretty much all previous versions, as far as I possibly can. I'm still not really sure what you mean by that. o.O

If we did that we'd end up with "money maps" like in starcraft, which isn't really good because then we'd need to disable such maps for rated games, creating yet another problem. I've been thinking of changing the way resources (esp stone and metal) work a bit, but I'm honestly not sure if the effect on gameplay would be beneficial or not. That's kind of off topic though. @Sundiata Nothing has changed for a23 regarding droppers :[. I'm hoping to fix that for a24, by making the networking p2p and making a drop = loss condition if a dropper doesn't rejoin after a certain amount of time (like 3-5 mins maybe) and converting "exit" into "vote-exit" so that you can't exit the game without resigning unless the other player(s) also agree(s) to. Zero-K does that and 'dropping' isn't a thing in that game so it definitely works. I actually rewatched that replay, and aside from picking up the treasures that guy played horribly. It's kind of embarrassing that I even lost to him. If I'd had full unit upgrades I probably could have won, although after checking I couldn't find a single mace unit with hack damage (ie mace doesn't have one, which I guess is the trade off for having every type of siege weapon), which wasn't really in my favor. I probably even could have recovered from losing my CC, but I wasn't really calm enough to manage that at the time.

IMO siege weapon capturability should be removed completely. It causes units to do extremely stupid things and is basically useless since killing the siege weapons is almost always faster, by several times. Also I'm pretty sure that every civ has a ram already, and if not rams then elephants which are basically the same thing just with a different weakness. However not every civ has a catapult, which is more problematic since catapults are basically the only ranged siege weapon and the only thing that can shoot over friendly and enemy units without being blocked by meat shields. Siege towers and bolt shooters don't even qualify as siege weapons, since they barely do any crush damage and take forever to kill buildings.

I don't think that's necessarily optimal. Some maps, notably Bactria, are really not playable without the treasures. Bactria is pretty wood deficient even with them. The treasures probably wouldn't have been that much of an advantage had it not been for the very low resource setting. For a very strong player perhaps, but very strong players don't need that sort of buff to win anyway. What? You can pretty much tailor everything exactly as you like it when it comes to random map scripts. Maybe not ambient sounds, but resources and treasures can be set based on whatever criteria you want. There are issues with random maps that are related to the use of crappy deprecated resource spawning functions, but I'm already working on fixing that for a24 as well as greatly improving a lot of the random maps both in terms of appearance and balance. I dunno about that. It's possible but there are other contributing factors that I didn't check, like upgrades. For experienced players I kind of doubt that they'd put up with this kind of nonsense, and might be more careful about checking game settings. There are two main issues that bother me though. The first is that this guy prefers to pick on newbies, especially people who are unrated or are 1200-1300 elo since those people are more likely to fall for the trap and less likely to voluntarily exit as soon as they realize that something crooked is going on. That sort of predatory behavior is bad for new player retention. The second is that this guy has gotten like 1400+ elo by gaming the system this way. Elo should be a reasonable measure of skill, and cheating that system undermines its value. It makes the game and its devs look bad if one or more people in the top 100 ranking have basically cheated to get there. I don't think it's actually that common at this point, but it could easily become so, and for the sake of our community I'd rather that it didn't. I don't think so. I doubt he "searched" for them, but rather memorized exactly where they were to ensure that he could get to them first. I mean sure if I'd been more familiar with the map or been thinking about treasures at all I could have had the same chances, but under normal circumstances treasures are either an optional bonus or something that's placed right next to your CC so that you can grab them easily, not something that entirely determines the outcome of the game. Obviously with random maps an exploit like that isn't really practical one way or the other.