NAM: Development

[Shadow Assassin 336]

Oh yay, you guys have finally got around it. I thought it was in the EXE, but aren't you going to run out of numbers sooner or later?

[Karybdis 34]

Well I'm not even sure if what I said DOES work. I just know that's the impression we had when decoding the original RH rulesset.

Even if it does, that still limits network possibilities. Visually you could change the roads, highways, etc to LOOK like certain things under various circumstances, but they will still be roads and highways. In other words, no new unique network types. Period. Everything will always have to use one of the known pathing types (car,pedestrian,elrail, etc). This is just yet another creative workaround to not allowing new networks visually at all that allows pushing the boundries of the game well beyond the expected.

[smoncrie 43]

I see a lot of Trixie winners here.  Congratulations everyone!  qurlix, you certainly deserve your new title.

It seems that a number of people would like cobble stone streets.  I am willing to change the dirt road puzzle piece, etc. to use cobble stones, but I will need textures.

Would someone volunteer to produce cobble stone textures? Since I will be limiting the scope of this at first, I will only need straight and 90 degree turn textures.  I would also prefer that the textures are the same width as the ordinary streets.

thatmonkeysim,  a have made, but not yet released a GLR neighbour connection puzzle piece, but drag able GLR will probability be able to do neighbour connections as well.

qurlix, currently, I am considering not using any end stub in GLR.  I think it would simplify the RUL

[Karybdis 34]

I think that's always the main concern really, the game takes a lot longer to do things the more rules it has to sort through, not to mention that even navigating them becomes horrible...

smon: actually the diagonal streets were a much simpler problem

 

The rules allowed it just fine, but try DRAGGING streets at 45 degree angles. Maxis actually told us that it was totally possible, then looked at the code and went DOH! and emailed us back again saying sorry. Nobody had known that overrides were possible originally so we gave up for about a year *Sweatdrop*

 

Other than that, we should be able to use whatever rule codes we want.

Technically speaking, the only truely coded ones are up to 13, but you can see if you look at the rush hour rules for some of the more complicated stuff that they start creating new rule edge IDs like they're giving out presents. Either there's a ton of codes that t7t and I never had fully recorded, or there's just an arbitrary ID allowance built into the exe. We might want to try it though if we have any time. Could alleviate all the starter problems entirely.

[Buggi 684]

*hugs rob*

Great job sticking to it man! Great job.

[Karybdis 34]

Heh. Dont congradulate me nick, thank these guys. They're the ones doing the work I'm just trying to get back into it again finally as much as I can.

[Buggi 684]

Yeah, I don't know if tropod can handle any more awards, imagine the weight!

 

I would like to see another official NAM release though, were were getting them monthly for awhile.

 

Oh, Rob, btw, I got to have lunch with Chris Taylor a few weeks ago. If you don't know that name he created Total Annihilation a few years ago and has since founded Gas Powered Games and is now working on Supreme Commander. He bought me lunch. ^.^

 

-Buggi

[xannepan 513]

Wow so many nice things happening here.

 

I made some cobblestone textures long time ago and poster them in one of the threads. Unfortunately, I had a HD crash in the mean time, and I forgot to create a back-up of the textures. I cannot find back the thread anymore. Hpefully, the textures are here somewhere. IF so, than you are fre to use them. BTW I think Tropod has the textures since he used one of the textures for one of his puzzlepieces

Xannepan

[ardecila 124]

xannepan: The textures are on the first page of this thread.

[topcliff 1]

this isn't  a request(at least, i don't think it is), but have you noticed on xannepan's wonderful Gare du Nord station those road textures? what if we were able to implement them with the other NEW draggable networks(which btw are AWESOME) for four laned roads? yes, there would be very little sidewalk, not to mention the creation of more textures, like intersections and diagonals and others, but it would mean we could create realistic small avenues that you see in lots of cities(like Sacramento. here, with 16 meters, you can fit three whole homes on one lot, IF it were sc4 standards) it would be a great breakthrough in the game. let's see what the other almost 100,000 members of the community have to say...

[Karybdis 34]

I imagine those could be done sure. its just a matter of getting lots of textures and if its a popular enough idea to get done ahead of other stuff.

If I'm not too busy, given the textures I might try myself if the others are too busy.

[jeronij 13]

Hello to all,

 

Not sure if I got it right, but I guess you are talking about making new dragable transit networks. You say you need textures to start with, so I propose you to start using the dirty street mod textures (my version includes some more intersection and tiles as the original Trolca

[prince_of_sims 0]

i second that idea. jeronij's dirt roads mod is pretty much complete in regards to textures. that might be a good idea to start off with on these draggable networks.

[Buggi 684]

Draggable opens so many possibilities... I'm so anxious to start seeing downloads...

Just to ask, is it then possible to make draggable Canals? Draggable shoreline supports? Draggable streams and irrigation channels?

 

How about something that I've yet to see... new dragable power lines? How about something odd like draggable Alaskan Oil Pipelines?

 

Dragable El-over-road? (w00t)

 

[davejowsey 1]

hi guys i just thought i'd offer my services. I'm currently working as a Transport Planner so feel i could add useful input on the actual design aspects of some junctions. Although i do not have any modding experience i thought i could still have some use. I'll try and check back in this thread but i have real memory problem when it comes to which threads i've posted in. So if you need any feedback on designs probably easiest to drop me a PM.

[cowkilla 12]

all of this work is wonderful!
cant wait for those highway interchanges and rail over road intersections.

if anyone needs some modeling done I am currently employed as a modeler but i dont really know anything about bating i would like to get involved!

anyhow, nice work people keep it going!

[Shadow Assassin 336]

Ardecila: How is that orth-diag trumpet interchange coming? We're eagerly waiting for it.

Last I heard, it's been modeled and split up, but not put together in the NAM.

[the7trumpets 10]

Date: 12/14/2005 3:20:34 PM
Author: smoncrie

Inspired by the Rural Highway project, I have found a new way to do GLR tracks.

A disadvantage of doing it this way is that the GLR tracks cost the same to build as elevated rail tracks. Another problem is that current GLR stations do not work on the new tracks.

I tried doing the same thing in reverse for road to viaducts, but if it is possible, it is harder.

quote>

Okay, I finally found your post and it makes more sense to me now

One thought:

Doing this might make it difficult to do intersections of elrail-elrail, glr-glr, and elrail-glr. You might have to choose one for normal operation (probably elrail-elrail) and use puzzle pieces for the rest. I still have to do some thinking about this though.

In the mean time, I am trolling around simtropolis a bit more so if you have some ideas or questions on RULs that you want to bounce off me, just let me know. Since I've switched over to Mac though, my actual modding ability is severely limited


Great advances on the bridges though, I was always scared by the bridge ini files

[GoaSkin 2]

May it also be possible to realize GLR bridges this way?

For example that the game uses other bridges if you start to draw a el-rail bridge over water starting on a GLR tile .

[qurlix 20]

t7t: All of the orthogonal el-glr intersections have been successfully automatized. Diagonal, that's another story. I'm not sure how much smoncrie has worked on the draggables recently, but we layed out an official system a while back. I've revised it several times since then, to accomodate for turns and intersections. The easiest way to describe it would be bouncing marker tiles back and forth. Yeah, that probably wasn't real clear. I'll send you a copy of the specs when I get a free minute.

GoaSkin: Well, detecting that is impossible. I'm 99% sure. But there probably will be a GLR bridge in the next NAM that you hand-pick off the el-rail bridge menu.

Buggi: Theoretically, those are all possible. But each one of these systems requires tons of work, not to mention the chances are nil that non-transport stuff gets into the NAM. Oil pipelines and canals sure would be fun, though.

-qurlix

[the7trumpets 10]

Date: 1/21/2006 11:08:10 AM
Author: qurlix
t7t: All of the orthogonal el-glr intersections have been successfully automatized. Diagonal, that's another story. I'm not sure how much smoncrie has worked on the draggables recently, but we layed out an official system a while back. I've revised it several times since then, to accomodate for turns and intersections. The easiest way to describe it would be bouncing marker tiles back and forth. Yeah, that probably wasn't real clear. I'll send you a copy of the specs when I get a free minute.

-qurlix

quote>

I'll be awaiting it, sounds like fun light reading

I was more concerned with how el-el intersections would be differentiated from el-glr intersections if you use the el network tool to draw glr instead of using puzzle pieces. It would be doable with overrides, but because there are no wildcards in the overrides (ggrrrr!!!!!) it makes it quite a bit of extra override coding, which can actually effect game performance when drawing. I ran into this when using overrides to do most of the turning lanes RUL codes (think 200 extra lines of recursive RUL codes), which resulted in a 2-6 second freeze when releasing the mouse button while drawing an avenue.

But alas, I will await the 'light reading'. In any case, I'm very impressed with what has been accomplished. I just hope I don't slow you guys down

[smoncrie 43]

I confess that I have not done much work on this since Christmas, but I have tried Karybdis

[ardecila 124]

Shadow_Asassin: Well, it would be a very big job to go from what I have now to a fully-functional interchange. I did find a way to go from gmax->S3D without using the BAT render or any skinning. Unfortunately, I have no batch way to do it, so I have to do it one tile at a time.

*shrugs* Still beats the hell out of the old way of doing these things.

Once I learn how to write gmax plugins, then I'll try making a batch plugin.

[the7trumpets 10]

smoncrie:

I have to appologize if I have confused everyone more, so I'll give a breif synopsis of the relevant information that I've heard from Kevin back in the bugfix era or tested on my own. Then I'll provide some thoughts which should be ignored if my understanding of your methodology is incorrect.

How does network dragging work?

The process is a fairly straightforward, but can become confusing if it's not kept in context. When a draw is initiated, RUL data of the appropriate flags is entered into the tiles you are drawing. For instance, if you use the road tool to draw a five segment orthagonal road, road RULes symilar to the following are added on their respective tiles:

02000000, 02000200, 02000200, 02000200, 00000200.

Once those RULes are entered into memory, the fun begins. The game has to decide which transit tiles to display (and build when you let go of the mouse button). For each tile which contains RUL data (is a transit tile) within 2 tiles of the current network draw, the following flow is initiated to find the right transit tile IID and flip/rotation value. I should add that it may extend to 3 tiles from the network draw, but I'm pretty sure it's 2, I just haven't checked in a long time

Case: tile contains network data for only one network
1. Look in the first 'simple RUL' file for the applicable network, these are the RUL files with low IIDs
2. Look in the second 'simple RUL' file for the applicable network.
3. Check the complex interchange RUL file (the one with the checktype and rotation ring lines) and search for a solution. Only use a found solution if it's the only one found, or autopromt is enabled (in which case a prompt is displayed).
4. Look in the Overrides RUL file for a line which contains the IID of the tile it has decided to use in the first pair in the declaration. When it finds an applicable line, it checks that line against all 4 bordering tiles. If a match is found, it replaces it with the second pair of tiles, and then looks in the overrides RUL again for each one of those new tiles. This continues until no applicable overrides are found.

If there is no solution found after step 3 for any tile, it results in a red draw. In EVERY step a solution does not kick it out of search mode, but it continues to go through the whole file, using the last found solution. This can sometimes be used to our advantage, especially in the Overrides file.

Case: tile contains network data for two networks
1. Look in the simple intersection RUL file and search for a solution.
2. Check the complex interchange RUL file and search for a solution. Only use a found solution if it's the only one found, or autopromt is enabled, and then display a prompt.
3. Look in the Overrides RUL, same process as the single network tiles.

Likewise, if no solution is found after step 2 for any two-network tile, a red draw results.

Concerning 'custom' RUL codes, I really don't get exactly why karybdis was suggesting them since you can't really draw custom RUL codes. My understanding is that the network drawing exe code creates the RUL codes, which the engine then tries to find a matching tile. It is surprising that using the intersection ordering RUL like you did didn't work though, since you weren't really drawing anything.

My guess is that the orientation you were trying to plop it in was a flip/rotate that you didn't put into the rail RUL file. The hard way is to manually create all 8 possible flip/rotations in the rail RUL file. The easy way is to copy all the rail RULes into the first file and then put a #Transmogrify header in the second file, with one declaration. For some reason, the game seems to want to use flipped tiles when un-flipped will work...but I never tracked down why, I just gave up and put in all the flips and rotations when it became a problem.

-------------------------------

Now, here is my current understanding of your ideas for dragable GLR. If I'm wrong or confused, please correct me and give me a little one of these:


I think you're using a custom interchange piece defined in the interchange RUL (glr to el ramp) which is then checked in the overrides RUL to see if the glr side is connected to an el network piece. If it is, the override RUL changes it into a glr piece. From then on, if a glr piece is connected to an elrail piece, the el piece is changed to glr. In this method, the glr really is part of the elrail network (and will be reported as such in transit maps, etc) which is probably a positive thing, but it does bring up its own challenges:

It would require override RULes for every 01, 02, and 03 RUL side eltrain tile next to every respectively matching 01, 02, and 03 glr piece. Whether this would create unacceptable slowdowns, delays, or crashes when drawing simply won't be known until it's tried.

One unknown possibility is the 90 degree within one tile turn issue you have brought up previously. There is no 00000202 eltrain piece, so we would need to verify whether the eltrain drawing tool will create those RUL codes for the tiles in question. I presume the answer is yes, but I haven't tested it (maybe you have).

glr crossings of 3d networks (like ground highway) are a potential challenge since they can take place over many tiles to ramp up and down over the obstruction. The easiest way to solve this (if it works) is to put RULes in for glr crossings and then prevent the eltrain solutions if it buts up against a glr track.

Finally, although this is a step that could be put off until much later, some surveying needs to be done on whether it is intuitive for the user to build a ramp and then draw eltrain to make glr, and then buldoze the ramp if they want a glr only network. It seems wacky to me, but I suppose we don't have many options here.


Okay, I think I've succeeded in confusing myself. I have to train myself how to dream in RUL codes again...I'm still waking out of simcity hibernation

[smoncrie 43]

the7trumpets, the first part of your post was interesting and contained quite a lot of information I did not know.  I am not sure I followed the second part and I think I should describe the process used to create drag able GLR.

Imagine a sequence of elevated rail tiles forming an elevated rail track.  Now imagine that one of the tiles is converted to a GLR tile.  We can convert more elevated rail tiles into GLR tiles using an override RUL like this:

<GLR><ELrail>  => <GLR><GLR>

Where <GLR> is a GLR tile and <ELrail> is an elevated rail tile.  In other words if you have a GLR tile next to an elevated rail tile, they are replaced with two GLR tiles.

The RUL can be applied to all the tiles that you drag, and each time it is, the GLR tiles spread further until all the elevated rail tiles one side of the original GLR tile are converted to GLR (except the last tile).  If you add more elevated rail tiles by dragging from the end of the GLR tracks, they will be converted too.

 

The last tile is not converted because it is a different elevated rail tile. It can be converted by adding another override RUL.

Now the question is: How do you get the initial GLR tile?

Puzzle pieces can have a tile that you can drag to or from by using the keywords check and optional in the Intersection Ordering RUL file.  This tile can be the GLR tile needed, but it must be unique (not used for any thing else).  The test I just posted about seems to verify that such a tile cannot be unique if only one network is specified, so we must use a unique intersection (two networks). Intersection RULs (not rail RULs) must then be used to make the puzzle piece tile into the GLR tile.  Dragging elevated rail to or from this puzzle piece GLR tile puts the elevated rail tiles next to it (the GLR tile), and the override RUL can convert them as described above.

 

I have not tried it, but it should be possible create a puzzle piece that is made from one GLR tile; extra stuff such as a rail ramp is probably not necessary.

The GLR tracks that result from this process do not have unique RUL values. (In fact the rail RULs do not need ANY changes.)  Unfortunately, this means that GLR intersections can not be handled with intersection RULs because they use RUL values not IID

[the7trumpets 10]

smoncri:e Thank you very much for your explination, it's all starting to make sense now

The basic idea (using overrides to domino-effect {glr}{el} -> {glr}{glr} replacement) is what I was thought you were doing, but the added information on glr specific tiles (90 degree turn and T intersection, for instance) is very helpful.

Don't let me slow you down, but the way I see it there are two possibilities. I really don't know which would have better performance, or if both are even 100% possible, but I'll try to lay them out below to at least help myself to think through them


1. Convert {GLR}{EL} to {GLR}{GLR} with override rules.

This is the way you have described. It does require quite a bit of complex RUL override coding though. As you mentioned, the endpiece (RUL code 02000000) does not get converted with the first RUL override line. To do that, an additional override line is necessary. This theory extends to all curves, intersections within lightrail, and intersections with other networks. If the domino effect is to continue through those places, RUL overrides have to be made in the following manner:

{GLRa}{ELb} -> {GLRa}{GLRb}

Where 'a' indicates all tiles with an eastward RUL code matching the westward RUL code of 'b', and where each GLR tile 'b' is a symilar looking GLR replica of the 'b' elrail piece.

For example, the following GLR tiles would need override replacement lines with each EL piece listed. So, there would be an override line for the first GLR tile next to each one of the EL tiles listed and so on. And this list is only for the 02 connection type.

{GLR 00000200}
{GLR 02000200}
{GLR 02020200}
{GLR 02000202}
{GLR 02020202}
{GLR 00130200}
{GLR 02130200}
{GLR 00000211]
{GLR 02000211}
{GLR 00130211}
{GLR 02130211}

{EL 02000000}
{EL 02000200}
{EL 02020202}
{EL 02110000}
{EL 02110200}
{EL 02000013}
{EL 02000213}
{EL 02110013}
{EL 02110213}

11*9 = 99 RUL override lines just for the 02 connection type. And this doesn't include intersections, meaning it would be several hundred lines of code.

Using this method would also require some creative solutions for the 90 degree pieces, T, and X interchanges for GLR (as you already mentioned). Drawing up to, but not into existing glr seems plausible but confusing to the end user, and there may be instances (although I cannot think of any) where the user does NOT want that to result in a GLR intersection or curve. This method would work though.

Another solution for the 90 degree issue is to actually create eltrain pieces symilar to the 90 degree turn pieces, and then use override rules to prevent them from appearing next to any other eltrain pieces. This should ensure that they are only used as placeholders when they are about to be converted to glr (next to a glr track). There is a chance that red draws would occur because of things being prevented or overriden in the wrong order. This can be corrected by reordering the overrides RUL, but it is extremely difficult to track down these bugs.

The final solution would be to abandon the idea of 90 degree turn pieces on GLR. This is my personal favorite, but I suspect the users of GLR would balk because they have gotten used to 90 degree turns and planned thier cities accordingly. So I suppose this isn't really an option.


2. Add railRULes for glr pieces, and use overrides to prevent GLR pieces from being continued as an eltrain piece.

I think this method would be easier in the long run, but if you're more comfortable with the first method, don't let me slow you down too much. Let me explain how this would work though:

You would combine the two existing simple railRULes files into one, and then use the now empty RUL file to create simple RUL entries for all GLR tiles.

In the first method, you use the eltrain tool to draw {EL 02000200} and then using the following override:

{GLR 02000200} {EL 02000200} -> {GLR 02000200} {GLR 02000200}

In this method, there are actually two solutions to the network drawing provided in the simple railRULes files, {EL 02000200} and {GLR 02000200}. Then you use a prevent RUL to prevent EL from being built as a continuation of GLR:

{GLR 02000200} {EL 02000200} -> PREVENT (0x00000000 IID)

It would then choose the GLR piece instead of the EL piece.

To me, this seems like it has a number of advantages:

1. 90 degree problem is mostly solved.

Simply draw it the way you do normally, into or from the 02000000 piece to create a 02020000 piece. Since the GLR piece is the only tile with RULes that satisfy 02020000, GLR is drawn. Prevents would still be necessary though, to ensure that GLR 90 degree turns don't get drawn in the middle of your EL network.

2. Less likelyhood of bugs.

Since all the overrides are Prevents instead of replacements, each RUL line only has one pair of instanceIDs instead of two, which means bugs are easier to track down and less likely to occur in the first place.

3. Easier maintenance of code.

While it does require more lines of code (simple rail RULes have to be added for all GLR pieces), it is easier to add GLR pieces as textures get drawn by inserting an additional RUL entry into the simple railRULes file and then Putting in the prevents necessary in the overrides file. This method would still require a large number of RUL override lines, but they would be much easier to write and bugfix since they are prevents instead of actual replacements.

4. 3d Network Interchanges.

GLR running under an elevated highway is inherently different from eltrain ramping over an elevated highway. An oirthagonal eltrain ramp over orthagonal elhighway takes up 8 or 10 tiles, while orthagonal GLR running underneath orthagonal elhighway takes up 2. With this method, you simply enter simple RULes for glr going underneath elhighway in the simple single tile multinetwork intersections RUL (sorry, I can't remember the real name of the RUL file). Then you find the first tile in the eltrain ramp over elhighway and prevent it from drawing next to GLR, and prevent the GLR under elhighway piece from drawing next to elrail.

While it may be possible when using the first method to use overrides to convert all 8 or 10 eltrain tiles to straight glr tiles, it makes it more difficult to draw glr over/under 3d network intersections since you have to first drag GLR 10 tiles across the el highway and then buldoze most of it until you have the shape you want.

----------------------------------------------------------------

In general, the second method seems to me like the slightly longer bug slow and steady way to win the race. I may very well be overlooking some show-stopping problem with it though, so please attempt to shoot holes in it before you decide to use it

Like I said, the method you laid out will work, but it may have usability issues and a higher chance of bugs cropping up or being more difficult to solve. In the end though, since it will only be done one way we won't know how difficult the other method is, and the grass will probably seem greener on the other side of the fence so we'll wish we chose the other method...oh well.


Good luck, and thanks for having patience with me as I re-orient myself with what's goin on.

[qurlix 20]

the7trumpets/smoncrie: Ok, here are my thoughts.

If we keep system A, we definitely should make a 00020002 El-Rail piece. And maybe actually make one, along the design lines of the respective heavy rail piece, rather than a red draw.

Don't forget, if we really need to, turns, T's, and +'s could remain puzzle pieces.

(@t7t) If we are going to keep system A, we also must explain the flag bouncing routine to you (for dealing with multiple successive intersections).

As for system B, I defintely prefer using other RULS to using overrides. They can quickly become clumsy, and we are already incorporating the RHW, for which there is no override alternative, due to its one-way-ed-ness.

I can't see any problems with the prevent method, except for GLR-El intersections...I'm not quite sure how that will work out. Then again, we aren't quite sure how they'll work out the other way.

I'll need a day to think about it. The prevent system does sound a bit better. But that's just because simple and intersection RULs are easier for me to comprehend.

PS: And the multinetwork RUL is called IntersectionSolutions. Just to help ya re-orient yourself.

PPS: We also need to set out a specific way to make draggable pedmall. We could use your prevent method for this too. Then, again, because there are no tile-differences from pedmall to pedmall piece, there would be very little override code, so that may be easier.

-qurlix

[allan_kuan1992 6]

Wow, you guys really do do a lot of hard work to make the NAM happen... and I am really amazed.

Are you guys trying to make two separate networks - ELR, GLR - with a transition piece to connect them (like subways and ELR)? Or are...??? I'm really confused here. Can someone working with the GLR just tell me briefly what are you going to do to the network?

[Shadow Assassin 336]

Allen: What they are trying to do is make the GLR network draggable, and hopefully, eliminate the bug that causes the game to crash when a GLR piece is hovered over a transit enabled lot. We've already got the GLR, but it's unwieldy in its puzzle piece form. I assume we'll still be using puzzle pieces, but a lot less than what we were using initally.

[the7trumpets 10]

Date: 1/23/2006 8:07:24 PM
Author: qurlix

the7trumpets/smoncrie: (@t7t) If we are going to keep system A, we also must explain the flag bouncing routine to you (for dealing with multiple successive intersections).

quote>

Yes, this would help a lot. I have read little snippits of this so called 'flag bouncing' but I haven't seen it layed out and can't really imagine it from scratch without a few more clues

I can't see any problems with the prevent method, except for GLR-El intersections...I'm not quite sure how that will work out. Then again, we aren't quite sure how they'll work out the other way.

quote>

Ah, I knew there was something I forgot. Glr-el intersections (and glr-glr) would be treated just like any other glr piece, with prevents for each exiting glr side attaching to an el piece. Seems simple to me, but maybe I'm not considering something important.

However, before I grasp this flag bouncing sceme I can't really compare the two methods on these glr-glr el-el and glr-el intersections.

PPS: We also need to set out a specific way to make draggable pedmall. We could use your prevent method for this too. Then, again, because there are no tile-differences from pedmall to pedmall piece, there would be very little override code, so that may be easier.

-qurlix

quote>

...7puts his thinking cap on...time to dream in RULes