LogMate Problems after TS2016 upgrade

[newbouy]

If anyone can explain whats going on with this Logmate problem i would be very gratefull to them.In the recent sale i decided to buy the UK 1st Class Edition DLC to get hold of the "Riviera Line in the 50s" route.Also this automatically changed my old fully updated Railworks / TS2016 core program to the latest full version of TS2016.I noticed a few minor differences in games user interface but everything works fine no problems.Then when i ran Logmate to do some more work on a project i noticed it wasnt behaving as it did before the upgrade.Before i could display lots of tabs in the Logmate screen like Pathing ,Streaming ,Sound , Script Manager ,Rail Vehicle Manager ect ect but now only 3 tabs called All , Run TimeError and Content are displayed.Changing the launch options switches in Steam for example "-LogMate -SetLogFilters="Script Manager" -lua-debug-messages" doesnt seem to have any effect on Logmate.Im now wondering if the new full TS2016 core program has done away with all the options that LogMate used to have.BTW i already have verified the game files on steam twice with no effect.

Thanks Newbouy

[AndiS]

Either I messed up my test or it really stopped working!

My options are:

Code: Select all

-LogMate -SetLogFilters="Script Manager,Signals,Pathing" -lua-debug-messages -SkipIntros

I only get the same tabs as you.

The thing is, I cannot say when it happened because I stopped using it long ago. I got too tired with repeatedly cleaning it out so it does not cripple the game. I write my own log files now as that does not cripple the performance.

The question is, what you usage of LogMate was before. I never used most of the tabs you mention.

[newbouy]

Hello AndiS thanks very much for the quick reply.At least im happy to know im not the only one with this problem , i was beginning to worry it was some serious corruption in windows that was causing LogMate to not work right but now you have the same problem i can rule that out.I definately know that Logmate was working fine before the full TS2016 upgrade because i was using it to debug a wagon script i was writing.So AndiS problem now is how the hell are you suppose to debug scripts if you cant print messages to LogMate .I dont really think alot of the top developers used LogMate anyway because i noticed even with some of the more recent DLC releases when you ran them through LogMate there was streams of scripting errors printed to the "Script Manager" Tab but the locos still ran fine in the game.Obviously LogMate was over reporting maybe.When you mention that you write your own log file i assume you write your own print routine and embed it into the script you are working on ? I was just looking at a PDF document by Rudolf Heijink called "Scenario Authors Guide" and he has a few script routines for printing messages to an offline file or directly to the game screen.Looks like i will have to go down this road unless someone else knows how to get Logmate fully working again particulary the script debugging side of it.

thanks alot Newbouy

[AndiS]

This is what I do. You only need the first half.

Somewhere really early, i.e., in function Initialise:

Code: Select all

logfile = io.open("Assets/AndiS/FPSignals/logs/logfile.txt", "w")

Anywhere you like:

Code: Select all

logfile:write("some stuff for the log\n")
logfile:flush()

The second line makes sure the stuff from the first line really goes to the file right now. It would be more efficient to live without it and let the system do the writing whenever the buffer is full. But in practice, you cannot have that luxury for a series of reasons, one being that no one tells your script when to close the file.


The above would be fine, if you were sure that there will never be a second instance of your asset in the game. Of course you can't. In such a case, you read the log of the instance that opened the file last, what the others write is lost.

In that case, you use "a" instead of "w" in io.open. Now you always append.

This is another reason to flush after each and every message.

Now you need to delete the log after each test run or else you get messed up in old error messages that don't relate to your current script version.

What I do is this:

Code: Select all

local tim = os.time()
local dat = os.date("*t", tim)
local datestring = string.format("%4d%02d%02d %02d%02d%02d",
   dat.year, dat.month, dat.day, dat.hour, dat.min, dat.sec)
logfile = io.open("Assets/AndiS/FPSignals/logs/log " .. datestring .. ".txt", "a")

You can go without the seconds, but then you should be sure to never fix a bug in under 60 seconds, else you append to the old log after the super-fast fix.

You will find that often enough, some instance opens the file before the second boundary and the other after it. (e.g., at 10:00:02.995 and at 10:02:03.001). Then the log messages are split across two files.

You can try to open the log file for reading ("r") only to know if it exists and try the same for the second before now and write to the one that exists, but it starts to become childish here.

I ended up sending messages from signal to signal, originating at a dedicated invisible signal object to tell signals what to log, and added the time stamp to that message. Of course, it is quite an overkill in the normal case.


You will want to prefix our log file lines with some kind of ID of the sender. Signals have their plates, rail vehicles have their unique numbers, too. I found this in an old post, not sure I ever tested it myself:

Code: Select all

number = Call("GetRVNumber")

If you are interested in the timing, you can either add up all the values of time in Update, assuming that you never call EndUpdate.

Code: Select all

secondsSinceStart = Call("GetSimulationTime")

gives the seconds since the scenario started.

Code: Select all

secondsAfterMidnight = SysCall("ScenarioManager:GetTimeOfDay")

gives the time in sync with what is defined in scenario editor. So in the case of signals, this is what I use to debug which train goes where and when.

[newbouy]

Thanks alot AndiS i will try and embed that into my script and report back with a result.Yes using the Call("GetRVNumber") and including it in the output text would be very handy for tagging the messages.I also noted when using Logmate it used to sometimes include a latitude and longitude coordination of the asset that produced the debug message.I think it used this in the "Pathing" and "Script Manager" Tabs.Just a quick question which confuses me is what determines when to use a local varible or a global varible.I read local varibles are more prefered and efficient then global varibles.

Thanks alot Newbouy

[AndiS]

Global variables are condemned by modern (i.e., post 70ies) programming theorists. However, the Kuju scripts are built on heavy usage of global variables. Various functions get called by the system at different times and to maintain the state of the signal or engine, you need to resort to global variables. You could introduce objects, if you like, but I don't know of someone who went that way.

Local variables are only valid in the function where they are found. This means that the memory they use is fried for other stuff once the function ran through. And the word local tells the reader that this variable is not used elsewhere. So they are preferable for short-term storage of intermediate results.

But using globals instead of locals is not the biggest of crimes in this scheme of things.


Regarding the location, I only know for signals, they always had this long/lat prefix. But I found it quite cumbersome to locate the signal in question by flying there and sinking down to the ground with the eyes glued to the compass and LogMate at the same time.

One thing I forgot to mention is that I tend to separate columns in the log file by tabs (could be colons, too) and paste that into Excel or LibreOffice. The filter feature of these programmes is quite handy to zoom in what one agent did and zoom out from a certain line to what the others did at the same time. (Agent would be signal or vehicle.) You need this most when debugging message passing or other forms of interaction.

[newbouy]

Hello AndiS it works ok but the only problem i had was setting the folder location of the log file.In the first line of your code i just changed the path like shown below.What happened is the script created a file called "AssetsNewbouyDebug_Logslogfile.txt" in the Railworks main folder and not in the folder i had set.

Code: Select all

logfile = io.open("Assets/Newbouy/Debug_Logs/logfile.txt", "a")

Looking at some of Rudolf Heijink`s scripts i noticed the path was written differently (double forward slash) so i modified the line shown below and now it works fine.The log file is now created in the correct folder.I know sometimes scripts for assets are written slightly differently than scripts for scenarios so wheather it has anything to do with that i dont know.This script is for a rail vehicle.

Code: Select all

logfile = io.open("Assets//Newbouy//Debug_Logs//logfile.txt", "a")

So basically its pretty straight foward and i can just replace all my lines that were printing to LogMate with the new code.I know how to print varibles within the text so i will have a go at adding the time stamp and rail vehicle number.I dont know if there is a text editor available which automatically refreshes the log file so the new added lines are shown without having to reload the file every time.I will have a look and see whats available.

Thanks alot newbouy

[AndiS]

I have never seen a double forward slash. Double blackslash would be logical as \\ really just means \, because \ normally introduces a sequence like \n.

One thing I remember is that it did not work when the folder to contain the log file did not exist. No idea whether that would have some bearing here.


I use Crimson and Notepad++ and both tell you that the file has been modified but you have to confirm that.
Google claims that you can disable the confirmation dialogue in Notepad++ :
Settings -> Preferences -> MISC -> Update silently
I try to leave Crimson for Notepad++ anyway, so that would be another reason. I did not test it yet.

[JamesLit]

Don't want to derail the subject of this thread but, speaking of things LM has never done to us prior to TS16, I have found that on certain routes (but in all scenarios for them), LM being open will cause TS to crash when it goes from the loading screen into the scenario or editor (route or scenario editor). If you manage to close LM in time as it sits there complaining about terrain issues, the scenario/editor will load successfully - otherwise, TS will give up completely, and will not CTD but will not respond, as LM spews out tens of the same error relating to terrain problems every second...... any of you experienced this?

[AndiS]

I can't say much about terrain issues - my test routes never have that.

I do note reports on track ribbons being out of sync, both on default content and my own stuff. The interesting thing is that they come and go, but not totally random.

I agree with the opinion that DTG stopped using LogMate as you get a few easy to fix errors now and then when you load a default route (like some Munich lamp in the Cologne route). No big things, but plain to all who read the log.

I guess we all need to be realistic. This was old software when it was released (it is obviously reused from some other project). And the original game was completed about a decade ago. Kudos for keeping things going for so long, but clearly, their energy is with the new thing for quite a while now, and rightfully so.