Variable cargo output types?

[gmyx]

DaleStan wrote:
gmyx wrote:
What if we had that attitude to other features such as PBS or larger stations just to name two? Are you suggesting we freeze the NFO spec?
Good try. But neither of those have anything to do with NFO.


While I was not trying to get an exact match, here goes another try: Articulated road/tram vehicles and new houses. I could go on, but I think you get the point.

DaleStan wrote:
And I think Belugas is suggesting that Open fully support the spec before extending it willy-nilly.


And how long will that be? Are we supposed to park ourselves and let others catch up on this item? I'm all for compatibility between (O)TTD, but can we hold back because they would prefer to focus on other features (speculation). The last nfo related change I can find (according to the wiki) is for r1698,
Code:

csaboka: added two new varaction2 operations: signed and unsigned compare

. That was a few days ago. By your argument, that should not of be done?

I don't know what level of implementation OTTD has for the NFO spec, but that should not stop us from creating new features just because it naturally causes a lag in a similar implementation in OTTD. What if someone else get a great idea that requires an addition to the NFO spec? Are we to tell him, sorry but OTTD won't implement it right away so we won't so they can catch up?

Dave Worley wrote:
It is, indeed, one of the things that infuriates quite a few of the old patch veterans.

The new kid on the block comes in, and completely ignores some parts of the way things work, takes it over, extends it as it will, and leaves everyone else in turmoil.

Basically, as DaleStan said - OTTD can extend NFO when it fully supports NFO. Until then, I'm not sure what "rights" or whatever you're talking about apply.


I am assuming you mean me by "new kid" since everyone else in this thread has around and active for a while - although I'm not a kid, but that's another story. All i made was a simple question that turned into a suggesting for new feature.

All this to say that we should not prevent new ideas from being implemented in one project just because the other can't/won't.

Sorry, but this brushed me the wrong way and feel like some people are implying we should become stale for the sake of full backwards compatibility. I may be wrong on that - and I hope I am wrong.

[DaleStan]

the Win32 API of the Linux kernel

And, further to the rubbish-that-infuriates-us-department, please refrain from implying that the Linux kernel supports the Win32 API.

I'm all for compatibility between (O)TTD, but

Between OTTD and what? Between requires at least two entities. You've only listed one. Unless you're suggesting that there should be compatibility between TTD and Open, which will, I believe, get you drawn and quartered in short order.

The last nfo related change I can find (according to the wiki) is for r1698 <...> That was a few days ago. By your argument, that should not of be done?

That's Patch. Patch supports the spec. Patch is, therefore, free to extend the spec.

I don't know what level of implementation OTTD has for the NFO spec, but that should not stop us from creating new features just because it naturally causes a lag in a similar implementation in OTTD.

What if someone else get a great idea that requires an addition to the NFO spec? Are we to tell him, sorry but OTTD won't implement it right away so we won't so they can catch up?

Wherever did you get those utterly rubbish ideas?

All this to say that we should not prevent new ideas from being implemented in one project just because the other can't/won't.

And again. Where in all the burning hells did you get the idea that it's not being done in Patch because it won't be done in Open?
Or even that it won't be done in Open subsequent to it being done in Patch?
For any NFO-related value of "it", anytime, anywhere?

[Csaboka]

Calm down, people, there's no need for this aggressive attitude

First of all, as far as I know, OTTD has already extended the NFO spec: there is a WIP feature that allows adding new airports from a GRF file, with all the required movement schemes. This spec extends feature4, so that feature is no longer just for train stations, but for airports too. (I guess the next logical step will be extending it to RV stations and docks too, but I digress.) I think DaleStan himself was helping the creation of this spec with suggestions.

Still, that case is different from the situation discussed here. TTDPatch doesn't support new airports at all, so if you want to code new airports, you can't even think of compatibility with TTDPatch. New industries, on the other hand, is (or will soon be) supported in both programs, with the same spec. Adding a feature that isn't supported in TTDPatch will mean that people choosing to use that feature "lock in" to OTTD. Those who want to remain compatible with both platforms will have to ignore the new feature, and will not benefit from it at all. Until now, if we knew something doesn't work with OTTD, we could assume they're working on it, and it will work eventually. But how about OTTD-only GRFs that you know will never work on TTDPatch?

I sorry if this seems a little hash or rude, but my original questions was "Is this possible?". Basically the answer was "yes with some work".

That answer was given for the "variable output types" feature, not the "more than three input cargoes" feature. More than three cargoes will probably never work in TTDPatch.

I am hopping that it does get implemented and asking politely for it to be implemented in TTDPatch. Whether you see it fit to implement these features in OTTD or not, thats up to you.

OK, I'm lost. Which feature are you asking politely to be implemented in TTDPatch? I assumed it's the "more than three cargoes" feature, but you must already know it's impossible for TTDPatch.

I am assuming you mean me by "new kid" since everyone else in this thread has around and active for a while - although I'm not a kid, but that's another story.

I guess Dave meant "new kid"=OTTD. I'm sure he wasn't flaming you.

the Win32 API of the Linux kernel

And, further to the rubbish-that-infuriates-us-department, please refrain from implying that the Linux kernel supports the Win32 API.

I guess that was just a typo, and he meant "the Win32 API or the Linux kernel". That sentence makes perfect sense with or. I haven't even noticed he wrote of until you pointed it out.

[gmyx]

the Win32 API of the Linux kernel

And, further to the rubbish-that-infuriates-us-department, please refrain from implying that the Linux kernel supports the Win32 API.,

That is a typo there, I meant "[...]Win32 API *or* the linux kernel[...]"

I'm all for compatibility between (O)TTD, but

Between OTTD and what? Between requires at least two entities. You've only listed one. Unless you're suggesting that there should be compatibility between TTD and Open, which will, I believe, get you drawn and quartered in short order.

I'm talking about NFO compatibility between OTTD and TTD, I have seen others refer to the combination as (O)TTD for comparisons and simplicity in writting.

The last nfo related change I can find (according to the wiki) is for r1698 <...> That was a few days ago. By your argument, that should not of be done?

That's Patch. Patch supports the spec. Patch is, therefore, free to extend the spec.

I don't know what level of implementation OTTD has for the NFO spec, but that should not stop us from creating new features just because it naturally causes a lag in a similar implementation in OTTD.

What if someone else get a great idea that requires an addition to the NFO spec? Are we to tell him, sorry but OTTD won't implement it right away so we won't so they can catch up?

Wherever did you get those utterly rubbish ideas?

All this to say that we should not prevent new ideas from being implemented in one project just because the other can't/won't.

And again. Where in all the burning hells did you get the idea that it's not being done in Patch because it won't be done in Open?
Or even that it won't be done in Open subsequent to it being done in Patch?
For any NFO-related value of "it", anytime, anywhere?

This thread and the responses I got.

I sorry if this seems a little hash or rude, but my original questions was "Is this possible?". Basically the answer was "yes with some work".

That answer was given for the "variable output types" feature, not the "more than three input cargoes" feature. More than three cargoes will probably never work in TTDPatch.

I am hopping that it does get implemented and asking politely for it to be implemented in TTDPatch. Whether you see it fit to implement these features in OTTD or not, thats up to you.

OK, I'm lost. Which feature are you asking politely to be implemented in TTDPatch? I assumed it's the "more than three cargoes" feature, but you must already know it's impossible for TTDPatch.

I should of specified that I meant variable output types in both cases. I understand that "more than three input cargoes" is a hard limit and pretty much forgot about it as soon as you confirmed it was a brick wall.

I am assuming you mean me by "new kid" since everyone else in this thread has around and active for a while - although I'm not a kid, but that's another story.

I guess Dave meant "new kid"=OTTD. I'm sure he wasn't flaming you.

I sure hope so, I'm trying to be respectful with my arguments for adding variable output types feature.

To sum everything up at this point so that every one is clear on my impressions. From the feedback I got, I believe I was being told that "variable output types" is not going to be implemented partially because it means the NFO spec needs to be added to to support the feature.

[Csaboka]

To sum everything up at this point so that every one is clear on my impressions. From the feedback I got, I believe I was being told that "variable output types" is not going to be implemented partially because it means the NFO spec needs to be added to to support the feature.

OK, this is cleared up, then. The "variable output types" function is possible, and is added to my TODO. The "more than 3 input and 2 output types" feature will probably never get implemented in TTDPatch, and IMO it wouln't be a good idea to add it to OTTD and break compatibility with TTDPatch.

[belugas]

I totally agree with that, Csaboka

[Csaboka]

OK, I've finished the variable input/output types callback just now. (See the wiki for details.)

I couldn't squeeze all the required info into 15 bits, so the callbacks are called multiple times, returning one cargo type at a time. As a side effect, this allows using more input/output types than currently supported. I don't intend to actually add support for that to TTDPatch, but OpenTTD can implement it now without breaking compatibility*. The extra cargoes simply won't show up under TTDPatch.

*Actually, this alone doesn't allow correct handling of extra input/output types. We'd need a way to allow defining the production rates of the new cargoes, and a new version of the production callback that doesn't hard-code three input and two output types. These things can be added easily too, I just don't want to do them unless an OTTD dev needs them (that is, if more input/output types will be an official feature, not just an unofficial patch).

[gmyx]

OK, I've finished the variable input/output types callback just now. (See the wiki for details.)

I couldn't squeeze all the required info into 15 bits, so the callbacks are called multiple times, returning one cargo type at a time. As a side effect, this allows using more input/output types than currently supported. I don't intend to actually add support for that to TTDPatch, but OpenTTD can implement it now without breaking compatibility*. The extra cargoes simply won't show up under TTDPatch.

*Actually, this alone doesn't allow correct handling of extra input/output types. We'd need a way to allow defining the production rates of the new cargoes, and a new version of the production callback that doesn't hard-code three input and two output types. These things can be added easily too, I just don't want to do them unless an OTTD dev needs them (that is, if more input/output types will be an official feature, not just an unofficial patch).

That is great! I expect to be able to have a test implementation sometime this weekend! I will provide feedback should I have any issue or the lack thereof.

Thank you!

[athanasios]

Thanks Csaboka, good news!

[gmyx]

I seem to be having a small issue - but it could be my code the problem, if I'm doing something wrong, please let me know. On the very first (or so it seems to me) industry to use the callback, the result are mis-interpreted. EX:

Code: Select all

  277 * 22	 0C "  MF: Dynamic Output "
  278 * 54	 0C "  MF: Callback check for 14C - Variable output types "
  279 * 17	 02 0A 00 85 0C 00 FF 00 01 01 00 14 0C 14 0C FF 80
  280 * 42	 0C "  MF: Callback check for 10 - count of 0 "
  281 * 18	 02 0A 01 81 10 00 FF 02 0D 80 00 00 0C 80 01 01 FF 80

Cargo Id OD is Maize and OC is fruit. When I use this code, the first farm has output cargoes of fruit and food (15 in my GRF). All other farms have fruit and maize as output. I know those output seem strange, it was just a test.

Also, is it *safe* to use the industry tile "random" bits (variable 61) to decide to what action 2 ID to branch to select the correct variable 10?

Thank you. (full NFO and GRF attached)

[DaleStan]

What does NFORenum say? (Hint: When it says "14 0C", it means "C14")

(And another "Why does Patch load this?" Csaboka? Oskar?)

Don't know about the random bits, though. Those should be generated early in the procedure, but I don't know how early.

EDIT: The random bits are stored in industry var AE (word-sized). If that var often all-zero in 14B/14C (especially when generating a new game) then the random bits have probably not been generated. Otherwise, the random bits are initialized. If they are not initialized, then it would probably be a reasonable request that they be initialized before the calls to 14B/14C.

[Csaboka]

Code: Select all

  277 * 22	 0C "  MF: Dynamic Output "
  278 * 54	 0C "  MF: Callback check for 14C - Variable output types "
  279 * 17	 02 0A 00 85 0C 00 FF 00 01 01 00 14 0C 14 0C FF 80
  280 * 42	 0C "  MF: Callback check for 10 - count of 0 "
  281 * 18	 02 0A 01 81 10 00 FF 02 0D 80 00 00 0C 80 01 01 FF 80

There seem to be some things you got wrong about NFO coding. For example, you can't jump to an action2 that is defined later in the file; ID 01 must be defined before ID 00. Also, in ID 00, masking with 0xFF then testing against 0xC14 doesn't make any sense. You seem to be misunderstanding action 3, too; usually, you need only one action3 per ID. As DaleStan said, NFORenum can catch those problems for you, but you must have some basic knowledge about NFO to understand what it tries to say.

When I use this code, the first farm has output cargoes of fruit and food (15 in my GRF). All other farms have fruit and maize as output. I know those output seem strange, it was just a test.

This is a bug in my code, I've just committed the fix for it. Thanks for pointing it out. Even though your code is incorrect, it should always make farms produce fruit and food.

Also, is it *safe* to use the industry tile "random" bits (variable 61) to decide to what action 2 ID to branch to select the correct variable 10?

No, industry tiles aren't yet placed on the map. I should have mentioned that on the wiki.
/me goes and updates the wiki
You can, however, use the random bits of the industry via using random action2s. You have 16 random bits for the industry, that should be enough for randomzing input/output cargoes.

And another "Why does Patch load this?" Csaboka? Oskar?

Which part shouldn't it load? I haven't read the full NFO, but the quoted part seems to be syntactically correct. It's semantically incorrect, of course, but TTDPatch doesn't even try to catch semantic errors.

[gmyx]

What does NFORenum say? (Hint: When it says "14 0C", it means "C14")

I know it complains, I was surprised when it worked! But then I noticed it was giving some different results, so even if it was incorrect, I thought I'd post to get that out of the way.

There seem to be some things you got wrong about NFO coding. For example, you can't jump to an action2 that is defined later in the file; ID 01 must be defined before ID 00. Also, in ID 00, masking with 0xFF then testing against 0xC14 doesn't make any sense. You seem to be misunderstanding action 3, too; usually, you need only one action3 per ID. As DaleStan said, NFORenum can catch those problems for you, but you must have some basic knowledge about NFO to understand what it tries to say.

Thats what I thought was the proper way to do the list - in a bottom up way. About the mask, I'm not sure what does go there? should it of been FF FF since were dealing with a word value and not a byte value? or something else? AS for the action 3, I thought I was doing on action 3 per ID (one for 00 and one for 01) - or am I so far off base?

Even though your code is incorrect, it should always make farms produce fruit and food.

Look like I need to crack my head at this again... I have to admit I'm having a hard time to understand the NFO code fully - especially callbacks. I wonder why it would use fruits (0Ch) and food (15h) and not fruits (0Ch) and Maize (0Dh)? I must be missing something here since I redefined all the cargoes, including a translation table.

No, industry tiles aren't yet placed on the map. I should have mentioned that on the wiki.
/me goes and updates the wiki
You can, however, use the random bits of the industry via using random action2s. You have 16 random bits for the industry, that should be enough for randomizing input/output cargoes.

Thats great...It is certainly more than enough with 16 bits. 65535 choices... Random action 2, while supports feature 0A, does not seem have any triggers. Again, I must be missing something here.

I'm sorry if this is frustrating for you two (Csaboka and DaleStan), I'm trying to learn this and have read the tutorials, but still I am very confused at these things. I'm slowly getting the cobwebs out and understanding this great feature. Thank you for the help - it is much appreciated!

[Csaboka]

Thats what I thought was the proper way to do the list - in a bottom up way.

Yes, it should be bottom up - ie. the action2 you want to be executed first should be at the bottom. ID 01 (the one that decides on variable 10) must phisically be before ID 00 (callback check); otherwise, you can't jump to ID 01 from ID 00.

About the mask, I'm not sure what does go there? should it of been FF FF since were dealing with a word value and not a byte value?

Yes. If you don't want to lose bits, you must use all ones as the AND mask. This means FFFF for word size.

AS for the action 3, I thought I was doing on action 3 per ID (one for 00 and one for 01) - or am I so far off base?

You need one action3 per industry ID, not one per action2 ID. Think of action3 as an anchor for the action2 chain - it tells TTDPatch where the chain begins. It doesn't make sense to have more than one anchor for an industry type.

Look like I need to crack my head at this again... I have to admit I'm having a hard time to understand the NFO code fully - especially callbacks. I wonder why it would use fruits (0Ch) and food (15h) and not fruits (0Ch) and Maize (0Dh)?

Oops, I'm sorry, I meant fruit and maize, not fruit and food.

Random action 2, while supports feature 0A, does not seem have any triggers. Again, I must be missing something here.

Triggers are required only if you want to re-randomize some of the random bits when some event happens. You don't need triggers for the input/output type callbacks, since those happen once only. You can, however, re-randomize industry random bits by using triggers with type 83 for an industry tile. (This is an advanced topic, though, don't worry if you don't fully understand it yet.)

[gmyx]

Thats what I thought was the proper way to do the list - in a bottom up way.

Yes, it should be bottom up - ie. the action2 you want to be executed first should be at the bottom. ID 01 (the one that decides on variable 10) must phisically be before ID 00 (callback check); otherwise, you can't jump to ID 01 from ID 00.

About the mask, I'm not sure what does go there? should it of been FF FF since were dealing with a word value and not a byte value?

Yes. If you don't want to lose bits, you must use all ones as the AND mask. This means FFFF for word size.

AS for the action 3, I thought I was doing on action 3 per ID (one for 00 and one for 01) - or am I so far off base?

You need one action3 per industry ID, not one per action2 ID. Think of action3 as an anchor for the action2 chain - it tells TTDPatch where the chain begins. It doesn't make sense to have more than one anchor for an industry type.

AH! That must be where things go wrong- the action 3s. Looks like I need to do some more reading!

Triggers are required only if you want to re-randomize some of the random bits when some event happens. You don't need triggers for the input/output type callbacks, since those happen once only. You can, however, re-randomize industry random bits by using triggers with type 83 for an industry tile. (This is an advanced topic, though, don't worry if you don't fully understand it yet.)

So, I just use random action 2 with 00 for the triggers variable? The rest makes sense to me.

[DaleStan]

And another "Why does Patch load this?" Csaboka? Oskar?

Which part shouldn't it load? I haven't read the full NFO, but the quoted part seems to be syntactically correct. It's semantically incorrect, of course, but TTDPatch doesn't even try to catch semantic errors.

There seem to be some things you got wrong about NFO coding. For example, you can't jump to an action2 that is defined later in the file; ID 01 must be defined before ID 00.

There is an ID 01 defined (at sprite 208) before that ID 00, but it's defined for feature 09, which should be an error when accessed from a var2 for any other feature (eg 0A).

Oh, and I see that's already in the todo. Nevermind, then.

[gmyx]

And another "Why does Patch load this?" Csaboka? Oskar?

Which part shouldn't it load? I haven't read the full NFO, but the quoted part seems to be syntactically correct. It's semantically incorrect, of course, but TTDPatch doesn't even try to catch semantic errors.

There seem to be some things you got wrong about NFO coding. For example, you can't jump to an action2 that is defined later in the file; ID 01 must be defined before ID 00.

There is an ID 01 defined (at sprite 208) before that ID 00, but it's defined for feature 09, which should be an error when accessed from a var2 for any other feature (eg 0A).

Oh, and I see that's already in the todo. Nevermind, then.

Funny, thats the only way so far I've been able to get it to work (have not had a chance to re-write the action 3s and re-order the action 2s yet). I know it's wrong, and I'm guessing it's my actions 3s that are giving me a hard time in getting my code to work. I was very happy when it worked (I was tweaking some layouts at the same time) despite the fact that renum was complaining.

[DaleStan]

Never ever ignore an error from NFORenum. Verily, its perception and judgment oft exceed thine. (Verily, its perception and judgment oft exceed mine too.)

If you can't interpret the error, even with the help of SANITY.*.txt, report it as a bug in NFORenum's documentation. If you can interpret the error, but think it is wrong, report it as a bug in NFORenum. Otherwise, fix the problem code. Code that causes NFORenum to generate error messages will rarely do what you expect.

For warnings, at least determine the cause of its unhappiness and understand what worrisome sign it tries to speak of. Then decide if it's actually a problem that needs to be fixed, or if NFORenum is just being excessively noisy. If the former, proceed as if the message were an error.

[gmyx]

Never ever ignore an error from NFORenum. Verily, its perception and judgment oft exceed thine. (Verily, its perception and judgment oft exceed mine too.)

If you can't interpret the error, even with the help of SANITY.*.txt, report it as a bug in NFORenum's documentation. If you can interpret the error, but think it is wrong, report it as a bug in NFORenum. Otherwise, fix the problem code. Code that causes NFORenum to generate error messages will rarely do what you expect.

For warnings, at least determine the cause of its unhappiness and understand what worrisome sign it tries to speak of. Then decide if it's actually a problem that needs to be fixed, or if NFORenum is just being excessively noisy. If the former, proceed as if the message were an error.

Well, as I said before, it was tweaking my industry layouts at the time and knew that renum was giving me an error for the action 2s. Since the patch was loading it, it allowed me to tweak it while trying to figure it out. What is the worst that can happen (except the odd blue screens I'm getting - damn creative sound card)? The patch errors out the file.

Unfortunately, I could not work on it last night - kinda hard with no power (that coal train must of gotten stuck again...)

[gmyx]

Well, I finally got it to work. My callback check was wrong - 0C 14 --> Which should of been 4C 01! Once I got this, everything thing else worked perfectly, including the random bits!

Thank you for all you help and support.