Page MenuHomeWildfire Games

FeXoR (Florian)
User

Projects

User Details

User Since
Jan 5 2017, 11:29 AM (110 w, 2 d)

Recent Activity

Tue, Feb 5

FeXoR added a comment to D1642: Allow to manipulate the heightmap in simulation.

It might be noteworthy that despite the engine differences Spring Engine supports in-game hightmap manipulation and e.g. Zero-K makes extensive use of it e.g. most projectiles deform the terrain. So looking into their code and playing a few games to see the gameplay impact might help to determine the needs and outcome.

Tue, Feb 5, 12:23 AM

Jan 9 2019

FeXoR added a comment to D1599: Texture priority support for rmgen.

My last proposal also doesn't work because each tile will get it's own ID and thus priority (which is neither what I wanted nor what would look decent) ;/
(At least, since the texture IDs will then be unique they would be much faster to search for ;D)

Jan 9 2019, 2:09 AM
FeXoR added a comment to D1599: Texture priority support for rmgen.

@elexis yes, just I'd use IDs. And we also need a priority "high"/"low" (I'd actually prefer paintBelow True/False, False by default to have unchanged maps).
But scrap that for now since we can use most of the code that is present and only hook things in at two points.
(Won't enable map authors to change the priorities later if placement order does not allow the desired texture order which I hoped for)

Jan 9 2019, 1:14 AM

Jan 8 2019

FeXoR added a comment to D1599: Texture priority support for rmgen.

@elexis I agree with all of that but that's mainly about what's exported.
That priority array I keep talking about is just an IMO easier way to handle the shifting of e.g. one texture above all neighbor textures.
Placement methods can just receive "low" or "high" parameters (the default being high would keep existing maps as they are).

Jan 8 2019, 3:53 PM
FeXoR added inline comments to D1599: Texture priority support for rmgen.
Jan 8 2019, 2:09 PM

Jan 6 2019

FeXoR added a comment to D1599: Texture priority support for rmgen.

I think the usecase for basically all maps is to paint plants/grass or other textures that are "higher"/have a more uneven "surface" above flat textures like e.g. sand. (For that we don't actually need to give the map editor much control about texture priority though.)

Jan 6 2019, 4:15 PM
elexis awarded rP22028: Remove excess argument from shift call a Like token.
Jan 6 2019, 4:09 PM

Jan 5 2019

FeXoR added a comment to D1589: Get rid of TERRAIN_SEPARATOR.

I'm sorry for the confusion that I may have caused because this should have been a plain:
A) I agree with both of you to replace the actor/entity combination strings with objects. Just that { "texture": tForestFloor, "entity": oPalm } would do. Using simpleTerrain right away would also do in cases where there is no array.
B) In the long run (likely a later patch) the simpleTerrain and randomTerrain should be used (what was what I was talking about but is not really related to this patch, so sorry.).

Jan 5 2019, 8:38 PM
FeXoR added a comment to D1599: Texture priority support for rmgen.

Oh, and if a map doesn't want to use texture support they could be just pushed to the list I keep talking about and the resulting behavior will be as it was before this patch ;)

Jan 5 2019, 7:18 PM
FeXoR added inline comments to D1599: Texture priority support for rmgen.
Jan 5 2019, 7:13 PM
FeXoR added a reviewer for D1577: Harbor rewrite: FeXoR.

Removing dependencies without much duplication sounds like a good idea to me, yea.

Jan 5 2019, 6:38 PM
FeXoR added a comment to D1589: Get rid of TERRAIN_SEPARATOR.

Well, I think there are 2 types of random terrain that would be useful:

  1. An array of multiple objects/associative arrays (key/value pairs) of exactly one texture and (optional) entity/actor each
  2. An array of multiple textures and entities/actors to result in a random combination of those

So in the end we would have

  • A "simple" terrain (one texture, no or one entity/actor)
  • A random terrain (multiple textures and multiple entities/actors combined randomly)
  • An array of multiple of those two (resulting in more control over terrain/texture combinations while still being random)
Jan 5 2019, 6:23 PM
FeXoR committed rP22028: Remove excess argument from shift call.
Remove excess argument from shift call
Jan 5 2019, 5:54 PM
FeXoR closed D1675: Remove excess argument from shift call.
Jan 5 2019, 5:54 PM

Dec 22 2018

FeXoR added a comment to D14: Thread the pathfinder computations to reduce latency.

Thanks a lot for everyone working on this :)

Dec 22 2018, 1:15 PM

Dec 14 2018

FeXoR added inline comments to rP21026: Cleanup TileClass prototype and use vector arguments for countInRadius….
Dec 14 2018, 3:11 PM
FeXoR added inline comments to rP21026: Cleanup TileClass prototype and use vector arguments for countInRadius….
Dec 14 2018, 2:26 PM

Dec 11 2018

FeXoR added inline comments to rP19704: Add random map Wild Lake. Patch by FeXoR. Reviewed by elexis and Imarok..
Dec 11 2018, 4:48 PM

Nov 25 2018

FeXoR added a comment to D1660: Move Wild Lake biome specifics to a JSON file.

I agree. My intention is just to clarify if we can find something we all agree on so we can aim for that.
And this decision has some impact on this ticket that's why I'm bringing this up.
What's you thought in this, @elexis ?

Nov 25 2018, 6:49 PM
FeXoR added a comment to D1660: Move Wild Lake biome specifics to a JSON file.

We could avoid spreading map related files over different directories by granting maps directories and put all related files there.
(This is what I would understand what @elexis called "logically grouped". Group what is only used by one map into that folder including e.g. the map-preview. There are other possible logical groupings orc..)

Nov 25 2018, 5:17 PM
FeXoR added a comment to D1660: Move Wild Lake biome specifics to a JSON file.

Dunno what the biome discussion is about, this isn't a biome, nor does it claim to be a biome, but it extends the existing biomes, which I think only these two maps currently do.

Nov 25 2018, 2:04 PM

Nov 24 2018

FeXoR added a comment to D1660: Move Wild Lake biome specifics to a JSON file.
In D1660#66565, @smiley wrote:

The way I see it, this is not a biome at all.

Then don't pot it into a biome file.

This is just defining entities based on the biome.

...which is exactly what a biome does (alongside terrain textures and actors).

I do not think these should be put in to the biome files for the reason.

I can't follow that reasoning (see above). However, removing the camps and farms would be an alternative clean solution (though maybe not desired).

The next such map may not want to have Romans in the Alpine biome.

...and another map may not want to use that base texture for that specific biome. That's always a possibility. Also I'm absolutely fine with changing the entities.

So, I think that keeping this as part of the map would be best.

Could do. But then:

Nov 24 2018, 10:48 AM

Nov 23 2018

FeXoR added a comment to D1660: Move Wild Lake biome specifics to a JSON file.

I find less files easier to maintain then multiple files BTW.
Also this biome is not meant to be unique to this map.

Nov 23 2018, 7:17 PM

Nov 22 2018

FeXoR added a comment to D1675: Remove excess argument from shift call.

Thought I find the Obect[] syntax quite misleading for the content of the array is more prominent than the array itself this way.

Nov 22 2018, 11:44 AM
FeXoR added a comment to D1589: Get rid of TERRAIN_SEPARATOR.
Nov 22 2018, 11:42 AM
FeXoR updated the diff for D1675: Remove excess argument from shift call.

Change documentation once more

Nov 22 2018, 11:39 AM

Nov 21 2018

FeXoR added a comment to rP20625: Remove civ-specific hardcoding in rmgen wall-placement script..

(The obelisks are just meant to show the center e.g. to show where it is on fortress (the "center of mass") compared to e.g. regular polygons/circular where it's just the center of symmetry)

Nov 21 2018, 10:00 PM
FeXoR updated the diff for D1675: Remove excess argument from shift call.

Documentation correction

Nov 21 2018, 9:54 PM

Nov 20 2018

FeXoR added a comment to D1675: Remove excess argument from shift call.

@Stan Maybe...
I wrote if myself but I'm pretty sure someone else did wright something similar before ;D

Nov 20 2018, 10:28 PM
FeXoR added inline comments to D1675: Remove excess argument from shift call.
Nov 20 2018, 10:21 PM
FeXoR added inline comments to D1589: Get rid of TERRAIN_SEPARATOR.
Nov 20 2018, 9:56 PM
FeXoR requested review of D1675: Remove excess argument from shift call.

Now this should really be tested in action with maps but I don't know how to change the test plan or the title.
Caledonian Meadows uses this. Generate some maps, if no paths cross each other it should be fine.

Nov 20 2018, 9:31 PM
FeXoR added inline comments to D1675: Remove excess argument from shift call.
Nov 20 2018, 9:27 PM
FeXoR updated the diff for D1675: Remove excess argument from shift call.

Added using Vector2D.distanceTo() to simplify code.

Nov 20 2018, 9:24 PM
FeXoR added inline comments to D1675: Remove excess argument from shift call.
Nov 20 2018, 8:26 PM
FeXoR added a comment to D1589: Get rid of TERRAIN_SEPARATOR.

At the moment we have:

  • Terrain strings, those containing the terrain separator
  • simpleTerrain objects
  • randomterrain objects
  • Texture strings in the Map object
  • Terrain entities in the map object

did I miss something related?

Nov 20 2018, 1:25 AM

Nov 19 2018

FeXoR added inline comments to D1589: Get rid of TERRAIN_SEPARATOR.
Nov 19 2018, 11:13 PM
FeXoR added a comment to rP20625: Remove civ-specific hardcoding in rmgen wall-placement script..

I think this is about the second line from below ind it's placeGenericFortress()?
So I guess placement function isn't able to create any sane fortress because the radius is small compared to the long wall sizes.
If that's the case it could be fixed by:

  • Change placeGenericFortress() to use smaller wall parts if the radius is smaller than the length of the "long" wall
  • Change placeGenericFortress() to have a minimum radius dependent on the "long" wall's length
  • Change the map to have a minimum radius for placeGenericFortress() (overlapping is not that big of a deal here since one still can determine if everything works in general IMO)
  • Use larger than giant maps (not so sure about this)

Likely all of the above (or similar) should be done in the end

Nov 19 2018, 1:40 PM

Nov 18 2018

elexis awarded D1675: Remove excess argument from shift call a Like token.
Nov 18 2018, 8:33 AM

Nov 17 2018

FeXoR added a comment to D1640: ConvexPolygonPlacer optimization in rmgen..
In D1640#66354, @smiley wrote:

abs might have a double meaning,[...]

What is the double meaning in respect to vectors? Different objects in math have an Absolute Value but each object type's absolute is unambiguous.

It should technically be magnitude, no?

You are correct: No! ^^ The Magnitude is a ranking and thus in general less strict than a Norm. However, the norm of vector spaces can't usually be used to order them for multiple non-equal elements can have the same absolute value (see Vector spaces with additional structure).

But length is more intuitive when thinking about 2D space.

Yea, not a big deal IMO but why not make the libs as clean and clear as possible? (And what would be more clean as mathematical rigorous definitions or more widely available like Wikipedia article's sayings?)
Also you said "let point = new Vector2D(10, 10);" would make more sense to you and there is Vector.distanceTo() ... which is exactly what I would have hoped to avoid for Points are not Vectors, They don't even have the same dimensions (Point: 0, Vector: 1, the vector spaces themselves usually have n - 2 or 3 in our case). Vectors have no distances but points have, points have no differences but vectors have, especially vectors have a length and signed direction while points have positions and relations as unsigned distances.

Although, thats a pretty extreme example.

I agree, but, well, the first thing that came to mind ;)

Nov 17 2018, 4:47 PM
FeXoR added inline comments to D1675: Remove excess argument from shift call.
Nov 17 2018, 5:04 AM
FeXoR added a comment to D1675: Remove excess argument from shift call.

I was the original author and am to blame. I checked the algorithm and, no, it isn't meant to shift by n so just an oversight.

Nov 17 2018, 5:01 AM
FeXoR removed a reviewer for D401: Stringify failed type conversation: FeXoR.
Nov 17 2018, 2:42 AM

Nov 16 2018

FeXoR created D1675: Remove excess argument from shift call.
Nov 16 2018, 11:49 PM
FeXoR added inline comments to D1640: ConvexPolygonPlacer optimization in rmgen..
Nov 16 2018, 8:17 PM
FeXoR added inline comments to D1640: ConvexPolygonPlacer optimization in rmgen..
Nov 16 2018, 8:15 PM
FeXoR added a comment to D1640: ConvexPolygonPlacer optimization in rmgen..
In D1640#66314, @elexis wrote:

[...]
I wasn't kidding when I said unrecognizable, unreadable code in the sense that it with only few operations can sometimes takes hours instead of 5 minutes to understand the geometric meaning of a handful of vector operations.

And I wasn't when I said it's an obscured property of the reader, not the code. But since I agree with you and smiley seems to join us I don't see a problem here. And thanks for your devotion to make the code more appealing to at least us 3 (and - I expect - most of the readers).

which part of this specific patch are you referring to?

I mentioned the topic of Vector algebra briefly because the patch doesn't use Vector algebra where it presumably easily could.

No need to presume since I answered your question in the first reply on your comments on using vectors: It's ranges, not vectors.
And, yes, you can use vector algebra to calculate the volume of a cuboid that has given length of edges a, s and c by choosing an arbitrary point, say O, and an arbitrary coordinate system with an orthonormal basis (hopefully) linked to it and then determine three vectors, say v_a, v_b, v_c that have the properties that v_a.dot(v_a) == a², v_b.dot(v_b) == b², v_c.dot(v_c) == c² and v_a.dot(v_b) == 0, (v_a.dot(v_c) == 0, v_b.dot(v_c) == 0 and finally volume = v_a.dot(v_b.cross(v_c)).length() if one wants desperately to use Vectors. It also happens to be a*b*c which is shorter, faster and - I estimate - more readable to most readers. Also the prototype "length" should be called "abs" because the meaning of the resulting value depends on the case the lib's code usually doesn't know - in this case it happens to be the volume. So, no, I don't agree it's always better to use vectors, even if one could. And I originally thought that would be rather a consensus than a single point of view.

(For example the inline comment, there is Vector algebra which after some transformations would probably look much more readable. Notice the ConvexPolygonPlacer.prototype.orient function didn't came across either until I lobbied on the lobby for using the cross function, you can see it in the first version of this upload.)

And what do you expect to happen now? The author is trapped in this situation, having copied the code (well, maybe just lazy) probably not easily able to convert that to vector algebra. You demanding, but not willing to do it yourself (or check yourself if your concern is valid). And I would rather write an own patch than excepting this one due to the licensing.

But "In general" is marked in bold above and I elaborated on this topic extensively to you not because the coding convention violation of this patch is so relevant, but because I am afraid that you didn't see the reason behind the coding convention yet and might let others get away with this code style in other patches or introduce it yourself in future maps, when there might not be a very good reason to. Resist the beginnings or something.

What code convention violation? And thus what code convention's reason? I'll get code "away" after checking a long list of pros and cons when the outcome is positive. While I can write the list down (and had written it down for you more than once) it's still a mostly arbitrary decision - as is yours. The only difference I see is you think that "is" and I think that "I think". I don't allow patches in to "allow" myself to use that stile later myself ;D I don't even thing that far! If I want to have code that does something I write code that does that. If it makes sense to me to use vectors I do that. If It doesn't I don't.

Nov 16 2018, 7:44 PM

Nov 15 2018

FeXoR added a comment to D1640: ConvexPolygonPlacer optimization in rmgen..

@elexis : On Vectors: Uhm, yes, I agree on using vectors can make things easier and they should be widely used (Though much less to those "unreadable", "impossible to understand", " obscured or unrecognizable" for those are IMO obscured references to properties of the reader, not the code... This depends strongly on habituation IMO). But, yes. I think we are on the same page here. Just ... which part of this specific patch are you referring to?

Nov 15 2018, 6:15 PM
FeXoR added inline comments to D1640: ConvexPolygonPlacer optimization in rmgen..
Nov 15 2018, 6:04 PM
FeXoR added a comment to D1640: ConvexPolygonPlacer optimization in rmgen..
In D1640#66297, @elexis wrote:

The question is how much faster this is. It must be worth the code complexity. If it's only a fraction of a second, that may be meh.

Agreed, as I wrote.

(Also my alarm goes off when I see variables storing X and Z coordinates that arent vectors)

x1, x2, y1, y2 are x/y ranges so it's absolutely valid to store them in variables IMO (just that they are constants).

Nov 15 2018, 2:48 PM
FeXoR updated subscribers of D1640: ConvexPolygonPlacer optimization in rmgen..

So I figure this is part of #5305 which also have some data backing up the claims but not for this specific patch.
Also it would be very preferable to not having to add code that needs additional license comments so please try to wright this from your own understanding.
I don't think using pseudo code as a source for writing your own needs license reference.
What do you say, @elexis ?

Nov 15 2018, 1:12 PM

Nov 12 2018

FeXoR added inline comments to D1587: DiskPlacer improvements..
Nov 12 2018, 10:21 PM

Nov 9 2018

FeXoR added a reviewer for D1640: ConvexPolygonPlacer optimization in rmgen.: FeXoR.
Nov 9 2018, 2:56 PM
FeXoR added a comment to D1640: ConvexPolygonPlacer optimization in rmgen..

What exactly is to be optimized here? Speed?
AFAICS there's a lot more code and no tests to show the benefit.
(It also seems to be a lot more code then in the links BTW ;p)

Nov 9 2018, 2:56 PM
FeXoR added a comment to D1660: Move Wild Lake biome specifics to a JSON file.

Yea, adding a warning or at least log when biomes are missing definitions.
Otherwise I'm all for it.
Change civs for the biomes at your liking (replacing e.g. Celts in India ;p).

Nov 9 2018, 2:36 PM

Sep 25 2018

FeXoR added a comment to D1615: Adding new rmgen placers and painters and a special filter for buildings..

Thanks @nani !

Sep 25 2018, 6:07 PM
FeXoR added a comment to D1616: Random maps: Fert , Fert Mountain, Dune with preview and triggers.

@nani terrific! Thanks!

Sep 25 2018, 6:06 PM
FeXoR added a comment to D1642: Allow to manipulate the heightmap in simulation.
In D1642#65083, @Stan wrote:

Well you shouldn't be able

In D1642#65081, @FeXoR wrote:

Concerning ground below buildings: @Stan: Either we allow players to manipulate the terrain as a game feature (which is both a long shot and outside of the original design concept) or we shouldn't provide any way to the player to change the terrain (impacting passability) at all (basically what @elexis said).

Really ? I thought it was part of it since Philip made a Trac ticket for it.
Well it makes sense to use features we implement right ?
What we could do is remember the destruction caused by a building and revert it when that building is destroyed. But smiley is right it's out of the scope

Sep 25 2018, 3:49 PM
FeXoR added a comment to D1642: Allow to manipulate the heightmap in simulation.

Nice idea, @smiley .
I'd like to inform you that I requested such a feature before and was warned that the engine was not designed with this in mind.

Sep 25 2018, 2:38 PM

Sep 18 2018

FeXoR requested changes to D1615: Adding new rmgen placers and painters and a special filter for buildings..
Sep 18 2018, 12:36 PM
FeXoR added a comment to D1615: Adding new rmgen placers and painters and a special filter for buildings..

To make it more clear: I won't except this patch in it's current state without a pressing reason why to commit it.

Sep 18 2018, 12:09 PM
FeXoR added a comment to D1589: Get rid of TERRAIN_SEPARATOR.

To make this more clear: I'm for it and will review the patch when commits are allowed again.
Is that OK?

Sep 18 2018, 12:07 PM

Aug 26 2018

FeXoR added a comment to D1599: Texture priority support for rmgen.

Is the arbitrary "10" is gone? Can't find it any more.

Aug 26 2018, 7:21 PM
FeXoR added a comment to D1615: Adding new rmgen placers and painters and a special filter for buildings..

This patch contains several things that are not really related to each other.

Aug 26 2018, 2:37 PM

Aug 3 2018

FeXoR added a comment to D907: New Map - Plague Swamp.

@trigger: To encourage attacks maybe check every unit every few seconds with a random roll and maybe damage it like: if randFloat() > [units within range x of checked unit including garrisoned and structures] /100: [deal randFloat() * 10 damage to checked unit]

Aug 3 2018, 5:49 PM
FeXoR added a comment to D1599: Texture priority support for rmgen.

Yea, texture priority support is an addition that I'd like to see.
Thanks @smiley to pick this up!

Aug 3 2018, 5:23 PM
FeXoR added a comment to D1492: Abort instead of throwing an error when dealing with empty areas..

@elexis True, so as you said: [] it is ;)

Aug 3 2018, 5:00 PM

Jul 7 2018

FeXoR added a comment to D1492: Abort instead of throwing an error when dealing with empty areas..

The comment areas.js is states:

An Area is a set of Vector2D points and a cache to lookup membership quickly.

Shouldn't it be:

  • An Area is an array of Vector2D with integer components representing tile positions as position vectors and a cache to lookup membership quickly.

for Areas.getClosestPointTo uses this.points[0] and e.g. in rmgen-common createPassage() uses arrays?

Jul 7 2018, 12:56 PM

Jul 6 2018

FeXoR added a comment to D1492: Abort instead of throwing an error when dealing with empty areas..

IMO the way to solve this is:

  • Identify the places that trow an arror when dealing with an empty array
  • Fix them.
Jul 6 2018, 9:34 AM
FeXoR added a reviewer for D1589: Get rid of TERRAIN_SEPARATOR: FeXoR.

Getting rid of a single string with a separator character is definitely a good idea independent of the same separator in the templates (though I wonder if PPL adding stuff to the templates that brake most random maps should mind a bit more about what they are doing...).
This will make long sets of "simpleTerrain" much longer (and somewhat harder to read) though so I'd wait a bit for alternative solutions that may come up.

Jul 6 2018, 9:24 AM
FeXoR added a reviewer for D1587: DiskPlacer improvements.: FeXoR.
Jul 6 2018, 9:11 AM

Dec 11 2017

FeXoR added a comment to D441: D13 collateral 5: automated test-map for pathfinder and UnitMotion behavior.

My fault, didn't compile, sry.

Dec 11 2017, 3:25 PM
FeXoR requested changes to D441: D13 collateral 5: automated test-map for pathfinder and UnitMotion behavior.
Dec 11 2017, 12:09 PM
FeXoR added a comment to D441: D13 collateral 5: automated test-map for pathfinder and UnitMotion behavior.

I did apply the patch and added the raw pmp file from this ticket. Or where should I get the pmp file from?

Dec 11 2017, 12:08 PM

Dec 10 2017

FeXoR requested changes to D441: D13 collateral 5: automated test-map for pathfinder and UnitMotion behavior.

The map doesn't load properly:

Dec 10 2017, 2:50 PM

Dec 9 2017

FeXoR accepted D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

Everything seems to be in order.

Dec 9 2017, 11:45 PM

Dec 7 2017

FeXoR added a comment to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

Offtopic:
@elexis "Phabricator also needs 30 seconds or something to add a new inline commit which I see as a sign for moving on ;-)"
For me that is a clear sign of a ill chosen web framework ^^
(...and a reason I like trac somewhat more.
But I also like phabricators ToDo list so, OK ^^)

Dec 7 2017, 12:44 AM
FeXoR added inline comments to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..
Dec 7 2017, 12:30 AM

Dec 6 2017

FeXoR accepted D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

I'm not convinced that validateStyle is needed in the first pace (and that _stone suffix) but OK.

Dec 6 2017, 3:08 PM
FeXoR added inline comments to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..
Dec 6 2017, 1:47 AM

Dec 4 2017

FeXoR accepted D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

@elexis No, there isn't an actual issue right now. I mentioned those two cases that came to mind above. I don't think this will help reducing debug time consumption and is IMO a pure limitation.

Dec 4 2017, 10:02 PM
FeXoR added a comment to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

I wanted to clarify that my proposal is only a simple solution, not the definite way to go.

Dec 4 2017, 3:24 PM

Dec 3 2017

FeXoR added a comment to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

To change the indentation of e.g. a defense tower would require to copy the wall set, change the indentation parameter and rewrite the wall alignment function.
Without the freeze and with the wall stiles constructed at import only the indent parameter would need to be changed.

Dec 3 2017, 12:58 PM
FeXoR added a comment to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

Thanks for the feedback!

Dec 3 2017, 12:41 PM

Nov 12 2017

FeXoR added a comment to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

Requested changes:

Nov 12 2017, 5:25 PM

Nov 11 2017

FeXoR requested changes to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

The wall lengths are really good! Thanks much!

Nov 11 2017, 2:14 PM

Nov 5 2017

FeXoR added a comment to D900: Remove civ-specific hardcoding in Random Map Generation Wall Placement script..

Thanks much for picking this one up @s0600204 !

Nov 5 2017, 9:46 PM

Oct 7 2017

FeXoR accepted D950: Test Vector2D.rotate with more numbers and fix oversight.
Oct 7 2017, 12:48 AM

Oct 4 2017

FeXoR added inline comments to rP11361: More random maps and FeXoR's wall system..
Oct 4 2017, 2:25 AM

Sep 8 2017

FeXoR added a comment to D877: Move placeable templates out of special/..

@elexis Ultimately, yes. But ATM there are 2 kinds of templates in the directory templates:

  • Definitions to generate entities from (in the subdirectories). Entity templates so to say
  • Perdefinitions of of a set of those (with the prefix template_), Entity template templates so to say.

Both are templates but in a different way.

Sep 8 2017, 6:39 PM
FeXoR requested changes to D877: Move placeable templates out of special/..

@Stan pointed out that since the trigger points are moved to the directory triggers the trigger prefix should be removed.
I agree since this was the default approach previously, too.
So this should be part of this commit to stay conform.

Sep 8 2017, 6:15 PM
FeXoR accepted D877: Move placeable templates out of special/..

I somehow agree with elexis meaningful folder naming.
Still I consider this is a welcome improvement ;)

Sep 8 2017, 6:09 PM

Sep 6 2017

FeXoR added a comment to D879: Trade gain related to the current map size.

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

Sep 6 2017, 11:57 PM

Aug 19 2017

FeXoR added a comment to D409: Fix the promotion healthpoint missing issue.

Thanks for the fast and pleasant feedback, @fatherbushido.
I have not looked into the other patch so please commit the two ;)

Aug 19 2017, 4:48 AM

Aug 18 2017

FeXoR accepted D409: Fix the promotion healthpoint missing issue.

This patch has been reviewed and accepted and I also agree with it.

Aug 18 2017, 5:09 PM

Jul 29 2017

FeXoR accepted D249: Fix SimpleGroup and RandomGroup placement retries.
Jul 29 2017, 9:25 PM

Jul 17 2017

FeXoR accepted D249: Fix SimpleGroup and RandomGroup placement retries.
Jul 17 2017, 4:26 PM

Jun 20 2017

FeXoR committed rP19808: Prevent height based forests to grow into player start locations..
Prevent height based forests to grow into player start locations.
Jun 20 2017, 2:16 AM
FeXoR closed D662: Prevent woods to grow into players bases by committing rP19808: Prevent height based forests to grow into player start locations..
Jun 20 2017, 2:16 AM
FeXoR updated the diff for D662: Prevent woods to grow into players bases.

Rebased after changeset 19807 (D659 committed)

Jun 20 2017, 12:42 AM