[jondor]

The plan is for the next release to contain at least all five L0-L4 90 deg MIS FLEXFly/Curves.  The models are mostly done, the L0 RULs just need a little more work before I can port them to the other four heights, and they will be as stable and complete as the rest of P57.

I also developed a well ordered IID scheme for them that with just a little tweaking can also be applied to the 45 degree curves, making RUL migration for them (almost) a copy-paste-find-replace job.

I'm sort of bouncing between three separate, but related, P57 sub-projects which complicates development a bit, but they're all necessary to make the whole project mesh together nicely.

[RickD]

I am curious to know wether or not the new NAM will resolve this issue:



Thanks. 

[GDO29Anagram]

I am curious to know wether or not the new NAM will resolve this issue:

It helps to point it out so we know what to fix.

It appears to be a mix of RHW and NWM and GLR, but these crossings fall under RHW according to P57 specs, so it's mainly RHW crossing adjacency RULs, or the lack of it...

In the meantime, you think you can spare an extra tile of space?

[epicblunder]

The plan is for the next release to contain at least all five L0-L4 90 deg MIS FLEXFly/Curves.  The models are mostly done, the L0 RULs just need a little more work before I can port them to the other four heights, and they will be as stable and complete as the rest of P57.

That will be incredibly useful.  Will it be possible to have a higher flex-fly crossing over a lower one? or is that unstable/impossible?

[GDO29Anagram]

That will be incredibly useful.  Will it be possible to have a higher flex-fly crossing over a lower one? or is that unstable/impossible?

I asked the same exact thing long before I got involved with the NAM Team... Turns out, you just need even more complex RUL-2 code... But how do we organise it, let alone execute it?

[Tarkus]

Just an FYI, I am at present "refactoring" the P57 RHW RUL2 code, which has slowed forward progress on my end for the moment.  But in the long run, it'll improve ease of maintenance with the code, which had gotten a bit . . . interesting . . . with RHW-over-RHW stability situations. 

-Alex

[jondor]

That will be incredibly useful.  Will it be possible to have a higher flex-fly crossing over a lower one? or is that unstable/impossible?

I asked the same exact thing long before I got involved with the NAM Team... Turns out, you just need even more complex RUL-2 code... But how do we organise it, let alone execute it?

I've organized it in my head.  Execution remains a small sticking point, but I think it can be done.  In the meantime, I've got another P57 sub-project going.  FLEXFly over FLEXFly may or may not be in NAM 31, it depends on how much other work I can get done and how quickly.

[Jayster]

Okay, so I've got a few questions about the design aspect of the elevated RHW pieces. The program I use is Rhino 4 because that is what I learned to use in high school. Very easy program to use that focuses on modeling with NURBS.

1. When imported, they are mesh objects. Why is this and is there anyway I can convert them to a NURBS object to make editing them easier? (There is a program that I can buy called Mesh To Solid but I'm not too keen on buying it...)

2. Textures? The model, when imported into Rhino doesn't have any textures when I render the scene. It doesn't have any textures in 3ds Max either. Where can I locate the textures for the elevated RHW pieces?

3. I'm currently working on a 45 degree transition piece from L0 to L2 for RHW4. Where can I find the piece for the 45 degree curve piece to place on the "floor" of the scene to model the transition from looking down on it so I get the right curve?

Hopefully someone can help me because it was really cool to get a piece into Rhino and just see the inner workings. Not to mention the WOW factor at how large the RHW4.dat was in general! Thanks for the help!

Jayster

[jondor]

To answer your questions:

1. In both the S3D format native to SC4 and the 3DS format that we use as a go-between, the models are stored as meshes.  Even if you were to convert the models into NURBS, you'd have to turn them back into meshes to get them into the game.

2. The textures are not exported as part of the model, only the vertices and triangles are.  In order to get the textures to show up in any modelling program, you'll have to extract them and save them in a readable format (such as PNG).

3. The RHW-4 curve actually comes in two flavors, a shorter inner curve and a longer outer curve.  The full preview model for the shorter curve should be at 0x5E14D005 (or at least near there) and the longer at 0x5E14C005.  Also keep in mind that you'll have to split the full model into the 16mx16m chunks that SC4 expects in order to get it into the game. (Unless you use some funky advanced modding techniques).

[Jayster]

To answer your questions:

1. In both the S3D format native to SC4 and the 3DS format that we use as a go-between, the models are stored as meshes.  Even if you were to convert the models into NURBS, you'd have to turn them back into meshes to get them into the game.

Don't mind at all about converting them back to meshes. Rhino offers that feature straight in the program. I also know that they have to be rotated 90 degrees when they are exported back into the game.

2. The textures are not exported as part of the model, only the vertices and triangles are.  In order to get the textures to show up in any modelling program, you'll have to extract them and save them in a readable format (such as PNG).

In what dat can I find the textures?

3. The RHW-4 curve actually comes in two flavors, a shorter inner curve and a longer outer curve.  The full preview model for the shorter curve should be at 0x5E14D005 (or at least near there) and the longer at 0x5E14C005.  Also keep in mind that you'll have to split the full model into the 16mx16m chunks that SC4 expects in order to get it into the game. (Unless you use some funky advanced modding techniques).

Perfect! Exactly what I was looking for! And no worries, it'll be easier to cut up the model into 16m x 16m chunks. A little difficult to explain how it is done but it isn't difficult at all.

Thanks for the help so far jondor! Hopefully somebody else can shed some light onto how to convert it to a solid. If worse comes to worse, I can always just re-draw the elevated piece I'm using as a NURBS object instead.

Jayster

[epicblunder]

That will be incredibly useful.  Will it be possible to have a higher flex-fly crossing over a lower one? or is that unstable/impossible?

I asked the same exact thing long before I got involved with the NAM Team... Turns out, you just need even more complex RUL-2 code... But how do we organise it, let alone execute it?

I've organized it in my head.  Execution remains a small sticking point, but I think it can be done.  In the meantime, I've got another P57 sub-project going.  FLEXFly over FLEXFly may or may not be in NAM 31, it depends on how much other work I can get done and how quickly.

Wow.  With how finicky the FLEXFly pieces are I was expecting the answer to be a straight up 'NO' (and i have no idea what the whole RUL code thing is, i've never made transit lots).  Even if that doesn't turn out to be possible after all, all the new toys you guys are making for us look great.  And all those different level FLEXFly's..... /drool.

Keep up the phenominal work folks.   

[Twyla]

Apologies if this has been asked before (no search query I could think of found anything) but...

Is pathing strictly relegated to the tile in question or can it overhang the way models/textures can?

[jdenm8]

They can, but it only works when perpendicular to the direction of travel.

To simplify it a bit, when a path enters on the Eastern side and exits on the Western side we can move the path further than 8m on either side (North or South). However, we cannot move it further than 8m away from the centre on the East or West sides.

At least, that's my understanding of it.

Also, as far as I'm aware, this does not work with Pedestrian paths, they will snap to the edges of the tile in-game.

[GDO29Anagram]

A little insight on how things work with the FlexFlys: At the core is the Controller, consisting of RUL-0, 1, and 2. RUL-0 is used to actually place it down, RUL-1 is used for the anchor tiles as well as drawing perpendicular through it, and RUL-2 is used to initiate the network overrides for dragging RHW-2 into the anchor tiles so that it converts to MIS (or elevated MIS), initiating the overrides that convert the other five tiles into a flyover, initiating the same override when something crosses those five tiles, and carrying over the network override wherever it crosses.

End result: Overridable puzzle piece. The bulk of it is all RUL-2, and with enough of it, you can override a FlexFly with another. Never underestimate the power of RUL-2; It's what holds most of the NAM together.

And for paths, they can overhang. I tried it once but I have found that they don't work great with cars entering or exiting outside the original boundaries... Look at the diag end stubs for, say, TLA-3 and the blue paths actually jet out of the boundary lines.

Let me guess: You had a curiosity with the 6S diagonal.

[jondor]

@Jayster  You'll find the FSH files in the same RHW-4 dat file.  I don't recall if those curves use the old separate flat-plane textures or if it was updated to a MORPH model. (Basically a triangle strip UV mapped onto the ortho texture).

[jdenm8]

@jondor, Jayster, they're flat pane because of the different diagonal width. The MORPH versions will be in NAM31.

[MandelSoft]

@Jayster: I could deliver the MORPH versions if you want to...

[Twyla]

Let me guess: You had a curiosity with the 6S diagonal.

Actually, I was curious about a possible approach to more complex flyovers.

Still toying with models and such, but here's the general premise:

*  0|1|2|3|4|
0 |O|O|-|-|-|
1 |O|O|O|-|-|
2 |-|O|M|P|P|
3 |-|-|P|P|P|
4 |-|-|P|P|-|
M = Main 'Anchor' of the 5x5 Ramp
O = Overhanging Pieces
P = 'Normal' Pieces

The basic design would enable users to construct the flyover portion of 4-level stack interchanges with only two components - one being the mirror of the other.  Fully constructed, the interchange would be mirrored along both 0-axise - 10x10 tiles in total size, bisected both ways with a 'clear' path 4 tiles wide (for the placement of RHWs).

The 'actual' component would only occupy the area from 2.2 to 4.4 - the flyover ramps themselves would be overhanging models (which I've seen done plenty of times, so that's no problem).  The question is:  Could the pathing information for the overhanging pieces be contained as part of the 'Main Anchor'? 

If so, it would mean that the overhanging flyovers would permit normal traffic without any regard for whatever happens to be running beneath them.

[jondor]

Unfortunately, that's not possible.  Even with slightly overhanging paths, the simulator needs a tile-by-tile path to follow.  It won't try to jump diagonally corner to corner without passing through one of the adjacent tiles, much less skip over several tiles that for all intents and purposes are a black hole to the tile in question.

Models can overhang because to the simulator, they don't exist.  They're purely visual.  Give a model a 500 meter offset and the game will happily go draw it, but it means nothing to the simulation engine.

[Blue Lightning]

In addition, with some experimentation I did a long time ago, two 45 degree curves would work a lot better than one 5x5 curve, mainly because with the 45 degree curves, you can have any two widths crossing each other without the need for new pieces (and therefore, saving hundreds of thousands lines of code).  Need to build a stack with a 10 tile wide collector/express setup? Done. Although we are considering making the RHW-4 90 degree curve 5x5, since 4x4 is far too sharp.

4x4 90 degree pieces can form T stacks with any width though, due to the nature of such interchanges.