• Welcome to SC4 Devotion Forum Archives.

RealRailway (RRW) - Development and Support

Started by Swordmaster, June 14, 2013, 08:42:19 AM

Previous topic - Next topic

0 Members and 4 Guests are viewing this topic.

cogeo

Quote from: Swordmaster on June 21, 2013, 09:03:45 PM
Cogeo, it's "only" a matter of coming up with the textures. I don't see why we couldn't take a look at how to implement it if a third party modder were to make them. But I don't see anyone in the NAM team doing that at this point. And the further I expand the RRW, the more work it'll be to make those textures and the more code it'll take. Judging from the SAM's 150,000 RUL2 lines, a full RRW override could multiply this easily.
Sure, the texture work is considerable, to say the least. But I don't think anyone asked YOU to make all these. And while nobody seems to be interested "at this point", some may be suddenly appear in the near (or mid) future. What we could do now is only reserve the IDs (and assign them to modders, if they are interested). And I will repeat my proposal about puzzle pieces, which require no RULs and are quite simpler to make (actually as soon as the first set is made, the next ones will be mostly copy and in-place replacement. Some modders regard puzzle pieces as "obsolete", considering the few extra clicks required to plop them, not taking into account their simplicity and efficiency (and "economy" in resources and ID-range requirements). We can even make some 2-, 3- or 4-tile long straight sections for those who are easily bored. It would be nice to have ALL the above (and addtional) track types in the same city at the same time. And don't get me wrong, most people will actually still want to use the original rail textures, for a variety of reasons, among others the existence of so many stations and other rail-related lots (eg yards) using the original textures (or similar texture packs like NCD's); many of them even have even the original track texture modelled into the station's model. That is, many players will actually opt to rather stick with the original ones, if they are forced to choose. The only way to make them use the new ones, is let them keep the originals as well.

Quote from: memo on June 21, 2013, 11:08:21 PM
Not to mention the considerably longer start-up times due to the thereby increased size of the controller. (cough) ;)
Haha, indeed! But if we use puzzle pieces instead?...

Quote from: memo on June 21, 2013, 11:08:21 PM
Regarding the suggestion of using network models for the wires, this could work, but it would be difficult to achieve the same degree of detail like the zigzagging wires.
I can't see why. Can you elaborate? Even if eggman used the BAT (Gmax or 3DSmax) to make these, it is still possible to make a 1-Z/R model out of it, if you select the front and back views of the closest zoom and combine them to get a 1-Z/R model, for all zooms and rotations - we may only need to reconsider the LODshell. And just consider the far fewer T21s this implementation will require.

Tarkus

#101
Quote from: cogeo on June 22, 2013, 09:19:22 AM
Sure, the texture work is considerable, to say the least. But I don't think anyone asked YOU to make all these. And while nobody seems to be interested "at this point", some may be suddenly appear in the near (or mid) future. What we could do now is only reserve the IDs (and assign them to modders, if they are interested).

Does that mean you're interested in doing it? ;)

On the IID assignment front, if it's someone who's not already on the NAM Team, we usually don't hand over an IID range right away.  IIDs are assigned based on the type and scope of project.  We like to see a proof of concept, proof of ability of the modder (to make sure we're not throwing IIDs to the wind), and have a decent idea of what the project entails and how it fits in with everything else, before we assign anything.

Quote from: cogeo on June 22, 2013, 09:19:22 AM
And I will repeat my proposal about puzzle pieces, which require no RULs and are quite simpler to make (actually as soon as the first set is made, the next ones will be mostly copy and in-place replacement. Some modders regard puzzle pieces as "obsolete", considering the few extra clicks required to plop them, not taking into account their simplicity and efficiency (and "economy" in resources and ID-range requirements). We can even make some 2-, 3- or 4-tile long straight sections for those who are easily bored. It would be nice to have ALL the above (and addtional) track types in the same city at the same time.

Quote from: memo on June 21, 2013, 11:08:21 PM
Not to mention the considerably longer start-up times due to the thereby increased size of the controller. (cough) ;)
Haha, indeed! But if we use puzzle pieces instead?...

I don't think you'll find many who agree with the idea that puzzle pieces are obsolete--I don't think they are obsolete, for one--though they're not the solution to every problem, and they're not the sole means of moving the game's networking options forward, like they were pre-2007.  They're just one part of a tool kit, that also includes various draggable and hybrid ("flex") techniques.  Their most effective use is for smaller, specialized network items, where override-based approaches aren't particularly feasible.  This was the idea behind the TuLEPs system.  Puzzle pieces can be very simple to make, certainly, and they do allow for a much finer granularity of control when it comes to smaller pieces, but that approach leaves all the decisions about network assembly to the end user, whereby they have to assemble things piece-by-piece.  For things that are likely to be the domain of a smaller set of users, with an intense focus on a particular network concept, and where there's minimal need for crosslinkage, puzzle pieces make sense.  But as soon as you're wanting to add diagonal intersections and interface with other NAM components, the required number of pieces skyrockets, running the risk of tedium for both the modder and the end user. 

The simple fact is that no matter where you add content, it's going to add up to lines of some sort of RUL code in the NAM Controller.  If I were to completely convert the RealHighway system to puzzle pieces, and remove the draggable code, all I'd be doing is shifting a massive hunk of functionality from one RUL to another.  We'd still be discussing hundreds of thousands to millions of lines of code--it'd just be in RUL0 instead of RUL2.  I don't know the exact math of how many puzzle pieces it would take to cover everything that's available through the draggable system--at least 10,000 would be a safe bet--but suffice to say, it'd likely end up being a wash with respect to load time and memory consumption.

Quote from: cogeo on June 22, 2013, 09:19:22 AM
And don't get me wrong, most people will actually still want to use the original rail textures, for a variety of reasons, among others the existence of so many stations and other rail-related lots (eg yards) using the original textures (or similar texture packs like NCD's); many of them even have even the original track texture modelled into the station's model. That is, many players will actually opt to rather stick with the original ones, if they are forced to choose. The only way to make them use the new ones, is let them keep the originals as well.

The RRW in many ways is like the Project Symphony effort.  Thus, by virtue of that, it makes the most sense as an "all-or-nothing" conversion.

-Alex

Indiana Joe

^ In summary, while it would be delightfully wonderful to have a SAM-like setup for everything, it would be a pain in the butt, so no.  :thumbsup:

In the meantime, I think we need moar updates...how goes it, Willy and Eggman?

memo

Quote from: cogeo on June 22, 2013, 09:19:22 AM
Quote from: memo on June 21, 2013, 11:08:21 PM
Regarding the suggestion of using network models for the wires, this could work, but it would be difficult to achieve the same degree of detail like the zigzagging wires.
I can't see why. Can you elaborate? Even if eggman used the BAT (Gmax or 3DSmax) to make these, it is still possible to make a 1-Z/R model out of it, if you select the front and back views of the closest zoom and combine them to get a 1-Z/R model, for all zooms and rotations - we may only need to reconsider the LODshell. And just consider the far fewer T21s this implementation will require.

I was referring to the fact that adjacent straight tiles would be different. In fact, there would be four different rotatory tiles/models. These would have to have different IIDs, which is why it would be difficult to implement this via INRULs/Overrides. Though, I had not realized you were talking about puzzle pieces. It would then be quite possible to have four different straight tiles (e.g. combined in a 4x1 puzzle piece), but then you would also need four different railXroad crossings, for instance, like you will need four different copies of any other intersection. Just because of the overhead wires. Thus, T21s are far more suitable for this, if you asked me.

Quote from: cogeo on June 22, 2013, 09:19:22 AM
Some modders regard puzzle pieces as "obsolete", considering the few extra clicks required to plop them, not taking into account their simplicity and efficiency (and "economy" in resources and ID-range requirements).

Maybe, puzzle pieces are simpler, but I disagree in terms of efficiency, at least not in terms of ID-range requirements. If you are talking about 10, 15 or maybe 20 puzzle pieces, then yes, the ID-range requirements will be minimal and the implementation and usuage will be simple. But then, if you were to implement the same functionality by draggable means, it would be just as simple and would require even less IDs. The reason for the large amount of IDs for draggable networks is the tons of crosslinkages, you would not even think about when implementing puzzle pieces. ID restrictions of puzzle pieces would soon turn obstructive.

Also consider the following ID-problem of puzzle pieces: If you have a puzzle piece like [this one], you would need a 4x4-block of IDs for a puzzle piece, whereas - if it were implemented by draggable means - it would require only 3 IDs because you could rotate and mirror the tiles in order to re-use identical tiles where possible.

eggman121

I agree with both Memo and Tarkus on this matter. A SAM setup would also have electrified trains running on un-electrified track  ()what() and the extra RUL2 code would burden and already overburdened system. There is also a slight gauge change if the texture that Swordmaster sent me are anything to go by.

The only solution I think is possible is to use the monorail/HSRP/BTM as an electric only network and maybe use the EL-Rail for both networks or using the monorail network to trigger paths on the rail network for both electric and non-electric networks if you know what I mean. But that I believe would only add more RUL code to an already overloaded system and or would sacrifice one or both of the El-rail or monorail networks for a single purpose. I agree wholeheartedly with Tarkus on this matter. it's an all or nothing conversion like project symphony that replaced the MHW and the electrification is the same. You either use it or you don't. I'm just thinking out loud here.

But I am interested in the model Idea for the slopes of the rail however if true 3d models can be t21ed onto a network or if they can be spaced out with models reoccurring every 4th tile on a diagonal run. crossing with other networks can be still t21ed normally thought since they are all flat so they can use the normal gmax rendered models.

I am getting closer to a solution on t21ing the diagonals however with the images that memo showed me. I would also like to remind people that the concept of electrified rail is still a prototype and much work needs to be done before I decide to make a real mod out of this. Once I figure out how to get the diagonals to work I can move on from there.

On that matter I think that using true 3d models may necessitate the mod becoming a NAM project since it would need an exemplar range to create the s3d props. I know a fair bit about replacing textures, fixing textures, t21ing and creating models but there is a lot I have to learn. I am more than happy to work with the NAM team on electrifying the rail network since there is a lot of interest in it from the posts I have read but that's up to higher powers.

-eggman121

memo

Quote from: eggman121 on June 23, 2013, 01:34:58 AM
But I am interested in the model Idea for the slopes of the rail however if true 3d models can be t21ed onto a network or if they can be spaced out with models reoccurring every 4th tile on a diagonal run. crossing with other networks can be still t21ed normally thought since they are all flat so they can use the normal gmax rendered models.

Unfortunately, it does not work that way. True 3d models cannot be T21ed onto the network, as far as I know, but only props can. Or rather: if you T21 true 3d models, they will behave the same as props, i.e. they become shorter on slopes.

The network's models themselves can(/must) be true 3d, like the monorail network, for example. However, what I tried to explain in my previous post, is that you cannot alternate 4 different tiles because the game cannot distinguish between them. You could at most distinguish between two different diagonal tiles, but only one orthogonal tile. It has to do with how the INRULs work.

Quote from: cogeo on June 22, 2013, 09:19:22 AM
Even if eggman used the BAT (Gmax or 3DSmax) to make these, it is still possible to make a 1-Z/R model out of it, if you select the front and back views of the closest zoom and combine them to get a 1-Z/R model, for all zooms and rotations - we may only need to reconsider the LODshell.

Also, I forgot to mention in my previous post that I don't see how your method of converting a 20-Z/R model into a 1-Z/R model could possibly work. For the 20-Z/R model, the BAT is projected onto a box, which means losing the 3d-data. If you try to put it into a 1-Z/R model, the perspective will be absolutely distorted.

Swordmaster

Quote from: Tarkus on June 22, 2013, 06:24:00 PMThe RRW in many ways is like the Project Symphony effort.  Thus, by virtue of that, it makes the most sense as an "all-or-nothing" conversion.

Technically that is correct, but there's a difference in their reason of existence. The primary aim for PS is to allow MHW and RHW to be compatible, and therefore, PS can be classified as a largely aesthetic mod, with a number of functional additions to make it work. The RRW, on the other hand, will mostly concern functional expansion of the rail network, while it happens to have a different texture. This is a subtle difference that is hardly noticeable at this point, but that I think will become clearer later on as the scope of this mod gets more shape.

There's a side-effect of this, namely that re-texture mods (or even full-blown SAM-like overrides) for the RRW are not a feckless idea. The RRW's goal is to implement additional functionality, and users should be allowed to have the texture of their dreams go with it. However, any such texture obviously needs to have the same technical specs as the current one, and this explicitly excludes the Maxis texture. In this regard, it is like Alex said a "take it or leave it" mod, where you have to choose either the new functionality or the old Maxis style textures. But the creation of additional texture sets is not my job, at any rate.

As for compatibility, this will in large part depend on the creators of custom content. Simple stations like marrast's pose no problem. These are a majority.




If you have created your own textures to go with your lots, then either you give me permission to create replacement textures or you update them yourself. If you have models with baked-in textures, you'll have to export a new BAT with new textures, or preferably without any textures baked in at all. Any other outcome will leave users standing in the cold.

But most of all, this is a forward-looking mod. I'm not gonna sit with my head in my hands because I feel tied by ten years worth of subdued rail modding. Large efforts have been undertaken to create realistic road networks, flora, terrain, BATs and so forth, so unless we concede that the realism-oriented SC4 player eschews rails, we have to go through a bit of trouble to improve the situation on this front. It will mostly be up to the rest of the community to either embrace this or reject it. I'm only playing my part as a transit modder.


Cheers
Willy

Meastro444

What is this new functionality you are talking about?
Friend of the Certified Drama Queen :)

Swordmaster

This happy family of draggable switches, for instance.




Sidenote: if you're not following memo's explanation of IID conservation above, they consist of only 13 different tiles.




Puzzle pieces for this would require every such variant setup to occupy a new string of IIDs.


Cheers
Willy

MandelSoft

Nice work on the switches, Willy...

But what makes me twitch is which switch is which? :D
Lurk mode: ACTIVE

Simcoug

 
Quote from: Swordmaster
This happy family of draggable switches, for instance.

:party:
good stuff!

Girafe

I have few questions regarding the re-texturing

I have a Vnaoned's project in the hands:



I would be glad to use the future textures and here comes my questions. I imagine that the mod will not overwrite LE texture (which is an overlay 0x03031500). So will the texture be available under LE and a polemic question when?

Same thing regarding the wires and the poles. It could be good to export them into a propspack for LOTters.

Anyway good stuffs.
The Floraler

This is the end, hold your breath and count to ten, feel the earth move, and then...

*   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *    *   *   *   *   *    * 

noahclem

So many beautiful things since I was here last  :o  Fantastic work to say the least Willy  :thumbsup:

Great work on the catenaries as well eggman121  &apls

Wiimeiser

Again I'll mention Peg's three path systems and their respective crossings. Oh, and Simgoober's Canal bridge, but that's pretty useless.
Pink horse, pink horse, she rides across the nation...

jdenm8

#114
Quote from: Wiimeiser on June 23, 2013, 05:25:24 PM
Again I'll mention Peg's three path systems and their respective crossings.

PEG or someone at SimPeg with permission to modify Peg's content will have to do them. He has a strict no-modification policy and has put it on basically every page of his website (Or at least the PLEX).

Quote from: Girafe on June 23, 2013, 02:16:46 PM
I imagine that the mod will not overwrite LE texture (which is an overlay 0x03031500).

I imagine that the standard lot textures will be overridden. That would probably include the most used base and overlay textures. If it uses SC4's built-in overlay (If it has one, I don't know), I imagine it'll be compatible.
It's things like Island platform stations I'd be more worried about since they can use one of multiple Island Platform rail textures, none of which are from SC4 itself.


"We're making SimCity, not some dopey casual game." -Ocean Quigley

whatevermind

Quote from: Swordmaster on June 23, 2013, 08:43:31 AM
But most of all, this is a forward-looking mod. I'm not gonna sit with my head in my hands because I feel tied by ten years worth of subdued rail modding. Large efforts have been undertaken to create realistic road networks, flora, terrain, BATs and so forth, so unless we concede that the realism-oriented SC4 player eschews rails, we have to go through a bit of trouble to improve the situation on this front. It will mostly be up to the rest of the community to either embrace this or reject it.

Bravo! And I would encourage the RRW team to continue along this idea in their developments. This certainly isn't the first time that a major project has sought to redefine, and dare I say, elevate the standards to which some particular group of custom content is created. By the nature of this type of project, there will always necessarily be some older releases that simply get left behind. But I think history has shown that the community will step up to fill in the gaps, whether by updating older releases, or creating new ones that fit into the RRW scheme.

That said, I'm thrilled to see this project has found new life, and I'll definitely be watching to see what comes out of this.


Gugu3


Meastro444

I take it those single tracks are bidirectional?
Friend of the Certified Drama Queen :)

rooker1

Quote from: Swordmaster on June 23, 2013, 10:59:21 AM

That's a beautiful pic.....made my Monday morning all that much better.
Great work Willy!!

Robin
Call me Robin, please.

Swordmaster

Thanks for the continued support everyone.


Quote from: Girafe on June 23, 2013, 02:16:46 PMI would be glad to use the future textures and here comes my questions. I imagine that the mod will not overwrite LE texture (which is an overlay 0x03031500). So will the texture be available under LE and a polemic question when?

The default orthogonal DTR texture is 0x263d2000 in the lot editor. If you use that one on the lot, it'll get overwritten with a RRW installation. Like JD said, the mod will include the default lot textures as the marrast station pictured above shows.


Quote from: Meastro444 on June 24, 2013, 04:27:57 AMI take it those single tracks are bidirectional?

There's nothing new about the single tracks here, so yes, they will be bidirectional like the originals.


Cheers
Willy