Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some NewGRF variables concerning railtypes #7000

Open
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@Eddi-z
Copy link
Contributor

Eddi-z commented Dec 29, 2018

Add: Var 6A, a clone of Var 4A for querying poweredness compared to an arbitrary railtype

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Dec 29, 2018

NML usage: "var[0x6a, 8, 0xFF, ELRL]"

@andythenorth

This comment has been minimized.

Copy link
Contributor

andythenorth commented Dec 29, 2018

Tested, worked as expected for me.

@andythenorth

This comment has been minimized.

Copy link
Contributor

andythenorth commented Jan 3, 2019

The intent is to use this in, varaction 2 for e.g. CB36.

Without this var, railtype labels have to be checked individually, which:

  1. is potentially a long list
  2. requires vehicle grf to know all possible railtypes in advance, rather than relying on railtype grf to specify compatibility and powered-ness
@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Jan 3, 2019

Open questions (that i can't answer myself):

  • choice of variable number?
  • skip the (redundant, because same as var4A) reverse lookup?
  • are there railtype introspection variables needed other than poweredness?
@frosch123

This comment has been minimized.

Copy link
Member

frosch123 commented Jan 7, 2019

I second the "skip the redundant part".

This variable seems to be about comparing two railtypes.
Besided poweredness there is not much to compare (compatibility is useless here).

  • Which one is better? Higher speed limit or something? Newer intro date?

In addition it may make sense to extend 4A with more attributes about the present railtype:

  • Track has catenary?

Maybe - but not necessarily - related:

  • Sometimes vehicles want to know about their speed limit, and whether it is defined by the vehicle, the railtype, the bridge, the timetable, stopping, ...
    Currently there are some acceleration/deceleration flags, but an actual number to compare with "current_speed" may be more useful.
@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Jan 7, 2019

In addition it may make sense to extend 4A with more attributes about the present railtype:

* Track has catenary?

i don't think "track has catenary" is a property of a railtype that can be meaningfully extracted from the arbitrary NewGRF data.

Maybe - but not necessarily - related:

* Sometimes vehicles want to know about their speed limit, and whether it is defined by the vehicle, the railtype, the bridge, the timetable, stopping, ...
  Currently there are some acceleration/deceleration flags, but an actual number to compare with "current_speed" may be more useful.

my previous idea about that was a vehicle state variable with values:

  • standing
  • accelerating
  • cruising (at max speed)
  • decelerating
  • unloading loading

possibly also add a bitset of what the reason for "cruising" is?

  • resulting acceleration force was (near) 0 (vehicle power exhausted)
  • railtype limit
  • bridge limit
  • curve limit
  • ...?

i feel like there was another ticket where that discussion would fit better

independent of that, adding railtype max speed to var4A should be possible, however

@frosch123

This comment has been minimized.

Copy link
Member

frosch123 commented Jan 7, 2019

Catenary is defined by RTF_CATENARY.

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Jan 7, 2019

Ok, but if we open that can of worms, people will request to know about 3rd rail. and the ability to issue sparks from somewhere other than the top of the vehicle, and...

(and by "people" i mean myself)

@andythenorth

This comment has been minimized.

Copy link
Contributor

andythenorth commented Jan 7, 2019

So...is it easier if I just continue checking 'ELRL' and ignore NuTracks and friends? o_O

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch 5 times, most recently from f01b3db to 2560ec4 Jan 15, 2019

@Eddi-z Eddi-z changed the title Add: Var 6A, a clone of Var 4A for querying poweredness compared to a… Some NewGRF variables concerning railtypes Jan 15, 2019

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch 2 times, most recently from 5b674bd to 0ae48df Jan 15, 2019

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Jan 15, 2019

Removed the lookup bit, and renamed the var to 63, because there's not enough relation to var 4A left to warrant a similarity in name.
New NML usage: "var[0x63, 0, 0xFF, ELRL]"

Added "has catenary" flag and railtype speed limit to var 4A (doesn't have to be the speed limit currently affecting the train, so i don't know how useful that is)

Show resolved Hide resolved src/newgrf_engine.cpp Outdated

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from 0ae48df to 10c5c0c Jan 16, 2019

@LordAro
Copy link
Member

LordAro left a comment

Looks fine, will wait for a GRF-God to approve & merge

@andythenorth

This comment has been minimized.

Copy link
Contributor

andythenorth commented Jan 21, 2019

We'll also want some docs once this is merged. Such admin :)

Show resolved Hide resolved src/newgrf_engine.cpp Outdated

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from 10c5c0c to 446d70f Jan 23, 2019

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Jan 23, 2019

So, i have no idea if this is the correct way to make a translation between grf railtype and game railtype.

Also, i have added a variable that makes that translation and then a reverse translation, this might be useful for checking whether two "logical" railtypes are mapped to the same internal railtype. this might need some more extensive testing

@LordAro LordAro requested a review from frosch123 Jan 27, 2019

@PeterN

This comment has been minimized.

Copy link
Member

PeterN commented Feb 22, 2019

Hmm, why does a NewGRF need to check mappings? It should be transparent to it.

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Feb 22, 2019

Well, my use case would be a wagon that can run on a 15t, 18t, 20t or 22t railtype, with different capacities. but if the railtype GRF doesn't provide any distinguished weight class types (as per the standardized railtype scheme), the different variations could be omitted.

@PeterN

This comment has been minimized.

Copy link
Member

PeterN commented Feb 28, 2019

Hmm, that sounds like information to be queried at load-time, not a varaction chain.

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Feb 28, 2019

yeah, we need something that can be used in action6/7/9/D. turns out i have totally forgotten how these things work.

@PeterN

This comment has been minimized.

Copy link
Member

PeterN commented Feb 28, 2019

Action 07 condition type 0D/0E can be used to check if a rail-type label exists. That's been there for 10 years.

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Feb 28, 2019

That is not enough to detect this case

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Feb 28, 2019

Slightly more elaborate answer, let's assume i have the following railtype table in my GRF (pseudocode):

rtt {
 rail1: [NAAN, RAIL],
 rail2: [NABN, RAIL],
}

now, NML will happily generate code to detect the presence of the railtypes with the existing checks, and fill in the fallback types as needed.

now the cases i want to detect here are:

  1. neither railtype is defined, and the fallback RAIL is used
  2. both railtypes are defined, and are different
  3. both railtypes are defined, but are mapped to the same railtype via alternate label

case 3 is not detectable with the current methods

@PeterN

This comment has been minimized.

Copy link
Member

PeterN commented Feb 28, 2019

Hmm, okay, alternate labels are a new one on me. Added 7 years ago...

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from 446d70f to bcce58c Feb 28, 2019

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Feb 28, 2019

Ok, this is probably now completely crazy (and untested)

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from bcce58c to 1dd97e7 Feb 28, 2019

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Feb 28, 2019

So how it is meant to work now is, assuming same railtype table as above, and the following action D:

-1 * -1 // ID, length
        0D // Action D
        00 // Result Parameter
        02 // Operation: Subtraction
        BF BF // New Var 3F: Check railtype mapping, +80 to indicate not-a-parameter
        00 01 // Which railtypes to check (Var 3F parameter)
        00 00 // leftover bytes from "data" (DWORD)

then the result in parameter 00 should be 0 if both are mapped to the same type (case 1 or 3 above) or non-0 if different (case 2 above), which then could be checked in a following action 6,7 or 9, as appropriate

@andythenorth andythenorth added the NewGRF label Mar 2, 2019

@PeterN PeterN added this to the 1.10.0 milestone Mar 4, 2019

@@ -693,6 +700,12 @@ static uint32 VehicleGetVariable(Vehicle *v, const VehicleScopeResolver *object,
return ret;
}

case 0x63: { // Powerdness relative to arbitrary railtype

This comment has been minimized.

@PeterN

PeterN Mar 6, 2019

Member

Poweredness

@PeterN

This comment has been minimized.

Copy link
Member

PeterN commented Mar 7, 2019

Have we got any test cases for all these changes?

@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Mar 7, 2019

Afaik @andythenorth had some test case for the "switch power between ELRL and RAIL" hybrid engine, which needs testing on more complex tracksets. but i haven't seen anything concrete otherwise.

@@ -6054,7 +6054,7 @@ static uint32 GetParamVal(byte param, uint32 *cond_val)
{
/* First handle variable common with VarAction2 */
uint32 value;
if (GetGlobalVariable(param - 0x80, &value, _cur.grffile)) return value;
if (GetGlobalVariable(param - 0x80, &value, _cur.grffile, cond_val==NULL?0:*cond_val)) return value;

This comment has been minimized.

@PeterN

PeterN Mar 7, 2019

Member

Spacing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.