(6-VT) allow recon to recall to capital

[Tekamthi]

Counter- or co-proposal to allow recon to pass through owned territory. They're not exclusive but we probably wanna do one or the other (if any), not both

I like the original proposal here in many ways, but there are some flaws, in that it incompletely solves the main issue it targets (recon will still get stuck, just stuck less), and it confers exploration advantages as byproduct in some cases that could be impactful.

I am not sure this will pass sponsorship phase, as there are some fine details I've only just scratched at, or am guessing at what's possible. For example maybe this is better implemented as a custom mission and not a build? I am not especially familiar with these features, it is not an area I have done much modding. Perhaps there should be a requirement that the unit is full hp, or this is only available when the auto-explore button is in greyed out status? Maybe recon should pay an xp cost? Or gold cost to player? Please scrutinize heavily, and quickly, I can only edit through the balance of today...

Proposed implementation

(Assumption: AI recognizes when it's stuck, and eventually deletes the stuck unit -- if this is not at least approximately the case please veto this proposal as it won't function symmetrically)

• recon units only
• new build: recall to capital
• build does not create any improvement, terrain type irrelevant
• build duration 5 turns
• can be initiated while embarked or on land
• cannot be initiated in any plot that already has a completed improvement (I believe a build automatically destroys previous improvement)
• if unit is attacked during the build, build is cancelled and must be started over again from turn 0
• upon completion, recon teleports to capital
• recalled recon unit cannot attack for 1 turn (ie recalled unit gets 1 turn temp malus promo)
• AI change: when AI would otherwise delete a recon cuz it's stuck, it activates this build instead

 

[Siege Tower]

I've been thinking about this since this thread a couple of months ago, and I still like this proposal more than the others I have seen. I slightly prefer my idea of having the unit teleport on the same turn but take a few turns to reappear in the capital like donating to city-states, if the unit is at full health and hasn't moved that turn, but ultimately I'm in favor of whichever is easiest to implement for the devs. There is also an added benefit that units could be recalled to upgrade rather than traveling all the way back from halfway across the world, which I think most players would agree is tedious no matter how they feel about the proposals. This would be a really big improvement to the exploration game for me, and exploring is often one of the most enjoyable of the 4Xs for me in the early-game and mid-game. I will only add that I see AI using non-recon units to explore, especially mounted units (I presume because of more movement) so it may not help them quite as much as players. I actually would like to see AI build a bit more recon to avoid using other units for recon, but that's a different proposal or just a code tweak.

 

[Tekamthi]

I slightly prefer my idea of having the unit teleport on the same turn but take a few turns to reappear in the capital like donating to city-states, if the unit is at full health and hasn't moved that turn, but ultimately I'm in favor of whichever is easiest to implement for the devs.

yeah i like that one as well, i just had to pick something here; the reason I leaned towards having it an in-place build is that this will eliminate the potential to use it to "escape" an otherwise imminent combat situation, whereas having them instantly disappear off the map might be abuseable, without other prereqs anyway. Just seems simpler doing it this way from my theorycrafting perspective -- ultimately kinda a 'dev's choice' issue, but the congress whips tend to like the proposal to be precise and certain with no 'options' or 'alternatives'. It wouldn't hurt to put it as a counter-proposal

I will only add that I see AI using non-recon units to explore, especially mounted units (I presume because of more movement) so it may not help them quite as much as players.

I'd prefer to address non-recon stuck units entirely separately, and possibly via another mechanism (ideally a little less convenient) -- I envision this 'recall to capital', if implemented, as one of the tools in recon's kit that distinguishes it from other lines -- as you say there may be other times to use it, for upgrades, or even for defence from invasion -- the latter is perhaps something that not everyone will agree upon but I would find this a positive.

Just occurred to me that rather than capital it could be origin city, as each unit records the city it was built in via existing tables. This might be preferable?

Of the optional features I've listed so far, I also like a potential gold cost to player. Will update OP with any direction that emerges from community discussion here today.

edit: i *think* you tried to link this previous discussion, but the link itself is broken. OP here largely flows from that discussion, worth a look for anyone interested in this proposal.

 

[Siege Tower]

edit: i *think* you tried to link this previous discussion, but the link itself is broken. OP here largely flows from that discussion, worth a look for anyone interested in this proposal.

Whoops, fixed now.

 

[azum4roll]

if unit is attacked during the build, build is cancelled and must be started over again from turn 0

This is not how Builds work. They don't need to be done in one go. You can even pre-build the "teleport" for 4 turns beforehand and use that as an emergency escape portal.

It also stops any other unit from building on the same tile.

 

[Rekk]

build does not create nor remove any improvement,

Essentially requires rewriting the entirety of the build code.

 

[Tekamthi]

This is not how Builds work. They don't need to be done in one go.

Plot:ChangeBuildProgress(BuildActionType build, int change, TeamID team)

another assumption of mine here: where .lua function already exists to accomplish a certain task, accomplishing same in .DLL would be trivial. Perhaps untrue, will leave it up to potential sponsors to assess.

The question this raises in my mind is whether starting a new build automatically wipes out any underlying improvement -- I suspect this may be the case, and we would have to block the build on pre-existing improvement. I don't think this matters as *most* of the time when recon will want to use this, they won't be standing on an improvement.

Impossible or so out of scope that it should be.

is this a backhanded proposal to remove BUILD_REMOVE_FOREST/BUILD_REMOVE_JUNGLE?

As I read the 'Builds' table, its perfectly fine to not define an 'ImprovementType' -- several builds already are setup this way, its nothing new. Builds table even defaults this field to 'NULL'

For reference:

Spoiler :

<Table name="Builds">
<Column name="ID" type="integer" primarykey="true" autoincrement="true" />
<Column name="Type" type="text" unique="true" notnull="true" />
<Column name="Description" type="text" />
<Column name="Help" type="text" />
<Column name="DisabledHelp" type="text" />
<Column name="Recommendation" type="text" />
<Column name="HotKey" type="text" />
<Column name="HotKeyAlt" type="text" />
<Column name="HotKeyPriority" type="integer" default="0"/>
<Column name="HotKeyPriorityAlt" type="integer" default="0"/>
<Column name="OrderPriority" type="integer" default="0"/>
<Column name="AltDown" type="boolean" default="0"/>
<Column name="AltDownAlt" type="boolean" default="0"/>
<Column name="ShiftDown" type="boolean" default="0"/>
<Column name="ShiftDownAlt" type="boolean" default="0"/>
<Column name="CtrlDown" type="boolean" default="0"/>
<Column name="CtrlDownAlt" type="boolean" default="0"/>
<Column name="Time" type="integer" />
<Column name="Cost" type="integer" default="0"/>
<Column name="CostIncreasePerImprovement" type="integer" default="0"/>
<Column name="Kill" type="boolean" default="0"/>
<Column name="Repair" type="boolean" default="0"/>
<Column name="RemoveRoute" type="boolean" default="0"/>
<Column name="Water" type="boolean" default="0"/>
<Column name="CanBeEmbarked" type="boolean" default="0"/>
<Column name="PrereqTech" type="text" default="NULL"/>
<Column name="ImprovementType" type="text" default="NULL"/>
<Column name="RouteType" type="text" default="NULL"/>
<Column name="EntityEvent" type="text" default="NULL"/>
<Column name="IconIndex" type="integer" default="-1"/>
<Column name="IconAtlas" type="text" default="NULL"/>
<Column name="ShowInPedia" type="boolean" default="1"/>
<Column name="ShowInTechTree" type="boolean" default="1"/>
<Column name="ObsoleteTech" type="TEXT" default="NULL"/>
<Column name="KillOnlyCivilian" type="BOOLEAN" default="0"/>
<Column name="IsFreeBestDomainUnit" type="BOOLEAN" default="0"/>
<Column name="CultureBoost" type="BOOLEAN" default="0"/>
</Table>
<Builds>

edit: modified OP to block the recall build in plots with pre-existing, completed improvements

 

[Rekk]

is this a backhanded proposal to remove BUILD_REMOVE_FOREST/BUILD_REMOVE_JUNGLE?

I was referring specifically to the destroys improvement part, not the creates a new one part.

cannot be initiated in any plot that already has a completed improvement (I believe a build automatically destroys previous improvement)

I checked the dll again, and I missed an if-statement. You were right originally, the previous completed improvement is only destroyed if the build has an improvement of its own (of which, your proposal does not). However, it will destroy partially built improvements.

Plot:ChangeBuildProgress(BuildActionType build, int change, TeamID team)

another assumption of mine here: where .lua function already exists to accomplish a certain task, accomplishing same in .DLL would be trivial. Perhaps untrue, will leave it up to potential sponsors to assess.

The dll's equivalent to changeBuildProgress() is called only when the unit is performing its build action. I'm not a huge fan of adding some spaghetti code in UnitCombat and Move to reset a specific type of build action.

 

[Tekamthi]

Good feedback. Will bring an improved version of this one back next round, maybe. Was a little rushed

Reflecting further here, i think we'd also have to block the build on any other in-progress builds. Say player has OB, moves recon on top of worker and recalls -- worker could be griefed endlessly this way, if capital isn't too far away. Or is this already the case? ie do worker builds in progress automatically block other builds? ie you can't move 2nd worker on top of building worker and initiate a new build... Unclear to me what would happen if player were to use recon to try to undo worker build, if OP were implemented

What are your thoughts on implementing as a mission instead of build? Obviously some details here would have to change. Would this be preferable in DLL? Would eliminate the interactions with other builds

Also, is a Lua hook when AI is about to delete stuck unit feasible? I might experiment with different unstuck mechanisms if I had access to some kind of delete override hook

 

[Recursive]

Proposal vetoed.

Reason: I think this is too complex compared to the original proposal to be introduced during the Counterproposal Phase. The proposed implementation is also strange and would cause a lot of compatibility issues.