(M.V.GetHeightAbovePoint) macro definition

I do not really understand what goal you are trying to achieve...

The macro "GetHeightAbovePoint" is only used to get the distance from any point in your bus (given with x, y and z) to the ground level (whether it's the terrain, a spline or anything, that is considered a surface.

If you want to get the general distance of some point to your coordinate system origin, you shouldn't really need to have a script that calculates that, because this value should be constant which means, you can just calculate it by yourself (e.g. using the Pythagorean theorem if necessary).

Zitat von kacperm

My question then, is - is there a variable that shows current height of the tram? If I opened shift+y it really shows current Height depending on the Z axis in the map, counting from zero, not from any terrain/spline, whatever it is. If it's not possible, how come I can count it, maybe bogie rotation from the origin may show up as going up/down hill.

No, there is no Variable to get the Global Height of the Vehicle. There is only the GetHeightAbovePoint where you simply get the next collison from the given Point (can be up or down, depends on what's the nearest).

This will only be possible by writing your own plugin to read the coordinates and give them back to the script, but i havn't ever done this.

Zitat von der_Nik_

Zitat von kacperm

My question then, is - is there a variable that shows current height of the tram? If I opened shift+y it really shows current Height depending on the Z axis in the map, counting from zero, not from any terrain/spline, whatever it is. If it's not possible, how come I can count it, maybe bogie rotation from the origin may show up as going up/down hill.

No, there is no Variable to get the Global Height of the Vehicle. There is only the GetHeightAbovePoint where you simply get the next collison from the given Point (can be up or down, depends on what's the nearest).

This will only be possible by writing your own plugin to read the coordinates and give them back to the script, but i havn't ever done this.

i'd say this would be possible with modifying the map. It should be possible to place a Plane with collission on Z = 0 (or any height you like below the omsi surface). now predefine an "offset height" of each entrypoint through the *.hof-file or hardcoded into the vehicle. make an in-vehicle "menu" to read or set the "offset height" for the specific entry point to use for your getheightabovepoint macro.
once you established your base height, any change in elevation can now be read by your plane on a known height plus (or minus) your offset to the point you check the nearest collission from.



Test Point Reference plane - of course - needs to be placed at a height that never gets too close or crosses the actual surface you drive on. it should also work if its placed high up in the sky.

Doing that from multiple points you can calculate the current angle on the vehicles forward axis with trigonometry.

without making the necessary changes to the map though - i can't think of a solution that doesn't involve some plugin that reads the coordinates directly out of the omsi memory. maybe auxi or the omsi hook thingy provides an option for that.

Also, if you just want the functionality to get some feedback from the rails you drive on, you could duplicate the railsplines and set them at different voltage levels (e.g. 1V for 1 ‰ of gradient, 2V for 2‰ of gradient etc.) and simply use the corresponding spline for the current gradient you can read the voltage value from the rail vehicle. it wouldn't be a smooth transition this way, but you could interpolate between both bogies based on the traveled distance. this wont work for crossings though afaik.

make sure that the offset to the terrain is big enough, so the dummy plane is always the nearest mesh in the z axis. this function may be buggy, especially when crossing a tile border. if the value "jumps" up to the surface for a frame or two, it may make sense to save the previous' frame height and compare it to the current one. if the difference is too big, ignore the value and/or "slowly" interpolate to the new one. lmk if it works out in the end, its always nice to see smart ideas come to life in a game that never was built to provide those functions.

I'd like to join in, as maybe my experiments will provide some helpful ideas. For the Rathgeber M5.65 tram that I am developing with PaulIP, I tried to build a model that is generally applicable on all maps, not just on "well built" maps that consider the z=0 plane from the start, like it is discussed above.

The way I tried to do it is by measuring the height of a point exactly over the first wheel of the tram, and another point height measured incrimentally in front of the first wheel of the tram, but at the same height. The incrimental distance is required so that the curve in the track will not affect the reading, and the height will still be measured between the point and the track plane, not the plane of the ballast or whatever. The idea is to determine the slope based on the change in height between the point in front of the wheel and the point above the wheel. If the track goes down, then h1 > h2 and so a negative rate of change in the slope would be picked up and so the slope will decrease. Alternatively, if h1 < h2 then the track is going up so a positive rate of change is taking place and the slope is increasing. I even implemented my own sin(x) function for the alpha angle using [newcurve] in the constfile, to try to establish the slope. Below you can find attached an exaggerated schematic of the concept.

Sadly, the experiments leave much do be desired so far. There is some achievement, in the sense that the tram may start creeping forward or backward, but that is inaccurate more often than not (which is why the player has the option to disable this experimental feature altogether). I simply can't figure out if the track plane is actually recorded as a point for the getheight function, or if it is the ground below the track. Sometimes it looks like the slope is calculated correctly and sometimes the slope changes for no reason on a flat piece of track.

I personally don't know how much time I want to dedicate to try to simulate tram gravity, as I've spent a lot of time getting a result comparable to me implementing a simple randomised positive or negative force to move the tram fwd / aft.

Looking forward to your thoughts, as I too would love to "crack" the tram gravity issue and have this simulated on the M-Wagen. I appreciate that maybe the only way is to have a map that is designed especially right for this gravity to work.

Zitat von Airplane09

not just on "well built" maps that consider the z=0 plane from the start, like it is discussed above.

it doesn't matter if the map is well built or not - it doesn't have to be on a specific height either. you need to know the initial offset from the spawn-point to your reference plane though.
so yes, the map would need to be modified for "my" solution to work, but it would generally function on all maps in a similar fashion.
your approach is basically the same from a technical point of view, mine just makes it more "safe" to calculate because there shouldn't be anyting else in close proximity to the reference plane.

what i generally would change in your approach is the following:

add a "dummy" plane to the splines that has collision but isn't visible, so no rails or switches can interefere your calculations.
extend the check-points from the wheel on the forward axis of the vehicle - so the distance between both points is bigger and therefore the values are bigger and easier to handle. you can offset those readings by adding the travelled distance to the calculation.
other than that, i don't really see any more optimizations.