Bugs loading cabview (X.1874)

Bug #1254531 reported by Carlo Santucci
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Open Rails
Expired
Medium
Unassigned

Bug Description

Loading this electric loco pack
http://www.trainsimhobby.net/infusions/pro_download_panel/file.php?did=1286&file_id=1344
and its cabview
http://www.trainsimhobby.net/infusions/pro_download_panel/file.php?did=1524&file_id=1583
and selecting consist FS.E444.027 leads under MSTS to the first picture attached.
Under ORTS I get the second picture.

There are at least three differences:
1) Needle Agomedio1.ace is not correctly shown (is present in some instances in the cabview)
2) The square on top right showing the activation phases of the loco (attivazione_loco.ace) is not shown correctly.
3) in ORTS a strange diagonal rectangle (attivazione_IR.ace) appears, however this is the only case where maybe the different behaviour is justified.

Logfile is attached too.

Tags: cabs graphics
Revision history for this message
Carlo Santucci (carlosanit1) wrote :
Revision history for this message
Carlo Santucci (carlosanit1) wrote :
Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Also trying to change parameters for the attivazione_loco.ace entry I don't get the correct view.

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

By correcting the corresponding line to
NumFrames ( 8 4 2 )
in both E444R-3-SCM.cvf and E444R-3-SCM_rv.cvf the warning of attivazione_loco.ace has gone, and the activation phases show correctly.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Thanks Peter,
I also checked this before posting the bug report, but it didn't work to me. Now I understand why: I modified only the E444R-3_SCM.cvf file and not E444R-3-SCM_rv.cvf, however the front cab didn't work. So I now discover also that it is enough to modify the E444R-3-SCM_rv.cvf file (withouth modifying the E444R-3-SCM.cvf file) to have both cabviews (front and rear) working. This does not seem correct to me.

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

Doesn't for me either. :)

The needle bug is in conjunction with r1793 and Bug #1088568. When I remove part of that fix, I can make this to work correctly, but of course the other one will be wrong in this case.

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

All right, looks like only downscaling is allowed for dial textures, upscaling attempt by cvf file should be refused. I attach a patch here, but I will commit it only tomorrow, since I ned to do some more testing, and it is getting late now. :)

Peter Gulyas (pzgulyas)
Changed in or:
assignee: nobody → Peter Gulyas (pzgulyas)
Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Hi Peter,
I tested your patch in the specific case, in case related to bug #1088568 and in a generic case and it works well; of course it's good if you also make tests, because needle working is a bit tricky, and there are many possible cases! Thank you.

Now that attivazione_loco.ace is shown in the correct size I noticed another bug: the NumPositions () order of frame numbers does not seem to be considered: in fact the blank frame (frame number 6) is shown with dynamic brake value 1.0 instead of dynamic brake value 0.0, and so on, in the inverse order. Maybe this was not evident up to nowadays because usually one inserts frame numbers in a progressive order rather than in a regressive order.

Another malfunction in relationship to MSTS concerns attivazione_IR.ace. In case of 180 degree rotation it should completely disappear from the viewing field (because it is used ad a masking texture, that must disappear in such case), while in OR the texture appears rotated by 180 degrees as it should, but it appears above the position where it is at 0 degrees, instead of disappearing at the left of the viewing area.

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

I fixed bug (1) of original post in r1878.
(2) The NumPositions() handling is a mess, as I remember, Chris tweaked it last time.
(3) I could not find what option or setting tells MSTS not to show this in its reversed state. Strange...

Changed in or:
assignee: Peter Gulyas (pzgulyas) → nobody
Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Thanks Peter.
Referring to point 2 if nothing can be done I will suggest people to modify the .cvf files.
Referring to point 3 it's not a particular parameter: the pivot point is at the extreme left of the screen and the .ace file is shown from there towards right at angle 0. So at angle 180 the .ace file rotates completely outside of the screen (in MSTS) and therefore should not be visible.

Revision history for this message
Peter Gulyas (pzgulyas) wrote :

But how do the X coordinate of the pivot point is defined? The Pivot() function only defines the Y coordinate...

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

From my bible (USA trainsim forum) I read: "Pivot specifies the number of pixels in the Y direction (i.e. down) from the top-center of the needle graphic." So it seems to work correctly.
I re-checked in MSTS: in fact the author of the cabview has used a trick: there is a superposition of two controls on top left of the cabview (attivazione_loco.ace and attivazione_IR.ace). When the sequence comes to the transparent frame of attivazione_loco.ace, MSTS lets become transparent also the superimposed attivazione_IR.ace. So it is a trick that does not need to work under OR, I think. Problem n. 2 remains... apparently inverting both NumPositions and NumValues does not work correctly under MSTS.

James Ross (twpol)
Changed in or:
status: New → Triaged
importance: Undecided → Medium
tags: added: graphics
James Ross (twpol)
summary: - Bugs loading cabview
+ Bugs loading cabview (X.1874)
Revision history for this message
Cédric GNIEWEK (sharpeserana) wrote :

Does the problem still happen with version 1.4?

Changed in or:
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Open Rails because there has been no activity for 60 days.]

Changed in or:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.