NFO - industry construction callback query...

[andythenorth]

to figure out what bit it is, use the built-in calc.exe in windows

(...short interlude while I find an OS X equivalent - yep got one...)

...then you end up with 100000 ... i.e. bit 5

Okay, hit me with some binary. How/why is that bit 5? If I can learn the fundamentals, I might get on better with complex action 2...

cheers,

Andy

[michael blunck]

Okay, hit me with some binary. How/why is that bit 5? If I can learn the fundamentals, I might get on better with complex action 2...

OK, let´s do some binary counting:

0
1
10
11
100
101
110
111
1000
...

Got it? Or must I proceed until bit5?

regards
Michael

[DJ Nekkid]

hehe...

well, binary is wierd counting-things where 10 is 2 and 100 is 4 and stuff; anyway,

to make it easy
0 = 0
1 = 1

then it gets harder

000 = 0
001 = 1
010 = 2
011 = 3
100 = 4
101 = 5
110 = 6
111 = 7
1000 = 8

...

the last digit gets 1 higher, and if already is 1, the 2nd last digit get higher, and if that is 1, the 3rd last digit gets 1 higher, and so on.

there are usually eight bits (bit 0 thru 7) in computer code. And to get even more confuseing, "they" use hex numbers to confuse us even more, and that is the 16-digit-system, where sixteen is 10, thirtytwo is 20 etc.
0-1-2-3-4-5-6-7-8-9-a-b-c-d-e-f-10-11-12-13-14-15-16-17-18-19-1a-1b-1c-1d-1e-1f-20

anyway ...

Code: Select all

1 0 0 1 0 0 1 0
| | | | | | | | 
| | | | | | | bit0
| | | | | | bit1
| | | | | bit2
| | | | bit3
| | | bit4
| | bit5
| bit6
bit7

or 146 is you wish


b11111111 = d255 = xFF (b= bin, d=decimal, x=hex)

[DJ Nekkid]

Got it? Or must I proceed until bit5?

regards
Michael

please do

[andythenorth]

Got it? Or must I proceed until bit5?

Ah, thanks to the combined efforts of both Michael and DJ Nekkid I get it.

I should have worked it out, but I had an off-by-one error - I was counting bit 0 as bit 1. That left me looking at a 1 followed by 5 zeroes, and wondering why a 1 in position 6 sets bit 5. Makes sense now.

The counting in binary I understand conceptually (I've seen the joke "there are 10 kinds of people in the world - those who can count in binary and those who can't".). Don't ask me to count past 2 (dec) though

TTDPatch wiki is very clear on which values to use to set the bits, but now I understand how they actually work which helps.

So, anyone able to tell me if this code checks industry 01 (or how to do that if it doesn't)?

Code: Select all

    1 * 28    02 0A 99 85
          1A    20 00 00
       0E 1A    20 00 01
       0F 67 00 00 FF FF
       01
       00 84 00 00 1E 00
       01 84

cheers,

Andy

[andythenorth]

Slept on the problem, did a bit of try-and-see testing in game, and then made the following change to the code:

Code: Select all

   10 * 28	 02 0A 0E 85
          1A    20 00 00
       0E 1A    20 00 01
//       0F 67 00 00 FF FF  // this checks for nearest coal mine (00)
       0F 67 01 00 FF FF  // this checks for nearest power station (01)
       01
       00 84 00 00 05 00
       04 80

This works - or at least, it reliably does what's expected, and doesn't crash the game. See attached . It makes sense to me, although I won't entirely trust it until I understand what each byte of code is doing.

@ Frosch What is the code above fetching from constant 0, and why it does it need to do this? (I have looked for documentation but didn't find anything so far).

@ others - thanks for the help.

cats_like_power.png (80.97 KiB) Viewed 1589 times

[michael blunck]

@ Frosch What does the code above fetching from constant 0, and why it does it need to do this? (I have looked for documentation but didn't find anything so far).

Well, it simply constructs "00 00" (WORD) to enable you to set the grf-ID to "00 00" (i.e. your own .grf). Remember, that the value of "1A" (as a WORD) is "FF FF" and AND-ing it with "00 00" results to "00 00". In the context of var67 this means that you want to use your own .grf´s ID when storing it in register 100h:

Code: Select all

   10 * 28    02 0A 0E 85
          1A    20 00 00		// get "00 00" (grf-ID)
       0E 1A    20 00 01		// store in reg 100h
//       0F 67 00 00 FF FF  	// this checks for nearest coal mine (00)
       0F 67 01 00 FF FF  	// get result of "67 01" (checks for power station)
       01			// one range
       00 84 00 00 05 00	// CB return 00 (allow placement) if val (distance) in [0..5]
       04 80			// else CB return 04 

[edit]
You´re doing the same to construct the "100" for the register to be used: get 1A = "FF FF", AND-ing with "00 01" (100h, LSB), which results to "00 01". Using 1A is the only way to generate constants in .nfo.
[/edit]

HTH
regards
Michael

[frosch]

Just to add to Michael's post:

Variable 67 gets two parameters: the GRFID of the GRF where the industry is defined in register 100h (can be written using operator 0E of variational action 2) and the setID of the industry as the regular parameter. There are two special cases for the GRFID: 00000000h means you're checking for a default TTD industry type, while FFFFFFFFh can be used instead of the GRFID of the current GRF.

The "regular parameter" is the byte which immediatelly follows the variable "67". The additional parameter is read from register 0x100. So to check for original industries (small typo in Michael's post ) you have to store 0 in it. Note that this is most likely the only case, for which word access is sufficient. As grf IDs are dwords you have to use dword-access (varaction2 type 89) in all other cases.

[michael blunck]

[...] So to check for original industries (small typo in Michael's post ) you have to store 0 in it.

Hehe. I should take a look into the Wiki before running the risk of posting buggy information.


@Andy
I´m aware that this is just for getting into .nfo, but in fact it´s not the most efficient way to code your particular "problem". Since you´re using only the distance information, you´d be better off using var64 instead. And if you don´t need to access WORD or DWORD values, you might use BYTE instead, i.e. "81" instead of "85" or "89" reference code. Remember, if you´ll only need a BYTE value, you may access the interesting portion of a DWORD result by shifting bits right into the 8-bit value range of a BYTE.

O/c, by using register 100h in your example, it´s not possible because 100h doesn´t fit into a BYTE. But there may be other cases where you want to do register operations and do it all in BYTEs instead of WORD or DWORD arithmetic. Using BYTE arithmetic adds less overhead in terms of code execution (?).

regards
Michael

[andythenorth]

I´m aware that this is just for getting into .nfo, but in fact it´s not the most efficient way to code your particular "problem". Since you´re using only the distance information, you´d be better off using var64 instead.

I've changed the code to use var64, example below (this performs as expected). Slightly over-documented to aid others climbing the learning curve in future.

Code: Select all

// Check distance to nearest industry of type n 
// In my case, used by callback 28 - allow building industry at location (full callback chain not shown below).  YMMV.
   10 * 15	 02 0A 0E 81 // action 2, type 81.  
       64 01 00 FF // check variable 67; industry type in first byte after variable (01=power station)
       01 // check one range
         00 84 00 05 // CB return 00 (0400 - allow industry placement) if val (distance) in [0..5]
       04 80 // else CB return 04 (string D0 04)

Var67 was challenging and useful. The explanation of how to set bits has just enabled me to set industry prop21 (callbacks) correctly (using bin to hex calculator).

So if a var requires an additional parameter, is that always stored in register 0x100? What if there are further parameters? Does that use 0x200, or 0x101, or something else (or is it a bogus case that never happens). Just for future reference.

I am moving on to production callbacks now...there'll probably be more questions I'm afraid.

[michael blunck]

[...]
So if a var requires an additional parameter, is that always stored in register 0x100? What if there are further parameters? Does that use 0x200, or 0x101, or something else (or is it a bogus case that never happens).

IIRC, you may use the range 0 .. 10F in total, but only 100h .. 10F for passing data to 40+x and/or 60+x variables. Insofar, registers 100h .. 10F are special.

I am moving on to production callbacks now...there'll probably more questions I'm afraid.

Well, that should be trivial after mastering register usage.


BTW, welcome on board, fellow coder.

regards
Michael

[andythenorth]

Just to add to Michael's post:

Variable 67 gets two parameters: the GRFID of the GRF where the industry is defined in register 100h (can be written using operator 0E of variational action 2) and the setID of the industry as the regular parameter. There are two special cases for the GRFID: 00000000h means you're checking for a default TTD industry type, while FFFFFFFFh can be used instead of the GRFID of the current GRF.

One comment on the documentation above - for some reason, the first few times I read it, I interpreted setID as being the GRF ID of the newgrf set, rather than the ID of the industry within the set.

The preceeding clause makes it perfectly clear which is which - but only after I'd read it several times. I'll try this to see if it's better (it may not be):

Code: Select all

Variable 67 takes 2 parameters
The regular parameter is the ID of the industry type to check for (BYTE).  Placed after the Variable ("67 xx) where xx is the industry ID.  
An additional parameter must be defined in register 100h.   This is the GRFID of the GRF to check for (DWORD).  
This parameter must be written into register 0x100 using operator 0E of variational action 2.

Don't know if it's better or 100% correct - if there's anything wrong I'll edit it to prevent misleading people.

[Comm Cody]

Hmmmm... Any picture of the catfood mine and industry chain? What about a dogfood mine?