PlayerID in events

[loco_motive]

OK, this might take a couple readings to understand the following test results. I have encountered no problems with companyID but playerID is another matter.

 

1. If your event cycles through just players, then playerID is zero, or more likely, empty.

 

So only the human player and first AI player are immediately accessible at the exclusion of all others. For the human, just cycle on human players only, For the first AI just cycle on computer players and make it a 1-time event. It is possible to assign a successively higher value of, say, playervariable1 to each successive player. Thereafter they would be accessible using PV1. This is easily done with a single event as I'll show in the next post.

 

2. If your event cycles through players and companies, then it just cycles through companies but sets playerID=companyID.

 

This is an odd result. For 4 players and 3 companies, you might expect to get 12 entries in the status report, one for each combination, but you will get only 3 entries, one for each company. Note that the status report entries in your company are only going to be for certain types of information such as (allowable bracketed items), gamevariable and territoryvariable items.

 

So here, if your trigger is playerID=4, you can give money to the player whose companyID is 4. Of course this requires that the player has a company that was created at the right time and you have the right companyID. Adding a variation like this to an existing scenario would require you to first test that the original author had not created and destroyed any companies in the process and that the target player created a company in the expected order so that it had the right number.

 

Just to test your understanding of the above, a trigger of companyID=4 would also work in giving money to that player. Also, the playerID assignments only persist within this event.

 

3. If your event cycles through just companies, you will not be allowed to do any player-related things. I didn't bother to test this.

[loco_motive]

How to assign successive values of playervariable1 to each player.

 

Trigger: (playervariable1=0)*(gamevariable1+1)

 

Effect: Gamevariable1: set equal to trigger
           Playervariable1: set equal to trigger

 

This obviously cannot be a one-time event and should be cycled on players only.

 

This event will never trigger true again unless some PV1 is set back to zero, so GV1 can be reused. If GV1 has already been used, you will of course need to initialize it.

[jeffryfisher]

So only the human player and first AI player are immediately accessible at the exclusion of all others. For the human, just cycle on human players only, For the first AI just cycle on computer players and make it a 1-time event. It is possible to assign a successively higher value of, say, playervariable1 to each successive player. Thereafter they would be accessible using PV1. This is easily done with a single event as I'll show in the next post.

 

2. If your event cycles through players and companies, then it just cycles through companies but sets playerID=companyID.

 

This is an odd result. For 4 players and 3 companies, you might expect to get 12 entries in the status report, one for each combination, but you will get only 3 entries, one for each company. Note that the status report entries in your company are only going to be for certain types of information such as (allowable bracketed items), gamevariable and territoryvariable items.

 

So here, if your trigger is playerID=4, you can give money to the player whose companyID is 4. Of course this requires that the player has a company that was created at the right time and you have the right companyID. Adding a variation like this to an existing scenario would require you to first test that the original author had not created and destroyed any companies in the process and that the target player created a company in the expected order so that it had the right number.

 

Just to test your understanding of the above, a trigger of companyID=4 would also work in giving money to that player. Also, the playerID assignments only persist within this event.

 

3. If your event cycles through just companies, you will not be allowed to do any player-related things. I didn't bother to test this.

[i wish this forum interface would allow me to insert comments in the middle of the backquote, but I can no longer force it to do so  :( ]

 

1) Although multiplayer is probably dead, I try to keep it in mind just in case. That means that I never allow myself to assume the uniqueness of "the" human player in any of my events. On any map the you would ever "publish", I recommend doing likewise (or else check the "single" radio button)

 

2) I see the value of assigning ordinal numbers to P1. I hate losing a whole player var. In my US History map I lucked out mostly by accident. Because even my player-effects were in events triggered by companies, I skated by on the CompanyId=PlayerControlledCompanyId "inner join" ("Inner join" is database lingo).

 

3) Status reports: As a player, you will only see the statuses for yourself in your own report. That's why you see each company only once, not 12 times. If anyone is interested in seeing how elaborate statuses can be, take the time to page through all of the debugging info in US History. Well into the game it can run to 5 pages.

 

4) Using company wouldn't have helped AK. He wanted to activate players previously with zero cash, so no company to work from. Fortunately, a cash or net-worth test would work there.

 

5) The game editor will complain if you put a player-related function or effect into an event that hasn't checked the players checkbox. The game won't know which player to test or effect unless it is cycling through (human and/or AI) players. It needs that checkbox in order to establish context.

 

A similar necessity exists for territory, but for single-territory events you can avoid a "time-wasting" loop by just putting the T-number in the box. Note on exec speed: Modern CPUs chew through these events in the blink of an eye. Even US History with ~450 (sometimes complex) triggers can run through them as if they weren't even there. The only lag in the game is when the AI is looking to build a long route on a congested map. Route planning still takes some serious horsepower just to come up with the disastrous builds that the AI uses to flush its cash.

 

6) playerID=companyID... That is very strange! AK could try creating an empty company for each empty player and then giving each some cash in later years.

[outofmage]

loco, I just test the companyId=playerId issue when you choose to cycle both companies and players. I also got the same result with you and I will try to explain why this is happening with my tests here.

 

As you mentioned, there will be only 3 entries if the game has 3 companies currently even though we expect 3*4=12 entries if there are 4 players. I believe it's because when you choose to test against both players and companies, the 'playerControlledCompany=CompanyId' is indicated. To be precise, the program writes 'players INNER JOIN companies WHERE Players.playerControlledCompanyId=Companis.CompanyId' when you compile the trigger leaving both players and companies checked, maybe this statement is always included in every event.

 

To confirm this theory, I design my test as this:

I create a map with 3 players, and each player has a company.

I set the player cash as $80K, $800K, $8,000K, and the company cash as #100K, $1,000K, $10,000K. So player cash is lower than their own company, but some players have more cash than other players' company.

 

only one event for this map:

test against all players

test against all companies

test monthly

trigger:

PlayerCash>CompanyCash

effect:

GameWin3

 

I just tested it, at first, nothing happens, but after 7 months, player #1 wins. 

Because the company controlled by the first player gets not enough interest to cover the overhead and salary, its cash drops down below player #1's cash and triggers the event. 

This confirms that the playControlledCompanyId=CompanyId is always indicated as long as you check both players and companies. Primary key needs to be defined as a result of joining of two tables, game designers chose CompanyId as the primary key, leaving playerId useless.

 

This is further confirmed when I remove some of existing maps 'playerControlledCompanyId=CompanyId' term and everything still works fine.

[jeffryfisher]

I think it's a bug in the Tycoon program that sets PlayerID to CompanyID. It would also explain why PlayerID remains zero when companies are not involved in the event.

 

In any case, we're stuck with using work-arounds for certain kinds of events.