Viconius wrote:+ I'd like to add the ability to adjust the track radius within a range just like the elevation currently allows in R&R (bit of it in the editor video, it's adjustable with the keyboard). Right now elevation can go all the way up to 15% grade. Steep yes, insane no. Insane to me means it isn't fun as a game control. I'd like to do that with track radius. The minimum will have to allow rolling stock not to look broken.
I assume this grade limitation would be only for track itself, not for terrain in general. That makes sense, and should help to prevent AI players doing really stupid things. Apart from that, personally I find the track laying in RT3 to be adequate. Not saying you shouldn't do better if you can, but I think something like that would be quite acceptable. It may not be perfect but it's fast and intuitive once you get the hang of it.
+ Multiple locomotives are not planned right now. My take on this was that Railroad Tycoon games gave up most of the advances of modern locomotives for nominally the same number of cars of greater weight. The reality is that is way short of the actual ability. If we get to the 15 or so consist, I think we'll make better use of locomotive differences that more accurately reflect the sheer enormity of what get's moved now. The exception to this will be passengers. To this end, I'd like to add more variety to the consist for dedicated passenger routes. More car types to improve rates and rot factors and ways to promote travel as a priority for the locomotives using particular tracks. Like so many questions regarding strategy games, this has an answer but the process of getting to the answer often has multiple conditions. Could the game support multiple locomotives on a consist... definitely. How and why are the devil's details.
My 2c here is that I wouldn't think it necessary to specifically code options for multiple locomotives. Since you're more or less trying to do the same job as RT3 modelling, I assume file structures will be somewhat similar. This is, in itself, enough to do the job for multiple locomotives.*
Let's face it: anyone who wants to do locomotive modelling is going to have to be fairly determined, and have an ability to handle some level of coding as well as the actual modelling. I think you should deliberately avoid trying to make the entire process idiot-proof. Trying to do that will only burn up dev time and budget, and someone will always build a better idiot anyway. As long as the file structures are documented, someone will be able to write a Blender > R&R export script for models (this is actually my next project for RT3 too, since I already have one loco almost fully modelled and some more underway, and just have to learn Python). The big problems with RT3 modelling are lack of documentation and lack of suitable export scripts. What the devs did for RT3 was to make some very simple things idiot-proof, while leaving more advanced modellers totally hamstrung.
Anyway, my point here is that by cunning use of locos slots, tender slots, and trucks for both, anyone sufficiently determined can create multiple units that, as far as the game is concerned, are read as one unit. I already know how to do this in RT3. It's just that doing it in practice is a bear at the moment because of the exporting problem, and building models from scratch via direct hex coding is no fun at all.
You don't have to build in every possible option in doofus-proof GUI form. You just have to build in flexibility at a fundamental level. If you do that, people will take it and run with it. I'd be taking this as a doctrine all the way through, from modelling to event scripting to whatever, because ultimately the longevity of this game will depend on
determined people doing things you didn't think of.
+ What will our Editor allow you to do? Well, there's sort of two editors... or will be. The first is the map editor and tools to make that happen. I'm doubting this will be anything less than what RT2/RT3 had but probably more configurable for the player. Since most of you folks know what that is, I'll skip that for now. I'm hoping to be able to do more with letting players just choose a region of the world and import a map of a selected region or import a Dem map of their choosing.
Sounds good. If you're interested, with RT3 we've figured out how to apply Google Earth satellite shots onto RT3 map terrain too (including piecing together large tiled images to correct GE's projection to the cylindrical projection used on DEM's).
.....All that just to say, the event editor is not even roughly prototyped yet. I just want it to be at least as good as the RT series.
Ok, now I'm getting interested. By the way, I notice you are promoting ideas like Mule Skinner and Top Tinkerer and whatever for chairman options. Two ways of looking at this. The obvious way is that it provides more options. A less obvious way is that in some ways it may provide fewer options. How so? Well, what you are effectively doing is locking in pre-determined pathways. There may be several of them, but they are still locked in. Under some circumstances this could reduce flexibility for scenario authors. So, if you are determine to lock in these pathways, it may be a good idea to allow the event editor to detect which option is selected. This would then allow a scenario author to compensate, or even to extend the options, if they thought it desirable.
+ Adding player created content. This is a big, big add in my opinion. For this it will be a system that can import objects and properly identify them in the game. It's going to be both a UI and a code hurdle. However, using Steams Workshop, we will have a template that has already be proven in games like Civilization. It even comes with rating and sorting options. Fusing it properly to the code is a lot of ifs and thens... so to speak. Hopefully, Darrin will chime in on that over time. The goal with this is to avoid the hurdles that the guys that did RT3's mods had to overcome. If we can do that, I think more people will use mods.
Obviously this is going to be subjective, but personally I see no reason why this should be a UI hurdle. There's a good case for not bothering with a GUI. Any mods, like locos or whatever, are just going to be files that have to be copied to a particular directory. The files can be prepacked in the correct folder structure so that all is required is to download the package, then copy the entire package to the R&R root directory. Really, who needs a GUI for that? Identification shouldn't be a problem since any mod worth having should include its own identification.
I honestly cannot see why any of this has to be more complicated than the way it's done in RT3, which is really simple. The problems with RT3 modding are nothing to do with actually getting the mod files into place. They're purely to do with getting a model out of a modelling app and into RT3's custom .3dp file format. The rest is a piece of cake for anyone determined enough to actually model anything.
*ETA: I just thought of one caveat here, that being skinning. RT3 skins are limited to 1024x1024 max, and trucks for any loco or tender can only call the same skin image as the parent loco or tender. This can be limiting when trying to do anything a bit out of the ordinary.
Take a Garratt as an example. I've thought about how to build these, and it gets tricky to get a decent resolution on the A skin for the front truck, main body, and rear truck while fitting them all on a 1024x1024 skin. You can fit them all in, but it'll look pretty rough at close range.
I'm not sure what you are thinking of for maximum skin size. Obviously if the maximum size was unlimited this would get around the problem (and you could just rely on modellers to have enough sense to not crash the CPU). Another way, if you think it necessary to have a limit on max skin size, would be to allow the files for trucks to call whatever skin image they liked. Again, you'd be relying on modeller's to exercise some sense, but that's their problem. If they don't understand the practical limits of game asset coding then they won't be any use anyway.
A Linux OS that ties you to a proprietary platform that has a bad name for screwing people around? That's pretty much the exact opposite of the Linux ethos. Nobody who wants a Nix box is going to want an OS like that.
