FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
I think that makes a lot of sense, given that "murkiness" in real life™ is due to particles in the water which would receive shadows if they were modelled individually.
Yes, though perhaps there could be just 2 shadows (then without particles): One on the water surface and one on the ground below the water. The shadow on the water would be for refractivity differences of water/air and particles in the water/at the water's surface. The second would account for the light still shining through. The second (to be absolute realistic) might also need to consider the refractivity difference of air/water.
I have no idea about particles or GPU abilities in general, just a though.
-
Looks very nice to me!
-
Yep this I agree. This chain mail propagated to the other civs. Yet the fact that they invented chain mails means that they were pretty much the experts when it came to smithing so they still forged better quality equipement. However not every celtic warrior had access to them since their armies lacked the organisation of other civlizations of that time, so there was never any rigorous plan to equip everybody. However like everyone today has their grandfather gun hanging around in a basement, every celts had some old weapons lying around in their houses, coming from someone in the family who was a warrior.
Good (riveted) chainmail where in general rare because it was expensive to get and to maintain. The most available (and used) armor in any age (until armor became pretty useless) was the scale mail while the materials used differed by region and culture. Even most plates where cheaper than good (riveted) chainmail.
-
Pyrogenesis crashes with out of memory error in large and very large sizes.
Oh, I noticed. It happens when the number of players are small compared to the map size (whatever that means ^^).
I fixed it and added it to the corresponding topic (http://www.wildfireg...=20#entry243899) and created a ticket for the patch (http://trac.wildfire...com/ticket/1522).
Thanks for the reporting
! I only tested with tiny 1-2 players, small 2-3 players, ... before. 
-
Here's a new version fixing the out of memory errors on large+ maps with only a few players:
Here's a table of the entities per map depending on map size and the number of players:
size width tiles entities with: average tree density
8 players 1 player 8 players 1 player
tiny 128 16384 430 1827 ~0,026 ~0,112
small 192 36864 1365 5519 ~0,037 ~0,150
medium 256 65536 4862 8604 ~0,074 ~0,131
normal 320 102400 7010 9029 ~0,068 ~0,088
large 384 147456 8295 9439 ~0,056 ~0,064
very l. 448 200704 9213 9777 ~0,046 ~0,049
giant 512 262144 9916 9866 ~0,038 ~0,038 -
[...]
Deep Forest is an exception and it crashes if created in a large map.
It's an exception, alright, but it shows well that 8 players on a tiny map don't grand enough room for much map design and even the players are to close to each other.
It crashes
? With what error/massage/reason 
? For me it generates fine in any size... 
BTW: I seam to have edited my previous post while you where responding, sry.
-
[...]
Please think about player placement in maps you are going to suggest. Someone might play an 8 player game in a tiny map. The map must be open enough for such a case.
A map with too many entities/actors would be problematic so a forest heavy map is out of our reach.
[...]
Tiny maps with 8 players are not going to work in many cases:
- Iberian civ bonus walls will overlap/be so close to each other that they shoot at each other from the beginning
- There will not be enough room to build a full base
- There will not be enough room to place much more than the recources close to the start positions
There is a forest heavy map: Deep forest. But if generated as a tiny map with 8 players most of the map space will be covered with free space from bases and roads. There can be seen that tiny maps with 8 players leave no room for much map design.
Perhaps the Iberian walls should be replaced with the smaller circle of towers (used for some maps without enough space already) if the map size is tiny and the number of players is > 4 (and perhaps on small maps with more than 6 players too).
In general give the players enough space to build their bases would be nice.
Perhaps it should be considered to place only chicken/pigs/sheep (or similar) and a few bushes/trees in a 20 rms tile radius around the players start locations (and their starting entities ofc
) and nothing else. That way the player would have to scout for stone/metal and the game would have another early challenge and scouting would become more vital. That does not need to be a convention, just an idea for some maps.There are some design tips here: http://trac.wildfire...m_Map_Generator
-
that wasn’t about really opening the gates, but a trick(a hack?) to get the pathfinder working with dynamicaly opening gates:
when the door is closed, it blocks tiles->the pathfinder sees blocked tiles->doesn‘t find a way through the door(since it is closed atm of the pathfinder query); you see the problem!?
so your(as a player) pathfinder should see the gates as always open(until force-close or something is triggered) to allow routing through them.
in reality the gate is opened when the units arrive and closed when they go away, and only in this timeframe the door is really open(so enemies could pass)
but the enemy shouldn’t see your gates that way, because if the enemy pathfinder would, you would almost always stuck your units at enemy gates(and vice-versa)
Ah, ok. That still leaves the problem with the player dependent obstruction mapping. But if it can be done...
-
Working out if they can access a resource is tricky. I think I will need to monitor units trying to gather and set a time out value so the resource is marked as inaccessible if they have been trying to reach it for too long without managing to gather from it.
I think this should be inside the unit AI. It should give back some "unreachable target" signal/state IMO.
-
I think switching to rmgem for simulations has been discussed before. Personally I think its a great idea; more variety. But not all the maps have to randomly generated (e.g. campaigns, certain scenarios, etc).
Ofc. save/load maps have to be supported in simulations as well, yes. That was AFAIK the reason why all the map stuff is not inside simulation.
Not sure: Is the map loaded befor the engine is run? And a new map can only be loaded after the engine is closed again?
-
One problem I noticed is there are a bunch of females standing around. I investigated their UnitAI state (open the Developer overlay with Alt-D, check "Display selection state" and select something) and it said "gathering". From the gather target entity ID I was able to find what they wanted to gather. It turns out that map generates some chickens inside the foundation of the civil center (use Alt-W to toggle wireframe mode to see this), and because they are the closest target to the civil center dropsite, all these workers are trying to gather from it but failing. That in turn economically cripples the AI.
It's just a bug in the Deep Forest script, I'll create a ticket for this. Thanks for reporting it
Hm, yes, my fault. I noticed that before but didn't think that would cause problems. I'll fix it...
The random map script takes care of no entities are outside the walkable map.
-
Nice diagrams
Side note: I still wish we could create roads as I've said before. Just to make our towns and cities look better.Thx
Roads can be placed with this as well though crossings are not supported well, yet. I'm arguing with some team members to move rmgen to simulations and perhaps make things trigger based. Then all functionality could be used everywhere like placing roads in-game or at least in Atlas. It's a big change though I think it's worth the effort since it's payed back with much more functionality and easy to change/add features without duplicated code. I'd do/help doing that but simply feel overwhelmed ATM doing this alone. vtsj checks the code/documentation/concept this days so maybe he has other ideas or knows better how to do this. I will stick to rmgen ATM.
-
Attack rate/time and range should be shown at the same place as the attack.
-
Working on a documentation PDF to make the concept of the wall builder clear because I find it hard to describe in words.
Here's an early version: http://fexor.dyndns.org/files/wall_builder_concept/wall_builder%20concept.pdf
-
i agree with the idea that you have to manually close them. I think that would be great, and would make the game more difficult in a good way. Surprise attacks would be more surprising...
Programing wise it wouldn't be hard to implement. When you have a sprite, or a unit of area, you set mapstate or whatnot.
If gate = "closed" then
maparea = 1
else
maparea = 2
endif
If you have to deal with the detecting friends and foes, the coding becomes all the more difficult with pathfinding etc. Keep it simple, let the user close and open the gates.
That way you would still need multiple areas to update for the pathfinder. It has to take care of moving/dynamic objects anyway so you could just place a blocking "gate door entity" when the gate is closes and remove it when it's opened. So a gate would be like 3 entities: 2 for the parts that always block (walls at the edges) and one for the center part that only blocks if the door is closed. I don't know if it would be easier to remove the center "gate door entity" or lower it's collision radius to 0 (or remove it's footprint).
-
The idea is to make a special material just for slopes to avoid using this everywhere.
Whatever you see that looks odd, it's most probably intended. When used like this, the triplanar effect is a trick that removes one type of artifact (the stretching) and replaces it with other artifacts that are hopefully a lot less noticeable..
Edit: Or maybe it's not intended... I'll look into it.
For sure it looks better. And I guess theres no way to avoid textures in non-right angles towards each other (and the textures where originally not meant for that). So at the bottom and top (where the effected terrain meats the unaffected parts) textures doesn't line up well. Still it's better than the extreme texture distortion without the effect.
EDIT:
Cliff textures and "multi-planer" can be combined for super basic "biomes"
That would a normal ground type:
Then a biome would select different versions of the above based on the angles things faced. You could do things like
- 75-90 degrees vertical: granite rock
- 180-270 degrees (z-axis rotation): snow+grass (south facing has less snow on ground)
This would sort of blur the distinction between manual and generated maps, making both tasks easier. Of course, if map-makers didn't like the way something looked, they could override with a forced normal ground type too.
Great idea!
The problem is: It has to be implemented twice: Once for simulations to be used in atlas and once for the RMGEN part (since it has no access to simulation AFAIK).
I think it would be highly valuable to think of fusing RMGEN into simulations. So one could add e.g. a circular wall in Atlas by drawing a box.
- 75-90 degrees vertical: granite rock
-
OK, I actually look a look at atlas, I believe with the current resolution, both heightmaps and vector fields will inherently look about as unrealistic as height maps do now. You may fine some things better with vector fields, but unless you seriously "steal" vertices from flat areas, you just need more data for realistic terrain.
On a related note, I think it would be really could get an erosion in atlas (and for random map generators). http://ranmantaru.co...ghtmap-terrain/ seems to have a pretty good idea, and it includes the full source code. (though personally I think the result would be better if a few constants were tweaked).
Isn't that for erosion over time? So you could add a painter for that to Atlas and a function that can be used for random maps (though only the result counts here, not the process over time). If triggers are in terrain could really use erosion at game time ^^.
-
Already done, though I guess that last pic was a bit messy. How about this one:
Triplanar + normal mapping + specular mapping. The stretching problem is solved.
I should note that triplanar texturing is a pretty GPU intensive effect: it replaces every texture access with 3x accesses, and memory access is pretty much the slowest operation. I think I'll make it so it lives in a separate material of its own that is used for cliff textures..[...]
That looks much better on slopes!
Is the effect used for every terrain texture tile? Because if I get it right it's mainly helpful when the gradient of the terrain is high and so might only be used there. Then the resource needs might be not that much of an issue.
It seams like not all textures are in a right angle towards each other. This could look strange at the border sometimes I guess?
-
you would need a player-dependant obstruction map for player-dependant pathfinding(I don’t know hard to implement that would be)[multitheading idea: 1 pathfinder per player with it’s own obstruction map]
own gates are always passable for own units(unless gate is locked, so units would walk through gates as the pathfinder finds a path through it) and only passable for enemies when it is in 'open' state(maybe even when in LOS too, but thats LOS dependant pathfinding, probably a bad idea)
What would be the advantage of "opening" gates if your own units can pass them anyway? Pathfinding is already hard to do, so I don't think complicating it further would be wise.
-
Dude I love that video! I saw it a few months back when I was doing some research. I find it funny how they just mock the problems, really takes your mind off of them. Watch their
about the Zeitgeists vs Paul on the economy
All of them are great, yes. Just chose this one.
And I love how the character Robert Foster gets on the one hand confused by his interview partners (somehow taking their point of view serious) but in the end stays critical. This somehow shows the process of realization. He does not really "know better" afterwards but he might have a clue that most others telling they would "know" it better don't either. Especially if they have a wide medial presence. I think there are two kinds of people needed to solve complex problems: One type to solve it or at least find a serious possibility to better it and the other to widely spread it so it gets backed by a broad community to have any chance of getting social reality. I guess both abilities are seldom found in the same character ^^. So the problem stays: How to connect the first type with the second?
-
I don't like rap but I like this!
-
Just to post where this discussion went:
The code changing the placement angle of units are in map.js line 330.
The documentation is here.
-
Well, I can't see an attach files button.... hmmm....
I miss it to. AFAIK it's just allowed to attach files in some areas of the forum. But you can always use a link if you have any other webspace to put the file.
-
What about generating the circle as a primitive, without the use of a texture? This way it would scale to any resolution.
Isn't a texture (and/or model) scalable???
RANDOM MAPS: Suggestions, Bug reports and Ideas about random maps here.
in Scenario Design/Map making
Posted · Edited by FeXoR
I will change "placeCivDefaultEntities" to call "createStartingPlayerEntities" to reduce duplicated code. Thx Spahbod for pointing this out. In addition I will add a keyword argument (like the Iberian civ bonus walls are already) for the entities to place so it is possible to do everything with one function. The common case will always be supported without keyword arguments though.
@vts/vtsj: It would be nice to have your changes of documentation in the wall builder. It was good!
Afterwards I will fix the issue I found while trying to explain the wall builder: http://fexor.dyndns....r%20concept.pdf. It's not really an issue ATM but ofc it should be clean.
There's still the problems with entities at the edges of the map (e.g. Anatolian Plateau: Trees). Even if they are reachable only few gatherers can harvest from them. That often results in stacked peasants that block each other. On tiny (and maybe some small) maps the Iberian civ bonus wall reaches out of the map, too. I think it would be good to add a function in rmgen that removes all entities outside (and at the edges of) the map. That could then be called before exporting the map. I'm not sure if some sort of "removeObject" function exists. I'll look into this. That function should always warn (or at least log) if any entity is removed to help rms programmers to notice what they can do better to avoid placement outside/at the edges of maps.
A related thing is that it is possible to place overlapping entities. It would be good to add a function that places an entity and removes all entities overlapping with it. Ofc that would need an "removeObject" function as well and the information of the space each object needs (which AFAIK is not available in rmgen ATM).
The AIs have problems with entities surrounded by other entities as well. This is very common on any map (scenarios too) e.g. a tree surrounded by other trees. I think it's an AI problem, not an rmgen problem, but just wanted to say it here.
It seams like areas surrounded by cliffs are somehow common in random maps though I think they are very unlikely in reality. besides: Unreachable areas should not contain any entity that can be gathered from.
Many rms don't grand enough space to the player's bases. There's a section "Design Tips and Conventions" at http://trac.wildfiregames.com/wiki/Random_Map_Generator. It would be good that experienced rms programmers would add ideas here (or directly at the wiki) that would further enhance general rms design.
I'm thinking of adding a function to load scenario maps into an rms. That way one could use a scenario but still could choose the civilization free. The other option would be nice as well: Exporting a random map script and save it as a scenario. This can be done in atlas already but I think it would be nice to have as an rmgen function as well. The problem is that I don't know a way to define the payers civs in an rms.
I would like to have support for a heightmap/erosion given by an image like myconid suggested here: http://www.wildfireg...howtopic=16233. That would increase the realism of random maps much!
Is there a method to determine if a player chose "random" civ?
Those are mainly some thought. I will be gone for the next 3 weeks so I will get to it afterwards.
If any other changes to rmgen is needed plz let us know. I am desperate to add new stuff after my brain was useless for about 2 weeks since I was ill ^^.
P.S.: I will do some of the above but if anyone is willing to support me with adding triggers that would be even higher priority to me. The result of that would be extraordinary! I tried to make that clear here:
http://trac.wildfire...1449#comment:20 (skip untill "The perfect world")
and here: http://www.wildfireg...showtopic=16096
EDIT: After I was told again that it was thought about triggers and definitely pushed to part II I'll try to shut up