Bump. All is well I presume? Looking forward to it.

I'm stuck b/c I can't figure out any way past the problem I stated previously and can't replicate TBest's solution to it.

Is your code on github? Feel free to @ me in the prog channel on discord

No, haven't posted it, just testing it locally still.

Can you send your entire LUA file you are testing with?

Also the criteria I'm testing it on is:

A (owned by player 1) moves to B (neutral)
B (owned by player 1) moves to C (neutral)
C (owned by player 1) moves to B (owned by player 1)
B moves to D (neutral)

And the B->D always fails.

Below is the code with some error checking where I'm trying to replicate what you've done.

function Server_AdvanceTurn_Order(game, order, result, skipThisOrder, addNewOrder)
	print ("0005 Turn_Order[start]")
	if(order.PlayerID==1) then
		skipThisOrder(WL.ModOrderControl.SkipAndSupressSkippedMessage)
	elseif(order.proxyType == 'GameOrderAttackTransfer') then
		if (result.IsAttack == false) then
			print ("10 [ATTACK/TRANSFER] IsAttack="..tostring(result.IsAttack).." pl="..order.PlayerID.." #attacks="..OtherAttacks[order.From].." #armies="..order.NumArmies.NumArmies .." #armiesFROM="..game.ServerGame.LatestTurnStanding.Territories[order.From].NumArmies.NumArmies.." TO="..game.ServerGame.LatestTurnStanding.Territories[order.To].NumArmies.NumArmies);
			print ("20   success=".. tostring(result.IsSuccessful).." ActualArmies="..result.ActualArmies.NumArmies);
			
			--local numAttackers = game.ServerGame.LatestTurnStanding.Territories[order.From].NumArmies.NumArmies;
			local numAttackers = order.NumArmies.NumArmies			
			--Write to GameOrderResult (result)
			--local NewAttackingArmiesKilled = WL.Armies.Create(numAttackers);
			--result.ActualArmies = NewAttackingArmiesKilled;
			if numAttackers == 40 then
				print ("30   success=".. tostring(result.IsSuccessful).." ActualArmies="..result.ActualArmies.NumArmies);
				local numAttackingArmies = WL.Armies.Create(numAttackers-5);
				--result.ActualArmies = NewAttackingArmiesKilled;
				result.ActualArmies = numAttackingArmies;
				print ("40   success=".. tostring(result.IsSuccessful).." ActualArmies="..result.ActualArmies.NumArmies);
			end
			--skipThisOrder(WL.ModOrderControl.SkipAndSupressSkippedMessage)
		end
		print ("50   success=".. tostring(result.IsSuccessful).." ActualArmies="..result.ActualArmies.NumArmies);
	end
	print ("1000 Turn_Order[fin]")
end

And here is the debug window output. You can see that while it does change the # actual armies from 0 to another #, it never changes success to True, and thus the move still gets skipped. Inputted moves were just A->B, B->C, where A & B are already owned territories, C is neutral. A->B always succeeds, B->C always fails.

274: [TURN START][start]
274: [TURN START][fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 10 [ATTACK/TRANSFER] IsAttack=false pl=1058239 #attacks=5 #armies=100 #armiesFROM=45 TO=0
274: 20   success=true ActualArmies=45
274: 50   success=true ActualArmies=45
274: 1000 Turn_Order[fin]
274: 0005 Turn_Order[start]
274: 10 [ATTACK/TRANSFER] IsAttack=false pl=1058239 #attacks=5 #armies=40 #armiesFROM=45 TO=2
274: 20   success=false ActualArmies=0
274: 30   success=false ActualArmies=0
274: 40   success=false ActualArmies=35
274: 50   success=false ActualArmies=35
274: 1000 Turn_Order[fin]

This works for me, and I think it accomplishes what you are trying to do with leaving 5 armies behind. Let me know if you want me to add comments. EDIT: duno why the copy-past is not formatting the code nicely.

function Server_AdvanceTurn_Order(game, order, result, skipThisOrder, addNewOrder)
	if(order.PlayerID==1) then
        skipThisOrder(WL.ModOrderControl.SkipAndSupressSkippedMessage)
        return;
    end
    if(order.proxyType == 'GameOrderAttackTransfer') then
		if (result.IsAttack == false) then
            if (result.IsNullified) then 
                local numAttackers = order.NumArmies.NumArmies
                
                if numAttackers > game.ServerGame.LatestTurnStanding.Territories[order.From].NumArmies.NumArmies then
                    numAttackers = game.ServerGame.LatestTurnStanding.Territories[order.From].NumArmies.NumArmies;
                end;
                
            numAttackers = numAttackers - 5;

            if (numAttackers < 0) then numAttackers = 0 end;
                local numAttackingArmies = WL.Armies.Create(numAttackers);
            
                result.ActualArmies = numAttackingArmies;
            end
        end
	end
end

Edited 9/15/2020 14:39:05

Still can't get it to work. To confirm, you're able to accomplish this?



1) Colombia moves 100% to Peru
2) Peru moves 100% to Colombia
3) Colombia moves 100% to Amazonas
4) Peru moves 100% to Amazonas

#1 and #2 already work fine, which is still an improvement on current LMA (#2 would fail).

But #3 and #4 both still fail. I'm printing out result.isSuccess, result.isNullified and result.ActualArmies.NumArmies and see that when orders #3 starts that it's false/true/0 and then after the modification of ActualArmies switches to false/false/57 which shows that the move is no longer nullified and that army count has been corrected, but it's still success=false and thus never gets executed.

Also 1 other oddity is that order #4 never executes. In fact, I can see that the code exits function Server_AdvanceTurn_Order after order #3 and halts, never processing order #4. It's likely the false/false/57 combination trying to get the WZ engine to exit an unsuccessful but non-nullified order causing it to crash and abort processing any further orders.

I just realized I have been testing in non-multiattack games. I assumed that transfer would behave the same, but this was a wrong assumption on my end. My code was written for normal games where multiattack is not enabled and there is no attack by %.

I do see what the issue is, I will see if I can make something working tomorrow.

Edited 9/16/2020 03:55:25

Also try the mod, Limited Attack. Set to 3. Then try the following.

Order 1 - 5 troops from A, into C.
Order 2 - 5 troops from B, into C
They merge, for total of 10, to be moved into D
Order 3 - move 10 into D

.............Order 1---5>
(merge) Order 3---10-->10
.............Order 2---5>

That explains it. And you're correct, for non-MA games, moves #1 and #2 aren't an issue, but of course you'd never be able to execute moves #3 or #4.

Regular MA is also fine with #1 and #2 but neither #3 or #4. Current LMA mod breaks #2, which is frustrating b/c it's super non-intuitive for LMA to be more restrictive than regular non-MA, and also breaking something that's present in regular non-modded MA.

My current LMM (Limited Multi Move) code fixes #2 (simply by not inadvertently blocking it) but gets shut down on #3 and #4.

And looking forward, I think I'll need to worry about how to prevent infinite troop transfers by having enabled #2. eg: if using LMM with 3 move allowance and you transfer 10 from A->B which already has 15 units, B now has 10 units with 1 move already down, and 15 units with 0 moves, but the game will only see 25 units and I'll have to set it to either with 0 moves done (permits infinite transfers) or to 1 (reintroduces a toned down version of the #2 problem - not the instant All-Stop breaker that current LMA is, but if a transfer to a territory is the final move allowed for those units, it would then block #2 for the units on the target territory -- still an improvement, but not ideal). Anyhow, this is the "next problem" to solve, and I'm still stuck on the "current problem" and if I can't get past this, the next problem is moot.

@HangFire - Agree, that is another use case, but that's in the "next problem" category. Until I'm able to figure out what's stopping the A->B->C problem ("current problem"), I can't progress on to A->C B->C, C->D test case ... but 100% with you that that needs to be enabled by this mod to truly succeed -- while simultaneously not enabling infinite transfers (see my last post).

hmm, can't delete posts. I didn't see it because it went to page two , but returned me to page one.

Edited 9/16/2020 06:05:01

uploaded image didn't come out right.

Edited 9/16/2020 06:06:14

edit - nvm can't delete posts?

Edited 9/16/2020 06:05:34

you cant delete posts, but you can edit them. Editing your posts eliminates the need to keep making new posts, so that is the prefered option (but idk if Fizzer already made this possible on mobile...)

Ok, looks like some strange things happens when we try to do this kinda things :/

The problems, or rather workarounds needed, are not trivial*. Guess the anti-hack/safety code in warzone is quite good.


*Warzone Server returned ServerError x=Can't transfer to a neutral

Fun issue. Warzone dosn't realize we can do what we are doing :/ So it's not a transfer to a neutral. But wz think's it is.

Edited 9/20/2020 22:06:01

Just posting to keep this alive ... been busy with work, but think I have a method to work around the issue I'm having. Just need some time to test it out.