Jump to content

elexis

WFG Retired
  • Posts

    3.644
  • Joined

  • Days Won

    59

Everything posted by elexis

  1. Thanks, I didn't know that Atlas feature! It seems when rightclicking, the 4 vertices still have the texture of the surrounding tiles but the center edge receives the different texture. It must be that blending thing that isn't supported currently in rmgen. The main problem is computing if a given position is obstructed by a building or not in a more precise manner. (Probably only requires biting the bullet for a number of days.)
  2. Which clicking only works 50% of the time? Is that reported (if so where)? Tooltips being incomplete is a thing. Especially civ bonuses and the history tab need rework.
  3. Step 34: Becoming artistically inspired by LordGoods awesome Atlas-created oppidum scenery. A new technology for paths that are smaller than 1 tile is what above map needs, but is not feasible with current code!
  4. Are you speaking about the forums or play0ad.com? The latter seems to always have the same header. Works well for me on the forums and the html contains the correct information. Sounds more like a clientside bug, which browser are you using?
  5. You can't unless you impersonate. The mods allowing that are against the terms of use and I think we should flip a bit to make impersonation impossible. (I guess smiley answered the questions though, didn't read)
  6. @Itms svn broken apparently ^ LordGood: file attachment? (If matei, historic_bruno or Philip were still active I could have asked them how to efficiently implement more precise rmgen colllision detection. Perhaps we can reduce the tilegrid size or use the Geometry.cpp functions for obstruction collision)
  7. We didn't start alpha 24 development yet (so only bugfixes that don't trigger OOS until GDPR and release responsibilities were performed).
  8. Man this is going to be disappointingly hard to code (and code efficiently) to use grids with higher precision than 1 tile in rmgen, but unless we want to stop rmgen development, it has to be attempted (as it's the logically next step). Can you upload the footpath actor? (As mentioned, we should have that in the repository once we start alpha 24.)
  9. Do you have some plans for that oppidum? It looks like it should be bundled into a scenario/skirmish map. Some practices that I saw utilized here and elsewhere that are problematic for released maps but can be remedied: Stacking buildings inside each other repeatedly. For instance there were like 15 towers in the upper fortified section above, or some temples stacked inside each other on the Napata reconstruction map. The first problem is that each building is selectable separately, has a separate production queue, garrisonholder, auras et cetera. The second problem is that half of the polygons of the mesh are invisible or incorrectly overlapping. The remedy is to introduce a new actor based on that composition, remove the invisible and unintended faces. There are 2-3 briton buildings but the rest is gaulish. At least when selecting the building it becomes apparent and breaks immersion a bit. Can be remedied by introducing a new template, possibly with the color / texture that the other gaul buildings use. There are some archery ranges, but they are stylized as farmsteads. Rebuilding that with code would be interesting, challenging, painful and benefitial (in that order). Whether or not such detail can be achieved with random maps will determine whether it will be feasible to create the campaigns with code or atlas. I recall Skhorn building many similarly candyful maps too and his thought to get into random map coding in order to save the work with manual optimization of entity placement (as possibly thousands of entities have to be fine tuned with multiple clicks in atlas often). Perhaps it'd also make sense to create the oppidum in atlas and load it from scripts if it's too inefficient to code. About the original topic, the path actors you added are like 4 times smaller than the smallest path that we can currently create with terrain textures. Doesn't seem right to have to place actors to create a terrain texture, but it seems unlikely that we want to increase the resolution by a factor of 4² or even 2². So we might need the paths at least for atlas editors.
  10. Can you upload the according atlas files? I'd like to know the actor density. One problem with placing bushes on random maps is that some of them are tiny (so multiple ones fit on one tile) and others are big (need a distance of two tiles to the next actor). (Then one changes one number and has to wait a minute for the loading screen to see if the new number is better, in atlas one can fix instantly, but once per entity)
  11. Entities on random maps are most commonly placed as a SimpleGroup consisting of a specified minCount, maxCount, minAngle, maxAngle. So the result is random angles, but we need specific angles. The fences and walls seen on your screenshot are always parallel to the tangent of the encompassing area, so it needs an algorithm computing exactly that. (The dock placement ingame and on the Hellas random map computes the tangent angle by computing the angle to the geometric average of the encompassed area. That in turn is really slow resulting in 10s of seconds of loading screen time. It's faster to determine angles and then place with more hardcoded offsets.). (Besides angles, locations also need to be perfect, just being off by 0.5 leaves very ugly artifacts.) Visual actors, especially the eyecandy/ ones are often combined into a new visual actor that can be placed as a sole actor entity. For example the fields players can build, or check "campaign_city_test" in the atlas editor. But there everything is fixed, so it always looks the same / repetitive, which is the same downside to atlas maps. One could create multiple visual actors that are compositions of fields, paths and fences and then just place these composites. It's a tradeoff between the disadvantage of repetition and the disadvantage of placement coding. But your palisades are also much nicer than the one on the oppidum map, because they aren't perfectly circular and there are some random offsets between the palisade and the bordering path. Another aspect is that you have two levels of elevation, while I had to work with a plane because there was supposed to be water. Basically everything is a bag of possible but timeconsuming TODOs.
  12. I didn't get the question, can you elaborate?
  13. Player built cities won't look like that as long as they can't place trees, fences and paths, have only square fields and rarely rotate buildings beautifully (there'd have to be some auto align or prebuilt paths to be aligned with). It is also tough for procedural maps since these paths are smaller than one tile and algorithms have a really hard time to not waste space between entities. (Just look at how crappy in comparison that oppidum map looks that also wanted to have paths and fences near things) But that composition looks exactly how maps with prebuilt settlements should be.
  14. Step 33: Considering Quest-design. As the map generation concludes, what concerned me most since the last update is which unique triggerscripts and features the map should receive. The "zombie invasion" gameplay known from survival of the fittest, polar sea, danubius and jebel barkal is interesting, but it is not unique anymore. Yet we want to break the status quo with every map. So I was thinking about RPG elements, such as storytelling and quests. Quests are mostly combinations of the two elements movement and destruction (go to location/person X, get/bring item/person X, talk to X, kill X units while doing so). The only possibilities that come to my mind: Main quest: When encountering some delegates of the celtic tribe outside of the oppidum (= passive hero + passive guardians?), a cutscene is triggered with some storytelling, negotiation with the celtic tribe. The talk could end with leaving the player multiple choices, for example whether to cooperate with the people in the oppidum or condoning war. So if the celts are pleased, they would spare one team and attack the other side. If they aren't, they will attack as known from the zombie-outbreak maps. The difference to diplomacy with a Petra bot would be that it's embedded in a story that is unique to the map. This is still one-dimensional. What makes stories good are plottwists, so maybe by some turn of events (being almost wiped out and claiming loyalty with gaia?) players units may flee to oppidum, work for gaia, help gaias cause in fighting the enemy or doing some labor for them. There could be a specific victory condition triggered in such a case, rather than just relying on gaia being militarily able to defeat the other team. Side quest: It could be that there is a lone celtic woman somewhere that when talked to, triggers a cutscene, tells some short story and if you bring her some entity or unit, you get some ingame benefit such as a treasure or some unlocked map-specific technology (maybe we can do something with the spies feature). I'm not really convinced by these thought experiments yet, but something like this has to happen eventually. If there is actual storytelling, there should be interesting camera angles and cutscenes while the text is displayed, otherwise it's too boring and the ingame controls are binding attention too much (at least that was my feeling with the tutorial). That's militarily more reasonable yes. The oaks are so beautiful there and voidness is so ugly that from a mere visual quality point of view I'd rather keep them even if unrealistic (it's a fictive place, so maybe it's still covered by artistic freedom). Secondly, that quote could be embedded in the story as is. It's what the experienced roman engineer could say to the people of the foolish celts who never understood the concept of fortifications well, and only built them because there was this one guy fearmongering. Or maybe they took over the ruins from a past tribe and didn't build the fortifications on their own.
  15. Declare a variable and use it as a cache -> yes? Whether it's reasonable to do so is written on a different piece of paper
  16. There should be an option in atlas to vertically resize the terrain in theory. Suggested reading https://wildfiregames.com/forum/index.php?/topic/20786-palaxins-heightmap-guide/
  17. "I would like to see it happen" is all I can say. If someone works on anything it's always a surprise for everyone. Even started patches are often discontinued. Heightmaps can be imported already in atlas and mapscripts already, what are the 26 special colors for?
  18. About some auras being slow, take a look at the relic auras, some of them are tremendously slow, especially those changing vision range #5099, it gets worse with the distance. Terrian flattening also has problem, consider the "Flying Wonder" in #3913. So we need to take some precautions before doing so. But the feature is certainly interesting, bridge building, road building, digging ditches, I want that somehow.
  19. First thought I had: Try cleaning the mod and cache folder, check if the download and installation were correct, maybe reinstall, https://trac.wildfiregames.com/wiki/GameDataPaths But please upload mainlog.html, either it fails printing the directory or it fails to locate the directory, which would explain the zip reading issues too
  20. No, that's not possible currently, but it is a viable and not so hard to implement feature. The terrain data (elevation and textures) are currently determined by the map and then there is no code to modify it in any way. Serializing the terrain (i.e. storing in savegames) is described in #2147 and one of the necessities. But there is also the simulation interface needed. There must be a TerrainManager system component that can be called from for example by building placement (terrain flattening or bridge-building in the Foundation or Repairable component or Commands processing), a triggerscript (for example simulating a vulcano) or maybe even a catapult hitting the ground (Attack component). While at it I'd also take the EnvironmentManager.
  21. Step 32: Performance improvements from 63 seconds to 41 seconds for a normal sized map, further down to 27 seconds with a library improvement. One of the biggest enemies of map development is the loading screen (and the reason why three days passed until the actors were placed). Behind each of these numbers a different algorithmic and mapdesign problem resides. Map generation should consume less than one second, so one could see an actual map generation preview in the map selection sreen, guess that will never happen. Created a profiler so that we can see the bottlenecks (here a subset of the output): The code quality is satisfying, since only two types of commands (createArea and createObjectGroups) are used repeatedly. So the complexity is comparable to a markup language (a composition of styles) but still remaining turing-complete. You are right, it's also something I wanted to improve. But there are some problems with that. The first problem is to compute the tangent angle at an arbitrary area, for example for the fences. But for the walls it's even more difficult because the wall piece angle would not be equal to the angle at the center depending on the shape. I had tried two approaches to create a breadth-first-search Placer that calls different painters depending on the distance to the border of the area (so one could have a winded path from A to B, trees on the right side of the path and a ditch on the left side of the path. The PathPlacer and the paintRiver function do something like that but not quite and it doesn't fit well into the library without some good design idea.) So it seems like that's future development. You are right that a promenade would be unlikely near a fortification that the city depends on. Perhaps they got so used to the peacetime, trade and the good life that they beautified the oppidum.
  22. About the argument that players don't know the city names, when players read something they don't understand, they get incentivized to read the map description which illustrates the meaning, which in turn incentivizes them to lookup some history. Is the proposed meaning Beautiful Gaul or Gaulic Wars? Both terms would fit, but isn't it nicer to use a gaulish name more authentic than a roman one? It's also why I had chosen Danubius and Ratumacos (rather than Ratumagos). I couldn't find the gaulish translation yet (or even a good place to find gaulish translations at all)
  23. Besançon aka Vesontio fits with regards to being an oppidum near a river, but it doesn't fit with regards to the other two rivers / streams. It's good evidence though that this kind of oppidum depicted in the map is realistic. It's probably better to chose a generic name, but Oppidum and Two Streams seem a bit dull. Maybe something describing a clash and territorial conflict with celts. There should also be some unique simulation scripts. Winning the game when capturing the CC is just the most obvious step, but can we find something beyond? Some RPG elements were nice, a dialog between some individuals, the celts only attacking under some condition, storytelling and such. For nomad mode I thought players might start inside the city with the fortifications being inactive but replaced with active ones after 5 minutes or such. All of this is asking to start the campaign, then there is no more question with regards what to map and what story to tell.
  24. Step 23: Add towers near the oppidum walls. Less than seen here though! Step 24: Adding a lot of flora near the water. Step 25: Reintroduce substreams that are not horizontal to the water: Step 26: Add a second type of farmland and add a path around it. Step 27: Add a lot of actors on the paths and on the main grasslands. Step 29: Add the bigger buildings in around the CC. Needs improvements though. Step 30: Add men and women to the city. Step 31: Use other texture for the main terrain and the waterground. That one had been chosen because there were some nice flowers on it, but I agree that it looks odd when zooming out. In particular I need a good name for the map!
  25. That is true for some map settings for some map types. In onlne multiplayer almost exclusively random maps are used and currently 70+ random maps support all gamesettings. So people (rightfully) expect their settings to be persisted, when they already discussed for 30min the teams and settings but only want to play a different map. For scenario maps only the gamespeed can be chosen currently, and I guess that also makes sense to persist (but certainly not the rest including ceasefire)
×
×
  • Create New...