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

@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)

src/newgrf_engine.cpp Outdated Show resolved Hide resolved
@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from 0ae48df to 10c5c0c Jan 16, 2019
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 :)

src/newgrf_engine.cpp Outdated Show resolved Hide resolved
@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.

@andythenorth andythenorth removed their assignment Mar 2, 2019
@andythenorth andythenorth added the NewGRF label Mar 2, 2019
@PeterN PeterN added this to the 1.10.0 milestone Mar 4, 2019
src/newgrf_engine.cpp Outdated Show resolved Hide resolved
@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.

src/newgrf.cpp Outdated Show resolved Hide resolved
@LordAro

This comment has been minimized.

Copy link
Member

LordAro commented Aug 17, 2019

Hi, there's been no activity on this for over 5 months. If no more effort will be put into this PR, it will be closed in the next week or so

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch 2 times, most recently from aafb449 to bda8e8f Sep 14, 2019
@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Sep 14, 2019

I'm having 3 thoughts about this PR right now:

  1. the speed limit stuff feels slightly too ambitious right now, and the raw railtype speed limit doesn't make much sense on its own, it might be better to leave it out right now
  2. i need a second opinion on the global-var-with-parameter bit, as it might be a tiny step too hacky
  3. some bits of this should maybe be extended for roadtypes, but that could be a separate PR
@frosch123

This comment has been minimized.

Copy link
Member

frosch123 commented Nov 2, 2019

  1. Seems like I suggested a "maximum speed" variable. However, it seems that this is already available in var 0x4C. The pure "railtype speed limit" appears useless to me. So, remove.
  2. Yes, this is completely different from what NewGRF usually does.
    2a) VarAction2 variables with parameters must be in range 0x60-07F, otherwise the parameter is unusable.
    2b) If the variable is not available in VA2, and it does not seem to make sense in ActionD either, then why assign a variable at all?
    2c) Adding a new Action7 operator "check if railtypes are mapped to the same type" seems like the more natural way to do it.
    2d) One could either pack two RTT-indices into a 2-byte sized value, or put two RT labels into a 8-byte sized value (as for var 0x88).
    2e) Is there consensus on what to return if both railtypes do not exist?
src/newgrf_engine.cpp Outdated Show resolved Hide resolved
src/newgrf_engine.cpp Show resolved Hide resolved
src/newgrf_engine.cpp Outdated Show resolved Hide resolved
@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from bda8e8f to 4999e23 Nov 3, 2019
@Eddi-z

This comment has been minimized.

Copy link
Contributor Author

Eddi-z commented Nov 3, 2019

1.  So, remove.

Done

   2c) Adding a new Action7 operator "check if railtypes are mapped to the same type" seems like the more natural way to do it.

added this now:

  • 0x13: check whether two railtypes are the same
  • 0x14: check whether two railtypes are different
   2d) One could either pack two RTT-indices into a 2-byte sized value, or put two RT labels into a 8-byte sized value (as for var 0x88).

went with a 2-byte sized value, as the 8-byte stuff seems too weird/hacked to me, which would put it back into the same problematic category as the var3F stuff

   2e) Is there consensus on what to return if both railtypes do not exist?

went with "check will fail if either railtype is not defined"

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch 3 times, most recently from 75c3637 to c556b92 Nov 3, 2019
src/newgrf.cpp Outdated Show resolved Hide resolved
src/newgrf.cpp Outdated Show resolved Hide resolved
src/newgrf_engine.cpp Show resolved Hide resolved
@@ -6252,7 +6253,7 @@ static void SkipAct5(ByteReader *buf)
* @param grffile NewGRF querying the variable
* @return true iff the variable is known and the value is returned in 'value'.
*/
bool GetGlobalVariable(byte param, uint32 *value, const GRFFile *grffile)
bool GetGlobalVariable(byte param, uint32 *value, const GRFFile *grffile, uint32 parameter)

This comment has been minimized.

Copy link
@LordAro

LordAro Nov 3, 2019

Member

parameter should be documented

This comment has been minimized.

Copy link
@Eddi-z

Eddi-z Nov 3, 2019

Author Contributor

I'll probably remove this commit

This comment has been minimized.

Copy link
@LordAro

LordAro Nov 23, 2019

Member

Still a thing...

@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from c556b92 to 526ee5e Nov 3, 2019
…re identical/different
@Eddi-z Eddi-z force-pushed the Eddi-z:var4A branch from 526ee5e to 70f0ca3 Nov 3, 2019
@LordAro LordAro dismissed their stale review Nov 23, 2019

dismiss

@andythenorth

This comment has been minimized.

Copy link
Contributor

andythenorth commented Dec 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.