Help on creating puzzle pieces

[cogeo]

Does anybody have any tutorial (or information in general) on how to create network puzzle pieces?

I need help for the the whole procedure, ie making a button define a set of puzzle pieces to cycle through and/or rotate, define the network type and connectivity specifications, define the texture(s) to be used (through a ground level flat prop) and customise it's appearance by making a type-21 exemplar (network lot), and finally attach a SC4Path file to specify the pathing configuration for the piece.

I have examined the ped-mall tiles of NAM, and I have found little coherence and many loosely coupled elements, interrelated in a way I was not able to figure out.

Also any information on NAM's (and networks' in general) ID allocations and conventions so as to avoid conflicts. NAM's documentation does have some information, but it's not clear which ranges are available.

Any help would be greatly appreciated.

[Tarkus]

Hi cogeo-

Well, the only tutorial I know of that's out there is redlotus' Interchange Tutorial, which can be found here.

The tutorial, however, is very dense reading, and it's also 2 1/2 years old.  There are a few things that it unfortunately doesn't cover, and some things that have changed since, including a lot of things you are mentioned.  Namely, Type21 exemplars, button creation, and all RUL coding issues, which include rotation cycles, defining network types and connectivity.  In addition, the Effects Directory template file that he mentions is no longer attached, and I've personally found easier ways to do it. 

I've also been asked by a number of other people looking to break into transit modding about these issues, and I am strongly considering the idea of creating a new transit modding tutorial, which will cover puzzle piece/interchange creation and other branches of modding. 

As far as the Instance ID (IID) allocations, the NAM team internally assigns instances, similar to the BSC texture index.  A lot of the NAM stuff you'll see has an IID beginning with 5, following the syntax 0x5nnnnnnn. There is a bit of a backlog right now, since there isn't really an official "team leader" right now.  Mostly, people working on modding projects right now, as far as I know, have basically just looked at how things were basically set up, and picked IIDs themselves, taking into consideration the existing standards, while avoiding conflicts by going into the main NAM .DAT file and sorting the internal files by Instance. 

Hope that at least answers some of your questions, and if you need help with anything that redlotus' tutorial does or doesn't cover, I'd be more than happy to assist.   

Best Regards,
Tarkus

[cogeo]

Tarkus,

Thanks! I would like to ask one question. I think (pls correct me if I'm wrong) that in order to make ANY set of puzzle pieces someone has to mod the central RUL file (instance ID 0x10000000). But this causes a problem, only one such RUL file can be active at a time, resulting in only one NAM extension be available. Any thought to address this? I have considered pre-allocating a large number of IDs, adding the RotationRing/AddTypes sections etc, but not their corresponding [HighwayIntersectionInfo_...] sections - these could be defined in different RUL files, thus not having to override the main RUL file for every puzzle piece set you want to make. Do you think this could work?

[Tarkus]

cogeo-

No problem.   Yes, you are correct in that to make any set of puzzle pieces, you have to mod 0x10000000.  I know that Tropod has created entirely new RUL files before, like for the One-Way Road bridges, etc. but I believe there was some sort of hardcoded precedent in the EXE that allows it in that instance.  I actually tried copying 0x10000000 and changing the instance of the copy to 0x10000003 once, but I didn't have any luck with it.  As far as I know, you can't do it with RULs whose instance numbers begin with "1".

As far as preallocating, you certainly could, but be sure to comment them out if you're adding them directly into the RUL file, or the game will try to read them and do strange things. 

It would be really nice, though, if we could have separate Intersection Ordering RULs, because that would really save a lot of headaches with getting things to work together.  (For example, we wouldn't have the clashing between the new NAM and the current version of the RHW.  )

Hope that answers your question.

-Tarkus

[cogeo]

OK, I would like to start playing now, I need to create some 16-20 puzzle pieces.
As far as I was able to figure things out, each puzzle piece requires a range of 16 IDs (one hex digit), ie a number like 0x5######X. Making it zone/wealth dependent requires 4 textures w/ 5 zooms each, that is 20 IDs in total. How should I work this out? Extend the range, or instead use a range outside NAM (for the textuers only).
Also what about the RotationRing/AddTypes numbers?

EDIT: OK, I have assumed range BF## for the the RotationRing/AddTypes and 0x58FFFF## for the rest (S3D/FSH pairs, exemplars, LTEXT etc) - this may need to be extended to 0x58FFFE##. No other pieces use anything in the 0x58F##### range at all. I considered using the 0x580FFF## (and 0x580FFE##) range instead (both available as well), so that I leave the whole 0x58F##### completely free, but 0x580FFF## lies in the heart (well, actually near the end) of the GLR section, so it may be better to leave it for possible future GLR extension. What do you think? I haven't started any work on the network yet (I have just started with the textures), I would like to know your opinion first.

The tiles I'm working on is a set of dual GLR/Avenue puzzle pieces, pics to follow soon.

[Tarkus]

Hi cogeo-

Before you get too far along, is this what you had in mind with the Dual GLR/Avenue puzzle pieces?


If so, memo from the NAM Team has gotten most of these done (he's also nearing completion on Draggable GLR), and they're very likely to be released as part of the next NAM (v21).  (We are still deciding on the logistics for stations, however.)

As far as the general logistics for all puzzle pieces go, with the RotationRing/AddTypes and the IIDs, it sounds like you have most of it figured out. That's exactly right with the rotation types, though depending on the types of pieces one is making, the ordering may not be entirely linear (like the Elevated Road puzzle pieces, which actually go 7100, 7108, 7101, 7109, etc. because of the diagonals). With the zone/wealth dependency, all of the network textures I'm aware of basically come in sets of 4 with 5 zoom levels, following the format 0x5#####WV, where W is the wealth level (0=no wealth, 1=low wealth, 2=mid wealth, 3=high wealth) and V represents the zoom (ranging from 0-4, the FSH producing programs like SC4Tool and FiSHMan will automatically produce the different zoom levels). 

With the actual puzzle pieces and their IIDs, the method redlotus mentions in his tutorial with the grid is actually how the game reads the segments and arranges them when the piece is plopped in game, according to the CheckType section of the [HighwayIntersectionInfo] part of the RUL file.  So going vertically, your IID is always going to go up or down by 100, and horizontally, by 10.  The IID does not necessarily have to end in "0", though, as many of the diagonal pieces in the NAM end in "5", and in my work for the Rural Highway Modular Interchange System (RHWMIS), there's pieces with IIDs ending in "A".  So the template you're always going to want to follow is actually more like 0x5N###PPP, N is the network, and PPP refers to each part of the puzzle piece and its location in the overall scheme.  If your pieces are 1x1 or entirely horizontal-oriented, you can get away with 0x5N####PP.

Best Regards,
Tarkus

[cogeo]

Baah, this is exactly what I was aiming for!
Only point, I would add a few more T intersections w/ road, street etc, connecting to the one direction of the avenue only.
So I stop working on this, and please consider the ID ranges mentioned above availble as before.
Thank you for your information and your help.

[Serkanner]

Cogeo,

Perhaps you shouldn't stop this project but join forces with the ones that are already working on it. I agree with you that a few more puzzle pieces could be used, not to mention stations ... which is one of your expertises ( with transparant roofs and all  ).

I forsee a great future for the GLR if you would assist the current project.

Just an idea.

[cogeo]

A few thoughts on the above, I think a few pieces are still missing, like a crossing with GLR only (but not with GLR/avenue) etc.
Also some streetlights must be added, this time on the sidewalks (like in high-wealth avenues), there is simple no space in the median.
Another point, these unfortunately could not be wealth-dependent, it wouldn't be realistic to have an avenue with mixed $$$ and $$ streetlights, actually in draggable avenues the game calculates the average wealth and changes all streetlights and other wealth-dependent props (barriers, plants) and textures for the entire length of the avenue at once.

I have also considered making a station, but this has to be thought out very carefully first, the main problem is that there is no space for platforms in the median. One solution could be to route the avenue in an underpass and put the station above. This will still suffer from the no-access-zot problrm, any ideas?

[Tarkus]

Hi cogeo-

Yes, looking over the files I have, it appears those instances are perfectly alright.  Same with the rotation loops as well.  The IIDs memo has been using for the GLR-in-Avenue are all in the 0x584##### range. 

As far as the stations go, I believe that the median is wider with the puzzle pieces than with normal Avenues, so there may be a little leeway there.  It's possible we could narrow the sidewalks down even further, too, to widen the median or have the pieces where the stations are be wider (3x1).  Some have also suggested narrowing the Avenue to one lane at the stations and using the space that provides for the station. 

And I concur with Serkanner--you really know what you're doing when it comes to the GLR and mass transit options in SC4.  

-Tarkus

[bwatterud]

Off Topic Alert(Refering to the GLR in Avenue/Draggable GLR)  Now all we need are those curves for EL over road. 

[jeronij]

Mmm, this thread is really interesting, not only for the information available here, but also becasue of the so clever minds behind it. I am sure I will take a good profit of that one.

And cogeo, I completely agree with Serkanner's and Tarku's post about your skills and that you should not stop this 

[cogeo]

In addition, the Effects Directory template file that he mentions is no longer attached, and I've personally found easier ways to do it.

Tarkus,
One more question please?
Which are these easier ways to create the preview effect? Could you post a few more details?
Also what's the "classic" way of editing the preview directory? I could use a better hex editor (instead of the built-in one) but is this the correct way? SC4 dats contain effect dir files w/ more than one entries. Do we have any info on the above format? I think it would be more handy.
EDIT: Is modifying the names of the preview effects in the effect directory really necessary? I have noticed that for GLR the names are somehow irrelevant, eg preview_rail_dualnetwork011 which of course refers to another network. But by specifying an AutoTileBase and PreviewEffect pair, the effect is uniquely specified. So overtyping the two occurences of the effect model must be enough.

[memo]

I usually modify Effect Directory files in this way: At first I copy an existing EffDir and change the IID. Then I open the decoded hex file (I'll use the EffDir 0x580cc700 of the straight GLR puzzle piece as an example). Next I locate this sequence of bytes 05 C7 0C 58 , which is the IID 580CC705 that links to the preview model of the puzzle piece. This sequence occurs two times within an EffDir file. You have to change both to the IID of the new preview model. Then look for this "preview_rail_dualnetwork009" in the Ascii column and replace it with the preview name that you're going to use in the Rule file, e.g. "preview_rail_glr00". It's important to use lower case letters only and to start with "preview". Then look at the colomn to the left of the Ascii code and search 1B before the hex code of your preview name. 1B stands for the 27 letters of the old name, since the new one has only 18, you replace 1B with 12. If you're creating a set of puzzle pieces, I suggest to use different numbers at the end of the name and only vary these, so that all the preview names have the same number of letters, to save time. Also repeat this step for "review_rail_dualnetwork009_red" and finally hit apply. As a precaution reopen the EffDir file - if the reader crashes, you've apparently done something wrong.

It is indeed necessary to change the names. Otherwise all the puzzle pieces with the same name would have the same preview model. The names just look similar because of convenience as said above.
AutoTileBase specifies the ID range of the puzzle piece. Actually, it controls the (sometimes) zone-/wealth-dependant base texture as well, but this doesn't work for every network type.

[Diggis]

Just out of curiosity...  When stations are transit enabled lots they cause no access zots... what if they were puzzel pieces, so are part of the network itself?

[cogeo]

@memo: Thanks! As said I have stopped working on the dual Avenue/GLR pieces, as you are near completion. I had only made the texture for the straight piece, and Tarkus informed me early on, so he saved me from a great disappointment! I have started another set of pieces, and some early pics are about to be released soon, probably tomorrow.

@Diggis: I have already experimented with this, I attempted making my roadtop mass-transit stations puzzle pieces instead of TE lots. This not only solves the no-access zot problem, it also does not cause (visual) conflicts with the turning lanes. BUT: many properties like maintenance cost, the Budget Items etc appear not only not to work, but not even be present at all. Most importantly these puzzle pieces do not even perform transit switches. The only property that appears to have some effect is the occupant groups, and of course it is absolutely possible to add a type-21 exemplar and put a busstop shelter on it, but these are not enough to make them (functional) busstops. I have tried many ways to mod them, like setting the purpose properties for the lot and the "highway" exemplar, or adding a "building" (a LotConfig line starting with 0) and of course a proper "busstop" building exemplar, but nothing of the above worked. Unfortunately this appears to be rather hardcoded. It might be possible to create a hidden lot programmaticaly (scripting) or even change the source code of the game (now available), but have not any clue on the above.

[memo]

I have experimented with this as well. I'm sure that a puzzle piece can't have the features that a TE-Lot has. But when you carefully (because you risk a game crash) hover a puzzle piece over a TE-Lot, and place it like this:

the bus stop is demolished and you can bulldoze the end of the puzzle piece, so that the remaining part changes to normal road. The props of the bus stop remain and it still works like a bus stop!! Then you can connect the road und developement in front of the bus stop is possible.
If you want to demolish the bus stop, you have to place the TE-Lot again at the same tile and then bulldoze it. Otherwise the main building would remain.
Keep in mind that this method is only experimental and not much tested.

[cogeo]

@memo: interesting technique! Then could a solution be a special puzzle piece, say 3x1 or 4x1 that allows a TE lot in the middle, thus allowing a tile being occupied by both a lot and a network piece, I mean somehow fool the game to allow this?

=========================================================================================

As for the pieces I'm currently working on, it's a set of GLR pieces with fence props. Here is a pic:


And some details:


Of course it is based on the existing GLR pieces (and connects to them, as expected). I still have to make the remaining pieces and then add some more, with fences at the one side only. I'm also planning making their heavy rail counterparts.

The "fence" props can be anything, fences, bushes, hedges, noise-absorbing walls, stone walls, metallic barriers etc. Only requirements, they must be about the size of a tile long (16m) and preferably have both straight and diagonal versions. As the props are referenced by a prop-family ID rather than by prop ID, any props that meet the above criteria can be used, and of course it is possible to have any model combination in the same city at the same time, and they are externally selectable. I'll post more pics, as the project evolves.

[screamingman12]

I have also attempted to do something similar to the GLR in avenue puzzle peices, but I'm going for a mor historic/urban feel with cars possibly being able to drive on the GLR tracks:


So far, I think that the GMAX model is about done, but GMAX only exports in .P3d format. Shouldn't it be in .3DS format or SC4model format?

[cogeo]

@screamingman12: The procedure you have taken (ie BAT the whole tile) is completely wrong. Instead, you have to make the textures first (better take some of the ingame textures and modify them as needed), make the S3D files that use them (again take the from the game or NAM, and change the texture ID they reference) and then make the "highway" exemplars and their corresponding type-21 exemplars (network lots). Then you have to add the necessary props on these network lots. So most of the work is actually modding (network modding in particular), and you have to read such tutorials before starting working on these tiles.

===========================================================================

I have found a minor bug in NAM's GLR. Have a look at my post on ST.