FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
alpha123: Thanks for this patch!
Any drawback in performance to speak of?
Now that exponential armor is in I'd recommend to do the same for damage upgrades.
Damage would be then calculated like: BaseDamage * 1.2 ^ numberOfDamageUpgrades
(Again 1.2 is just an example and could be any number greater than 1. It should just be slightly greater though)
This is a lot less needed then the armor upgrade change but has the following advantages:
- Balancing will be a lot easier because everything scales independent on the number of upgrades
- An upgrade effects all units (this upgrade applies to) the same. (This only is true if floats would be used for damage and health but using floats only for the calculation of health loss while base damage and health stay integers would be fine as well)
What to keep in mind:
- It still might be good to scale up base damage and health by a factor of 10. That way we'd get at least another decimal point precision (while keeping base damage and health as integers). That is not really needed though as you can see below.
- I chose 1.2 as a basis because a damage upgrade is than stronger than an armor upgrade (To be equally strong it would have to be 1/0.9 = 1.11...). That way battles become more rapid with the game time (after 5 damage and armor upgrades combat will become about 1,5 times as fast/deadly). As is now (absolute damage upgrades and exponential armor upgrades) battles will take longer later in game.
- Although base damage could stay integer it might be good to show the damage in the GUI with 2 decimal point numbers. In the bottom center of the screen (with one unit type selected) just 1 value could be shown e.g. if a unit type got 7 base damage and 1 armor upgrade effects this unit type it could say "8.4 Damage". In the mouse-over a simplified calculation (with base damage + damage gained by upgrades) could be shown like "7 + 1.4 Damage" while in the manual the exact formula could be mentioned with an example for a unit type (or for all units a detailed description with a table or the calculation for all possible upgrades and the resulting damage e.g. "1 Damage Upgrade: 7 * 1.2^1 = 7 + 1.4 = 8.4, 2 Damage Upgrades: 7 * 1.2 ^ 2 = 7 + 1.4 + 1.68 = 10.08 and so on).
For me a main reason why I'd like to have this is because I like consistency
-
Whoo, this looks interesting:
http://codeflow.org/...-erosion/#video
And this, hui:
And all open source...
-
1
-
-
I would like to know if and how in detail it is planned to add and/or support collision detection and line of sight.
I read (http://www.wildfireg...showtopic=17334) that it's not planned.
IMO line of sight and collision detection (for projectiles mainly. Units could be handled by the pathfinder) is a quite basic feature of an engine to be realistic. That doesn't necessarily mean everything should be checked for collision/sight blocking (as said in the post). Line of sight calculation for rough terrain and buildings would do I guess. About the same for projectile collision.
AFAIK collision detection with the terrain is already implemented (arrows that miss stick in the ground).
I'd appreciate a small information about what is planned and what is already in concerning this.
-
1
-
-
@historic_bruno: Your scepticism is justified. However, after having sane base terrain generation I intend to write some functions to make the flat parts more flat and the rough parts more rough. That way cliffs will form that are unpassable and a greater part of the map will be more suited to place buildings. Additionally woods and rock formations can be set to change passability. How well all that will turn out in the end is to be seen.
IMO the reason for most modern RTS games not having random maps is that they likely don't have eyecandy areas. Note that most 3D RTS games don't allow to zoom out far (with few exceptions) so that those areas have to be small to be noticed.
However, I don't think that should be our concern here why or if other RTS games do something or not. If something in another RTS game worked well we should think of adding it. If something went very wrong we should try to avoid it. But just because it does or does not appear often is not a criterion of quality at all.
-
1
-
-
Here's a screenshot of some random terrain that came out while trying to get a working hightmap manipulation library.
(2 sec.generation time, no erosion applied)
-
4
-
-
Here's a version with a much cleaner and easier to read function. It also does not need any additional function so in principle could be copied and pasted anywhere and be used (for the map the rmgen library is still needed though). It still only produces riverbeds if the strength is set so high that interference appear. However, to clean up the interference only one decay erosion (so only a range of one tile) is needed (and not the evil hack like in the last version. Definitely a progress:
To play with:
The function in question: getWaterErodedHeightmapStandalone line 783
Parameters to play with:
- Number of erosion processes: Line 969 (currently 200)
- The attributes the function takes: Line 1015 (description of the attributes in the line before)
- Smooth the noise: Document in line 1021 (Applies a simple decay erosion once. Rivers will be harder to see but are still there)
- Where the magic happens: Line 869 (Here the question is: What's the correct function? E.g. just multiplying the current version with 1/2 destroys all "river digging")
Not much "qualitatively" changed though.
EDIT: Some more thoughts:
Information we have:
- Slope := Dh = (dh/dx, dh/dy)
with h = height of ground, D = Del operator, d/dx, d/dy the partial derivation in space (local) in the given direction.
(This all is meant for the borders between tiles)
- Volumetric flow rate: Q = W*H*v = dV/dt
(We assume dV/dt depends linear on Dh and V is distributed dependent on the arithmetic mean. That might be wrong)
(We could use the harmonic mean or the root mean square easily while the geometric mean might be harder to use)
with W = tile width, H = water depth, v = water velocity in the x/y plane, V = water volume, d/dt the partial derivation in time
(This all is meant for the borders between tiles. Assume W = 1)
Information we might additionally need:
- Decouple water velocity and depth (should be easily and should be the next step)
-> Would additionally grand: water gravimetric potential energy, water kinetic energy, gravimetric force (and maybe water pressure)
(That would mean we had all parts of the incompressible Navier–Stokes equation - if that helps in any way (which is questionable) because we have to assume the water velocity reaches it's critical speed on every single tile to be constant in time)
- Water pressure (may additionally need the grounds bending)
- Stress at (near) the ground and the critical stress needed to pick up material. I'd prefer to do without it because that would mean more constants to assume/tweak.
What's to be done next (imo):
- Decouple water velocity and depth
@wraitii: As you suggested we could then use the water depth as water derivation map for the next run
- Implement harmonic, root square, and geometric water distribution (I think this might really matter)
Any ideas welcome.
-
That's looking pretty good
.I'll be on holidays for the rest of the week so I'll give a look at your code this week-end/on monday (public holiday in France).
I'll try to get stuff done until then (including cleaning up the many fail tries and debug code). I'll try to explain a bit how to play around with the parameters to test the functionality/outcome in different situations so flaws can emerge and what kinds of parameters are useful/have an effect (in the long run it would be nice if erosion functionality could be used as a global filter and a local painter for atlas and ofc. for random maps).
What if we used these kinds of "realistic" maps for a "battle" game mode? Something like Total War multiplayer where players choose their units and upgrades and fight on a battle map (no construction or bases).
That would work.
But (without any disrespect to your idea - indeed I like different game modes) my focus would be to make the entire game (including structures) work on realistic terrain (while the terrain has to be scaled to the structures ofc.), not to make a game mode working on realistic terrain. For me this is part of "historical accuracy" because indeed civilizations had to deal with advantages/disadvantages in resources/space to build etc. given by terrain, ground type, flora and fauna inside there territory.
Still there should be very balanced maps to ensure a non-frustrating (luck independent) multi-player experience: http://www.wildfireg...160#entry268242
And now I'll jump upon the code getting it by it's throat
-
Some interesting stuff: your line 674 is actually required and does all the work.
Yep, I noticed. Though I'm still not sure why.
I tried *0.5 the waterDrain variable: now it did nothing. Setting it to 2 gave odd results. 5 gave the same.
It does something e.g. smoothen everything (though not much different from erosion simulating material just falling downhill). What it does not do is "unlinking" tiles with even and uneven values of x+y - and as sad as it is I have to admit this seam to be the cause of the river like structures. I still hope though because it somehow looks to good to be just numerical artifacts.
Looking at your code, it doesn't seem too sane: first you only move the ground for x+1 and y+1, might want to do it at least for w-1 and y-1 too, if possible all 8 corners.
Yes, I've done this right away (to get rid of the even/uneven noise). The result is just smoothing out the random noise of the initial ramp (mainly). There might still be some small "rivers" but no material seam at all to be carried further then one tile which is odd after 200 cycles. The effect is so sensitive that the diagonal calculations of the water drain and the carried material has to be scaled with 1/(2)**0.5 to take into account the higher distance of the center of that tiles - otherwise diagonal crinkles appear.
And just to make that clear: I'm quite sure it is sane. For each tile I calculate the material carried over the border to it's positive x and y direction - not from the field away or towards it but above that border. So the calculation is not really done for the current field but for two borders of the grid. Calculating those for all tiles however exactly calculates each border once. Each tile might have it's material changed up to 3 times: 2 times when the calculation reaches the field (get or loose material over its top or right border), when the calculation reaches the field with the x coordinate 1 lower and the same y coordinate then the field in question (material transport over it's left border) and the field with the same x coordinate and a 1 lower y coordinate (over the fields bottom border).
So adding the x-1 and y-1 field to compare does nothing but double the effect (because all borders are calculated twice). From the quality point of view it's exactly the same.
I hoped the diagonal fields to fix the issue but that only eliminates the visual "rivers" entirely.
Secondly, the way you calculate the water drain map seems alright, but it has a side effect: it seems to me like in the current implementation this means all water will flow down to the lowest point on the map (locally), with no respect for possible pond formations… You need to take into account the water height when calculating height difference,
Yes, that's true. And I don't see another sane way to get rid if the "singularities" in local minima. However, that means I have to calculate it several loops (I think). I agree that ignoring water hight might be one real flaw though.
I think it would alleviate the effect. Furthermore, you should make each square retain a little water (percentage) so you will get some rivers as you can keep track of where water runned before going down. If you then use my method of recreating the water drain using the first water drain distribution, you should get really good results.
Otherwise seems fine.
edit: or keep adding water each frame uniformly as if it was actually raining, losing a little every turn too to simulate absorption.
Sounds like a good idea.
Just to explain why I chose the "static" version with the water not added to the fields height: This calculation is somehow the lim(t -> inf; integral(0 to t; WaterVolume/time)) for a static heightmap on each tile (which seamed nice). But indeed this describes only the unnatural case that no water is "lost".
THX much for your reply. I thought I was totally stupid not to find the cause. But you hit mainly the same points as I did so I seam to do at least some things sane.
Rewriting the water drain and adding a field that contains all information "unshifted" (so for example each field contains 4 slope values - for each border of the field - rather than just 2 for the borders towards positive coordinate directions just to make sure therein lies no problem).
EDIT: Though somehow "cheated" (and still a bit noisy) we definetly got some rivers going here:
Some seeds might be not so good so try 5 or so out: The screenshot is from seed 7752.
The "hack" is from line 1073 to 1094. It splits the map in two maps, one only containing tiles with even, the other with uneven values for x+y, then applies a non-linear function to the height values (x³) and finally fuses them back additive to one map. That strengthens the structure otherwise barely to see and this is something looking quite like riverbeds. Note that this only seams to work for a "strength" parameter of exactly 1/4.
@wraitii: The "multi way" calculation of material movement is in there but documented out. Not much more done yet.
-
FeXoR: I don't think you posted the files.
Oh, maybe I posted an old version, so again:
What do you mean by the "resonance"?
Tiles with even values for x+y are somehow independent of tiles with uneven values for x+y
I had something like this before and it turned out that the implementation indeed handled x and y comparisons totally independent on each other. In principle there is nothing wrong with that. But in some cases they are not only independent in a single call of the function but stay independent over multiple applies. That can cause "resonance" in space (not as normally in space and time).
First some strange screenshots (all of the same seed 710 of the version above):
First again the hightmap the manipulation started from:
for (var x = 0; x < mapSize + 1; x++)
for (var y = 0; y < mapSize + 1; y++)
myReliefmap[x][y] = x + randFloat(- mapSize / 10, mapSize / 10);...so just a ramp increasing towards x direction with a noise of an amplitude of 1/10 of the total height difference:
Then we apply the changes of the functions mentioned in my previous post and get (with seed 710):
Added code as final heightmap manipulation:
for (var x = 0; x < myReliefmap.length; x++)
for (var y = 0; y < myReliefmap[x].length; y++)
if ((x+y)%2 == 0)
myReliefmap[x][y] = myReliefmap[(x+1)%myReliefmap.length][y];This sets all fields with even values for x+y to the height of the "next" field with uneven value for x+y:
for (var x = 0; x < myReliefmap.length; x++)
for (var y = 0; y < myReliefmap[x].length; y++)
if ((x+y)%2 == 1)
myReliefmap[x][y] = myReliefmap[(x+1)%myReliefmap.length][y];This sets all fields with uneven values for x+y to the height of the "next" field with even value for x+y:
for (var x = 0; x < myReliefmap.length; x++)
for (var y = 0; y < myReliefmap[x].length; y++)
myReliefmap[x][y] += myReliefmap[(x+1)%myReliefmap.length][y];This now adds the height of the "next" field (so even if the actual field got an uneven value for x+y and the other way arround) to the actual fields height:
...so there is nothing but some noise at the places I thought to see rivers ...otherwise it's just a smoothed version of the original ramp.
And just for comparison:
for (var x = 0; x < myReliefmap.length; x++)
for (var y = 0; y < myReliefmap[x].length; y++)
if ((x+y)%2 == 1)
myReliefmap[x][y] += myReliefmap[(x+myReliefmap.length-1)%myReliefmap.length][y];
And than I didn't believe what I saw:
for (var x = 0; x < myReliefmap.length; x++)
for (var y = 0; y < myReliefmap[x].length; y++)
myReliefmap[x][y] += myReliefmap[x][((y+myReliefmap[x].length)-1)%myReliefmap[x].length];...so this is mainly the same as before just adding the height of the field with 1 lover y value instead of this with a x value 1 higher, but:
I might miss something here because it looks exactly like:
myReliefmap[x][y] = x * y;
But I don't get what's happening here!
No signs of flaws left, btw.
Well, at least I got some nice shapes x)
Trying to link them by adding diagonal calculations...
(Who can explain the last picture is my hero for the day!)
(Who can fix the functions is the hero for the week!
) -
This is the hack WORKING!!!
...somehow...
Now we have to get rid of the resonance...
(Seed 710)
(I made a mistake before: I assumed getWaterDrainMap() returns the amount of water that drains through a tile. But it return the amount of water that drains through a tile per time! So the waters speed is already in it!)
wraitii: The ramp was a good idea. I'd never have chosen values needed to get rivers if I had used a more natural heightmap because I had never seen there actually is something (because of the resonance).
The used functions are only:
getWaterErodedHeightmap() line 684
that uses getWaterDrainMap() line 603
...so that should be quite easy to debug... *hope*
NOTE: The many lines commented out in getWaterErodedHeightmap() are the version assuming getWaterDrainMap() returning the amount of water only, not the amount per time (which was wrong, see above).
EDIT: Additionally not all tiles are taken into consideration (the last raw and line) in getWaterErodedHeightmap(). I fixed that but it does have no effect on the resonance.
After the fix I'm quite sure getWaterErodedHeightmap() is correct so the problem has to be in getWaterDrainMap().
-
I suggest you try this erosion on a tilted plane with minor differences in height level and check how it looks like.
Yes, I thought about that too.
Result (pretty equal with all functions including your proposal of applying getWaterDrainMap result as the initial water distribution for another run):
...so still no riverbeds.
What I actually do:
myReliefmap = getDifferenceOfFields2D(myReliefmap, getDiv2d(getProductOfFields2D(getRescaledField2D(getWaterDrainMap(myReliefmap, 0), 1), getGrad2d(myReliefmap, false))));With:
- myReliefmap: The heightmap the erosion should be applied to (a scalar field).
- getGrad2d(myReliefmap, false): The slope vector field (the 2D projection of the normal vectors). I assume the water speed between tiles depend on the vectors length (which might be wrong since it might be the square of it or something). The second argument just means that the field is generated assuming myReliefmap is not "wrapped" (top +1 = bottom, right +1 = left).
- getWaterDrainMap(myReliefmap, 0): The amount of water draining through each tile (calculated downhill, a scalar field). I scale this to have a maximum value of 1 (with getRescaledField2D) and than scale the slope with that (with getProductOfFields2D() assuming the amount of material carried by water equals the waters impuls = amount * speed [assuming its density is 1]). The second argument is the "seepage" (how much water sinks into the ground and so is lost to run further downhill each tile it passes).
- getDiv2d: Calculated the amount of material carried from one tile to the other downhill. Second argument is "wrapped" like in getGrad2d().
- getDifferenceOfFields2D: Actually applying the change to the heightmap.
NOTE: The only real difference between this and "decay erosion" (where just some material "falls"/"rolls" downhill) is that the slope field is scaled with the amount of water gathering in "channels". This is (in opposite to everything else) a global effect and so takes much longer to calculate.
What we might miss is that we need to calculate the "pressure" of the water towards the ground. That would be proportional (maybe not, maybe square or something) to the "bending" of the ground (where the water is driven upwards - in holes with positive bending - it carries away more while leaving material where it's "falling" - on hills/ledges with negative bending). Not sure right now how to calculate it though it should be similar to how to get the slope by grad(heightmap). So the bending would be the differentiated slope field (this cannot be grad because the slope field is a vectorfield though).
So small "hills" are lengthened downhill (the direction the material is transported) while shortened uphill (since there will be a "hole"). Mainly the same thing with holes (dug out downhill while filled uphill). That's what may "dig" riverbeds. (For physicists: The second-order term might be needed to generate riverbeds). EDIT: Indeed the pressure is (at constant density) the square of the speed.
I can't find any formular for this (material carried away by water "raining" down equally distributed on a given heightmap). Instead I find tons of formula to calculate the waters pressure, speed, density (though it's nearly incompressible, tztz) dependent on each other or the width of riverbeds dependent on the amount of water etc..
Further thoughts:
Maybe it's:
div(grad(heightmap)) * grad(heightmap)²
div(grad(heightmap) / abst(grad(heightmap)) * grad(heightmap)²)
div(grad(heightmap) * grad(heightmap)²)
div(waterAmountField * grad(heightmap)) * grad(heightmap)²
div(waterAmountField * grad(heightmap) / abst(grad(heightmap)) * grad(heightmap)²)
div(waterAmountField * grad(heightmap) * grad(heightmap)²)
???
(I assume here that the water speed equals the slope = grad(heightmap). If anyone knows PLZ tell me!)
EDIT: V should be proportional to heightDifference**0.5 so V² proportional to dH proportional to p...
1/2 m*v² + p + m*g*h = const (constant energy) while E(pot) just drives the process (and should not have any impact on the carried material)
So p*E(kin) proportional to waterAmount * dh**2 might be the amount of material carried...
Makes: getWaterDrainMap(heightmap) * grad(heightmap)² (this has no direction though so * grad(heightmap) / abst(grad(heightmap)) or simply calculate it by directly comparing tiles...)
So still no real clue and any input welcome.
-
Hm. I got it working (as far as I can tell as I planned).
Some screenshots and the evolution of the map after a different number of water drain erosion steps:
[steps: 0 (just a random heightmap), 1, 2, 5, 10, 20, 50, 100, 100 (zoomed out)]
...so it somehow works. There are still no signs of "riverbeds" though x)
I tried to apply it to a more smooth heightmap (like the one in my last post) but still no riverbeds.
Maybe I have to take into account material of different hardiness?
At least it gives a quite different shape (more spiky hills and more flat low areas) than the other erosion functions (though it's quite slow ofc.).
I don't understand the effect of the "seepage". It only seams to strengthen (lower values) the effect so higher seepage but more loops give about the same result as before. (If I rescale the water drain speed field to a fixed value before applying it changing the seepage does seam to have no impact at all).
Maybe I'm doing something wrong again x)
However, I am not entirely sure that the library functions work properly or can be defined better/faster etc. so if someone would be willing to look through at least the 2D part at the end that would help me greatly.
Any help/suggestions/ideas very welcome!
-
Help! I got stuck with erosion functionality somehow...
There are generally some different (abstract) erosion types:
- Decay erosion: Caused by sun, gravity and slight vibrations of the earth. Implementation: Easy and fast.
- Directed erosion: Caused by wind or sun mainly coming from one side. Implementation: Fast but not that easy to adjust by parameters.
- Water drain erosion: Caused by rain draining downhill forming rivers and gathering in pits. Implementation: Slow and not really working at all.
Maybe I didn't find a good approach at all for water drain driven erosion. I mainly implemented some general functions to handle calculations for scalarfields and vectorfields. I use a discrete version of vector analysis which may in the end be a bad way to do this. Maybe an algebraic approach would be better and faster.
Here's what I got:so far:
Some basic functions for discrete vector analysis. The first part works for any dimension but is emmensly slow. So I added some 2D functions that are much faster later in the file.
A random map to test things (very unorganized, sorry). In it many ways to simulate and apply the different types of erosion and visualize the multiple fields. The only function that seams to work for water drain erosion is getWaterDrainMap(). Uncomment line 858 to paint it (for color code see drawFieldAbsOnTiles() line 165). However, I can't seam to find a way to scale it right to do something sane. BTW: It ignores the height of the water so in pits it's somehow singularly.
(For a little orientation: Functions ending with DVA are extremely slow so avoid them. Functions without DVA and 2D are (more or less) stand alone functions not needing discreteVectorAnalysis.js )
I tried to avoid "multi step" water drain simulations (like suggested by myconid) because they are so slow. Maybe it sinply can't be done without multiple simulation loops for each erosion step.
If anyone has any idea or information about how the transported ground material depends on the amount of water and it's speed draining through this field - that would greatly help! As well I'm not exactly sure how water speed depends on steepness (and/or how water distributes depending on it).
Screenshots:
Just a hightmap formed by decay erosion:
Water drain field on the same heightmap (water removed to see the bottom of pits):
Color code: Amount of water draining through the field: yellow (not much), neon green, green, light blue, blue, purple, red (very much)
-
Skirmish maps will not rely on triggers in any way. They will likely just be a variant of scenarios.
True.
But I don't think it's a good idea to have 3 ways to initialize a map.
A rough concept (nothing more than the order of things) I have in mind would be:
1.) Generating abstract map data structure: This would include the terrain and placements of entities (if any). If it's a random map just an empty map is generatet fitting the settings in the RMS .json file. If it's a scenario it will be (more or less) entirely loaded after this stage. For skirmish maps just some entities has to be replaced later.
2.) Map manipulation: If it's a random map script some manipulations are made to generate the map. For a skirmish map the "placeholder" entities of the start positions are replaced with the appropriate entities. (When we have triggers implemented they could be add here for custom scenarios etc.).
3.) Loading the map: Now that all map data are present actually load the needed entity templates and the terrain art etc. and initialize the game.
That way we only have one way to load maps. Additionally all the RMGEN stuff could (not need) to be done with triggers (as far as all needed functions work with the abstract representation of the map and don't need the art etc. loaded. Entity templates might be needed earlier on though e.g. for obstruction/terrain analysis for AI and stuff, not sure here).
If all map types are initialized the same way it would need to be linked in a similar way so it also might get easier/more urgent to make shared libraries like mentioned here: http://www.wildfireg...showtopic=17052
-
This is planned, I think the term skirmishes has been used. It requires some support in the editor, so you would place a special entity which gets replaces by the correct civ's starting units/buildings when the game is created.
This also happens to be related to a recent post of mine: http://www.wildfiregames.com/forum/index.php?showtopic=16887&st=80#entry268738
...because random maps and scenarios happen to be initiated differently. So I think it would be good to grab this issue by it's roots.
-
2
-
-
We must be opend mind, in order to satisfacy many types of players, I ask my friends why don't try 0A.D, they says, don't have spaceships, don't have Japan feudal faction, don't have elf faction, it's not DOTA. age of Mithology etc.
Yeah more mods more fans, and all that can be traduced to have more contributors. The important thing is attract audiences.
...and for that we need some quite fundamental design decision - the earlier the better, the later the more over all work.
My last related post concerning this (with links to older ones): http://www.wildfireg...showtopic=16887
-
I'm not sure but don't you think something like this is "discussed" better in a (so-called) "social" network or another place where it's more about opinions/believes than about developing a game?
I saw some more helping posts of you. I'd appreciate if you try to focus on that even if that might be hard for you.
-
1
-
-
I don't think triggers should be made to fit the campaigns needs. The map designer, random map generator API, triggers and player-AI-API should be as powerful as possible and general purpose tools (and not designed to work for specific needs and only work well when used as "meant to be used").
ATM only Atlas seams to head the right way (AFAIK). So we need to figure out a new "structure" for scripting or something IMO so that all parts can access any information they want (or at least as many as possible) without causing to much headache to debug (and not only those thought to be needed). In the end this will cause much less pain adding new features and less work to make all parts work well together. We have to keep in mind here that player-AIs are meant to be threaded.
I personally am horrified by the current situation where every part has it's own libs and cannot (easily) access those of another part. I explained why at various parts in the forum and in track (which was maybe a bit stupid because now I can't find most of it).
Zoot noticed that and opened a topic for that some time ago: http://www.wildfireg...showtopic=17052
THX again, Zoot!
A related ticket would be: http://trac.wildfire...com/ticket/1589
Another related topic: http://www.wildfireg...showtopic=16096
We had some discussions about triggers before and it was agreed on (to my disappointment) to wait until part 2. However, if we implement triggers they should be general purpose triggers. Otherwise I agree it's better to wait until part 2 but to implement some basic triggers - because they will be used and it will be more work (including convincing PPL that this is needed) to implement/change to more general/powerful/useful triggers.
-
1
-
-
Guys, the decorative stuff would obviously not go on the in-game GUI and take room away from commands.
In this case I didn't say a thing
-
This isn't "over the top" at all, actually. It would be neat to add these kinds of flourishes everywhere you can.
I'd like to be able to turn all graphically irritating and distracting stuff off to get the most possible space for information and interactive UI.
Don't get me wrong, I like the style! But for me this projects value is the game and it's usability. Focusing more on graphics means focusing less on playability and usability.
-
1
-
-
(Continuing discussion from http://www.wildfireg...=60#entry267877)
That's terrible for multiplayer. Unless you don't want random maps to be played in multiplayer (only the yet-to-be-implemented skirmish maps), there NEEDS to be resource balance for all players. As for different maps having more or less of specific resources, yes, that's fine (there could be a high wood but low stone map) as long as the resources are equal for all players. It can't be too extreme though, or else certain maps start to heavily favor certain civs: in your example, that map would be much better as the Gauls than as the Romans.
What I meant is:
- There should be a bunch of maps optimized for multiplayer. Those should grand the players access to all resource types and all of them should be equally hard to reach for all players. Those maps are often symmetric. Due to the focus on playability those maps tend to be quite similar and unrealistic in landscape and resource derivation though.
- There should be some maps focusing on realistic landscape and/or resource derivation as well as some maps that grand not "sufficient" access to all types of resources for multiplayer games (I think however the second this is more a question of taste than on playability). Those maps can be separated in another category like "others" while the others might go to "MP optimized" or something.
-
If I open atlas and generate a testmap of mine (not placing any entity/actor) it works fine. If I go to the player tab and than switch back to the map tab (without anything changed) and regenerate the map errors occur:
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 reference to undefined property settings.PlayerData.AIDiff
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 21 Script value conversion check failed: JSVAL_IS_NUMBER(v) (got type undefined)
WARNING: JavaScript warning: simulation/helpers/InitGame.js line 23 reference to undefined property settings.PlayerData.AIDiff
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 68 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:68 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:42 @:0
This is annoying and does not really help to indicate any problem because if the player got no units he will likely notice on it's own (without a Bot raising errors).
It would be nice if those messages could be removed.
Another question: Is there a bot "template" for the AI-API-v3 (a bot that links to the engine but does nothing)? To be an "API" I think something like this is actually a must.
-
It would be nice if the top/bottom keys and the mouse wheel would change the item in the selected drop down menu appropriate.
-
It's similar to the actor "water_log" more flying above the water than swimming if placed there. If the hight over "ground" can't be set depending on if it's placed in water or on land it still would look better IMO if sunken deeper (even into the ground).
[FIXED] Manned towers hold open gates.
in Bug reports
Posted · Edited by FeXoR
The gate should react only on mobile units, not on buildings. I'm not sure if the area of code where the gates auto-open/close functions life have access to such data. If so the fix should be easy.