Knighttime
Prince
- Joined
- Sep 20, 2002
- Messages
- 380
For the next version of my Medieval Millennium utility libraries, I'm going to be adding a function syncKnownTileImprovements(tile, tribe) which basically just sets tile.visibleImprovements[tribe] = tile.improvements . You went the route of adding support for charting/uncharting each possible improvement separately, but (unless I missed it) I didn't see a function that would just give a tribe all of the most up-to-date info for the tile. Do you think that would be valuable to add?I've updated the General Library with a series of functions for tile visibility. I haven't updated the documentation webpage for these changes yet.
I didn't want to weigh in on this without giving people actively using the library the chance to respond first. But I think this is a good route -- much better than changing a unit type's role, which feels like it ought to be accomplished by calling a function that more explicitly intends that.I ultimately chose the throw error if the unit isn't a settler route, but that error to be suppressed with a second argument. This seemed simple and sensible, and a more complicated function would leave simple functionality of just changing a flag absent.
I wasn't aware of pcall, thanks for linking to that info. I was pretty inconsistent with error handling in the Medieval Millennium code, and it's been on my list of things to research further.makeObject.lua no longer asks for the number of terrain types for each map. Instead, pcall is used for arguments of civ.getTerrain and civ.getBaseTerrain. These throw an error with arguments out of bounds, rather than simply returning nil, which is why I previously asked the user for the number of terrain types.
Regarding number of terrain types, I've also encountered the issue of needing scenario-specific code to pass in this value to generic (scenario-independent) functions. I think it would be ideal if TOTPP exposed all of the new COSMIC2 parameters in Lua as a civ.cosmic2.* table, using the same keys as in Rules.txt. Using error handling here is a good solution in the meantime, though.
This seems like a pretty useful feature. Just curious about the technical details here: are you handling this basically the same way as your legacy event engine? Where each discrete event function gets stored in a table (or, I suppose, a separate table for each trigger), and then processed in a loop in the main block of code that contains all of the triggers?I have added "discrete events" functionality. This is so that events can be written using a similar structure to the old macro system, where each trigger is its own self contained code, regardless of the location of code for similar triggers. There is a discreteEvents.lua file, but the events could be written in any file.
For example:
...
I think people have commented in the past that the "write all events for a given execution point at the same place" it a sticking point when starting to learn Lua, so this could help solve that.
Also, this should make it easier to offer help writing code, since you can provide an entire self contained event.
But I'm a little confused by your example. How does the second definition (or third, etc.) of function discreteEvents.onTurn(turn) avoid overwriting the first one? I could envision a setup where calling discreteEvents.onTurn() and passing in a function would add that function parameter to the correct table, but the syntax you provided confuses me. What am I missing? (I know I could download the library and dig into the details, so please don't feel you have to write a long explanation if that's what I need to be doing.

Last edited: