[Genma Saotome]

Idea: Use the Wagon() section to pass additional .wag characteristics to game.
Application:

• Allow specification of freight animation files to be placed within individual Wagon() sections.
  
• Allow specification of .inc files to be placed within individual Wagon() sections.

Benefits:
Significant reduction in the number of .wag files.

• Example: for a model of open top car the creator may have defined several freight animation files show different loads. This results in multiple .wags to be defined and maintained. Moving the .freight animation line from the .wag file to the .con file means only one .wag file is needed -- one for the empty car.
  
• Example: for a model of a closed top car the creator may have defined several .wags to represent loads vs. empties. Creating an .inc file for the parameters specific to loaded cars and placing the reference to that .inc file in the .con file will result in needing only one .wag -- for the empty car.

Had this feature been provided by KUJU we would all have just a single .wag file for each car with a handful of lading.inc files, each of which holding ~ 10 parameters.


Transition plan
Objectives

• Let end users implement the new functionality in stages at their own pace.
  
• Handle duplication of parameters in the standard way

[DirtyRam]

Hey Dave, excellent idea, for sure.

[James Ross]

Genma Saotome, on 27 June 2018 - 09:14 AM, said:

Idea: Use the Wagon() section to pass additional .wag characteristics to game.

Very interesting; we will certainly want thing kind of thing in our own new file formats.

Obviously thinking about the implementation a bit, I do not think it is going to work to allow arbitrary data in here, i.e. actually setting parameters directly (as that would require some very careful recording/translation to pretend the data was really in the .wag or .eng file and looks like a complex job due to the change in nesting), but I do think we could support a list of include files that work like this relatively simply:

What you actually have saved on disk

Train (
	TrainCfg ( consist
		Wagon (
			UiD ( 0 )
			WagonData ( carname cargroupname )
                        IncludeFile ( northern_division.inc )
                        IncludeFile ( loaded_coal.inc )
		)
        )
)

Wagon (
        ...
)

What Open Rails acts like you have

Wagon (
        ...
)
Include ( northern_division.inc )
Include ( loaded_coal.inc )

I believe that will get you where you want to go in terms of functionality, as we neither care about repeating sections (like "Wagon") nor the individual settings (the last one wins usually). Positioning the "fake" Include() anywhere other than the end of the file may be a challenge, but if you think that's worth trying we can certainly have a go.

(Note that the name of the item in the .con file can't be "Include" because that will trigger the actual include functionality, but you're free to come up with whatever name you like for it.)

[Genma Saotome]

James Ross, on 28 June 2018 - 11:11 AM, said:

Obviously thinking about the implementation a bit, I do not think it is going to work to allow arbitrary data in here, i.e. actually setting parameters directly (as that would require some very careful recording/translation to pretend the data was really in the .wag or .eng file and looks like a complex job due to the change in nesting), but I do think we could support a list of include files that work like this relatively simply:

What you actually have saved on disk

Train (
	TrainCfg ( consist
		Wagon (
			UiD ( 0 )
			WagonData ( carname cargroupname )
                        IncludeFile ( northern_division.inc )
                        IncludeFile ( loaded_coal.inc )
		)
        )
)

Wagon (
        ...
)

What Open Rails acts like you have

Wagon (
        ...
)
Include ( northern_division.inc )
Include ( loaded_coal.inc )

I believe that will get you where you want to go in terms of functionality, as we neither care about repeating sections (like "Wagon") nor the individual settings (the last one wins usually). Positioning the "fake" Include() anywhere other than the end of the file may be a challenge, but if you think that's worth trying we can certainly have a go.

(Note that the name of the item in the .con file can't be "Include" because that will trigger the actual include functionality, but you're free to come up with whatever name you like for it.)

James, I am perfectly comfortable leaving the technical matters up to technical people so long as the actual objective is met. My only concern about what strings appear to end users is that they make sense to end users. Chris mentioned some difficulty about using the WagonData() clause for this purpose and suggested a perfectly good programer's solution... I countered with CustomWagonData() as it did a better job of conveying to the end user what it was all about.

I am concerned as to why Include() should not be used. I was figuring the only parameters that would appear in any referenced file would be parameters found only in a .wag file and that they would be presented via an .inc file (the whole idea grew out of my work on .inc files). Are you thinking of other kinds of parameters besides .wag parameters? If not I think it's pretty important that however the parameter is named it works upon the original .wag file as any .inc file would and unless there is no way to get around it the .inc suffix should be used. My reasoning for this is we can craft an .inc file today for use in (yet another) .wag file and tommorrow when this new functionality is available reference w/o change that same .inc file in the .con file, allowing the depreciation of that extra .wag.

Also, I did not ask for anything similar to CustomLocomotiveData() tho conceptually the idea would be identical. As for application, it would be one way to present specifications for a different appearance of exhaust and/or lights so it to offers a way forward to having a single .eng file for a skinned model.

I will return to the PM exchange I had w/ Chris and add your name.

[Goku]

Quote

Example: for a model of open top car the creator may have defined several freight animation files show different loads. This results in multiple .wags to be defined and maintained. Moving the .freight animation line from the .wag file to the .con file means only one .wag file is needed -- one for the empty car.
Example: for a model of a closed top car the creator may have defined several .wags to represent loads vs. empties. Creating an .inc file for the parameters specific to loaded cars and placing the reference to that .inc file in the .con file will result in needing only one .wag -- for the empty car.

If you want this functionality, then better define all variants in WAG file and in CON file we can use only variant name, for example:
WagonData ( carname cargroupname carvariant )

But I don't think that it is something new. Now with includes, you can make one master WAG, and simple WAG variants. Placing everything in one file would reduce file loading time, but because you use much more INC files, this doesn't matter.

[Genma Saotome]

Goku, on 28 June 2018 - 12:51 PM, said:

If you want this functionality, then better define all variants in WAG file and in CON file we can use only variant name, for example:
WagonData ( carname cargroupname carvariant )

But I don't think that it is something new. Now with includes, you can make one master WAG, and simple WAG variants. Placing everything in one file would reduce file loading time, but because you use much more INC files, this doesn't matter.

An interesting idea.

The objective I have in mind is to get to a place where only one .wag file per skinned mesh is needed and that one defines an empty car. The first step was to figure out how to get rid of all of the loaded .wag files. I have identified 10 parameters whose values change on account of weight. It makes no sense to set up yet another .wag so you can change the value of those 10. Far better to put those 10 someplace where they could be used as needed by whatever empty car .wag files they'd be correct for -- call them a lading or load file.

You can see an example in this post: http://www.elvastowe...post__p__237991 That is what my .wags look like right now.

My original thought was to specify a load file using new line for each car in the .con file. That way y ou can have whatever variety of loads you want on a .con by .con basis. If I understand you correctly the same can be accomplished with a new clause in the .wag file -- let's call it Variants() -- where you can define n number of instances uniquely identified by the value of VariantName() and then put the VariantName() into the .con file for each car you want changed. Sounds reasonable but I'm sure this will be to your dismay, I'd still put each of the 10 into their own .inc file and get them via Include() in the .wag because each of those load files are valid for all other instances of the same mesh and their .wags. By this I mean if one mesh has been skinned 4 times I'd want just one occurrence of the lading file to be available to all 4 wags. The last thing I want is to have duplication of parameter lines all over the place. 15 years of de-normalized data is enough.


I am aware there is a price paid for more files, traditional disk being particularly slow. I use an SSD to hold my files and that helps a lot. Another solution could be a process to do all the file reads from some library and drop validated, compressed binaries into the directories where they will be read by OR, perhaps even structuring the data into the same object forms the OR software uses. It's a bit of a bother to do before running the game but perhaps if the difference is measurable in game performance in might be worthwhile.

[Goku]

Important thing is to think about how you create consists. Your suggestion about includes and freightanims in CON file would make creating consists really difficult and time consuming for end user. You need to remember that consists are usually made by end user and not wagon designer.

[Genma Saotome]

I disagree Goku. The .con editor goes along as it does now, letting the end user select locomotives and cars. Each car .wag converted to this method reflects the conditions correct for an empty car. The other .wags remain teh same as they are today. For whatever "new" .wags the user wants loaded he gets a list of names correct for that car and pick one. Repeat as needed. Once it is done it is done. Copy the .con file and rename it, edit that one to come up with something similar but with load edits something quite different. Over time more and more of his .wags can be converted but at his own pace and by his own choices.

It may be a bother for you to code it but it really isn't much of a bother for the end user, especially if the OR functionality allows for mixing old and new. The places where I have implemented this idea are in freight car folders where the same car design was owned by dozens of railroads. The empty car data in one .wag is correct for all of them, excepting for the the strings in Name()n and sometimes the necessary uniqueness of the .s file name. A dozen or more lading files sit together in the a neutral location, all equally valid for all occurrences of .wags for this model. The fact is there is only a 1 line difference between the empty and loaded .wag files for the same car. It cannot be made any easier.

The only thing the proposal adds is to move that one line that is unique to the loaded cars from a .wag to the .con. Do that and you no longer need any .wag files for loaded cars.

This may not be well suited to those models that have just two .wags -- one empty, one loaded -- where that's all there ever will be, but where there are dozens of .wag files for the same mesh (ignoring skins) is it a significant simplification in terms of files to manage and if the end user wants, a very simple way to increase variety as the loads file has just 10 parameters. I have a spreadsheet I'm using that generates all of the parameters for the .wag... it takes me a couple of minutes to do the .wag for the empty car and about 30 seconds to do each load. And it is all correctly done.

[Goku]

Quote

the user wants loaded he gets a list of names correct for that car and pick one.

This can be achieved only by the way I described above. With variants specified in WAG file, so consist editor knows from what user can select.
With your idea with inc and freightanims directly in CON file, there is no info about what can be chosen.

[Genma Saotome]

As things are today, not via the con editor. Nor is the functionality in OR. I'm setting out objectives here with the expectation that if the ideas are good they'll eventually be developed. In this case in makes no sense for the con editor to change first because it's not at all clear how OR wants to handle it. When the OR software is ready the end user can edit existing .cons by hand until such time the con editor catches up. In the meanwhile people can follow the example I've shown in the link I posted earlier and do something quite similar by hand in the .wag itself.

With open source volunteer teams there really isn't any other way than, essentially, throwing something against a wall and seeing if it sticks. It'll get developed... or it won't. IMO the benefit of getting rid of as many .wag files as possible has merit and reducing those that are kept to their essence of just what varies with pointers to the rest -- just 10-12 lines. I think that approach will carry the day.