Discussion in 'Civ4Col - We The People' started by Nightinggale, Nov 23, 2018.
Exactly and those 2 will also get their "Large Rivers" at the weekend.
So the Faireweather maps have large rivers too?
No, only existing map scenarios have large rivers.
Adding large rivers to map scripts is on the to-do of the team, however that is a huge undertaking balance wise.
Planned and looked into. However it's such a complex task that there is a severe risk that it won't be done before the next release.
Yes, but we were always hoping for a talented "Map Script Creator" which we do not have.
The balancing is not the problem and writing logic to create some Plots is also not the problem.
But to make it look good in terms of matching the map terrains and features is another thing ...
See, possible bad scenarios:
The river flow looks like a drunken pig running in circles.
The river flow looks like a marching soldier walking in straight unntatural lines
The river flow totally cuts like a cissor through terrains without caring about other Rivers, Mountains ...
The only team members we have that can write Python (needed for Map Scripts) are mainly programmers and we lack any talent for making things look natural and aesthetic.
(Our Graphics, Maps, Mapscripts, ... look like they have been created by an artifical intelligence of the early 2000s.)
I updated the cache for how many units can view plots. I also added some error checking code (asserts) and it passed the automated test as well as my manual test. We might finally be rid of the bug where some plots are left viewable even though the unit moved away.
When weather is moving, it updates the view of all units within a certain range. The vanilla code made a guess at the range at startup and guessed units can view 9 plots. I changed the code to make it assume the longest viewing unit is the unit with the longest viewing distance, which has ever been in the game. This mean it starts at 1 and increase as units gain promotions, but will always be far below 9. Not only will this update a far smaller area, it will always be big enough for the units in the game. Unlike vanilla there shouldn't be a way to break this in xml.
This turned into a much bigger fix than planned and I have been working on and off on this for a week.
Sounds like a pretty complex but very well thought design.
Must have been quite difficult to get this performant.
Thanks for putting so much effort into this.
One bug less on the list.
Ray's first steps to becoming a Civ4Col 2D graphical modder ...
So ok, I guess now that I learned GIMP again, I will be able to create a lot more 2D graphics on my own ...
Here are the first results - two button I created myself using original images from the internet as inspiration.
Buttons for Terrain Feature "Fog", and Terrain Feature "Sandstorm"
This are the original images I used as inspiration:
In the future I will not have to annoy you for such small 2D stuff anymore.
(I am now able to do it myself and it is also fun.)
I don't have much interesting to write here for the time being. I'm mostly in bugfixing mode right now. While it's good that I fix a lot of bugs, it's not that interesting for the diary. For instance the last bug was fixing a way for the natives to remove more goods than they have stored, meaning a native settlement could end up storing negative furs (or whatever). Since people didn't know that could happen, reading about it is less interesting than some new shining feature with graphics and screenshots.
I do have a todo list for new features, but I will deal with bugs first. Also I plan on looking into improving EnumMaps and InfoArrays (my custom classes for data storage) as new features would benefit from having those working better. Better as in using less memory, is faster and/or less prone to bugs.
You can still contact me if you get stuck.
Now that WTP 3.0 is released, I have moved on to what I have been planning to do for a while now: work on internals. More specifically InfoArray and EnumMap. Those two are data containers, or more specifically lists. EnumMap contains the full list and is optimized for the game asking for specific indexes (like is unit allowed to enter terrain X). InfoArray only contains the data, which is different from default (usually 0, none or false). This is optimized for looping through the list and do something for non-default values (like free promotions given by a founding father. It's usually around 1% of all promotions meaning checking all would be way slower).
You can already see the first real gameplay impact of this in WTP 3.0. The AI is way better at picking buildings to build, hence develops a better late game economy. This change is relies entirely on InfoArray and without it, this AI improvement would be way more time consuming to write, likely slower, with more bugs and also less fun for us to create.
Since EnumMaps and InfoArrays will likely be used way more in the future, I have decided to take a break from working on anything the players can see and instead fix/improve those two classes. While it might take a while, it will be worth it in the long run as it makes feature creation faster later. Also optimization in something, which will be used all the time will naturally have an impact too and I plan for more/better autodetection of bugs. I'm also going to into one major flaw, which is converting data between EnumMaps and InfoArrays is severely lacking despite it being a really useful ability.
I decided prior to the release that this is what I should do post release. I get annoyed every time I need to use one of the planned features and then I'm not making it because I have to finish the next release first.
Sounds very cool... although I didn't understand like... anything.
But I do understand that it is something very good.
Is it something that can be merged into BtS mods too? Or is it Col specific? Or it can be but takes a lot of work to so so?
Separate names with a comma.