Advertisement
Guest User

Untitled

a guest
Feb 18th, 2012
639
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 34.71 KB | None | 0 0
  1. b22rian: Hello everyone ! My name is Brian, .. and I would like to welcome all of you to the much awaited and anticipated seminar -
  2. b22rian: " FUTURE OF THE RHW AND BEYOND !! "
  3. b22rian: This will complete our special 2 part series on the RHW. The first having been done last week by NAM members Maarten and Riiga.
  4. b22rian: And as my good friend Tigerbuilder pointed out to me , For people who love transit this is indeed the ultimate seminar we will likely ever do !!
  5. b22rian: So this brings us today's main guest speaker, Tarkus. Although many who know him well call him simply "Alex".
  6. b22rian: Alex is addition to being the heart and soul of RHW for many years now is also recognized as the unofficial " Leader of the NAM team "
  7. b22rian: .. And since most of you are well aware of Alex's transit accomplishments, ( Too many to this here !!),
  8. b22rian: .. I just wanted to briefly touch on the fact that Alex is also one of the friendliest chatters we have ever had in chat and also goes the extra mile to help anyone in chat regardless of their questions or gaming abilities. Something I am very proud of him for to be sure !
  9. b22rian: .. and none of us could ever thank him or the NAM team enough for what they have contributed to this community for many years now. Providing all of us only with the best custom content, that is always NAM's trademark.
  10. b22rian: .. So without further ado.., I now present to you Transit genius extradinaire.. and one of my best friends !...
  11. b22rian: please a big round of applause... for Alex !!!!!
  12. b22rian: alex u have the floor my friend :)
  13. riiga applauds loudly
  14. gurning_chimp applauds
  15. lreyome254 applauds
  16. katherman111 applauds
  17. bakercity: clap clap
  18. _swamp_ wh00t wh00t
  19. 111222333444 applauds
  20. ba zing ze: clap
  21. meister1235 applauds
  22. vlasky applauds
  23. mntoes: clap clap
  24. durfsurn: applauds
  25. pagenotfound: :D
  26. ivo_su: Alex alex
  27. tarkus: First off, thank you so much for your efforts in setting this up, Brian.
  28. b22rian nods
  29. tarkus: And thanks to all of you for coming--I'm really thrilled and honored to be doing this.
  30. tarkus: Welcome to "RealHighway: The Future--Project 57 and Beyond".
  31. tarkus: During this seminar, I will be discussing some of the latest, cutting-edge modding developments underway and in planning for the RealHighway (RHW) mod, including the rather mysterious "Project 57" effort (formerly Project 0E).
  32. tarkus: Much as Maarten did last time, I've prepared a series of slides that I will refer to throughout the presentation.
  33. tarkus: I'll start out here with Slide #1: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307909
  34. tarkus: First off, a little about me and how I got into this crazy business (and believe me, it is crazy!) of transit modding.
  35. tarkus: I'm 26, live in the Western US state of Oregon, and am working on my Ph.D. in music composition.
  36. tarkus: I started getting involved in transit modding seriously in October 2006, and 5 years ago this month, I was invited onto the NAM Team.
  37. tarkus: I first discovered the online SC4 community toward the end of 2005/beginning of 2006, and being a road enthusiast, was just floored when I discovered that there was a mod out there that added a ton of new transit functionality.
  38. tarkus: Needless to say, I was immediately taken with the NAM.
  39. tarkus: Also around that same time, a new project, then called the "Rural Highway Mod" (RHW) popped up with a very rough alpha build.
  40. tarkus: That takes me to Slide #2:
  41. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307910
  42. tarkus: The RHW was extremely limited in that very first release, which came out November 16, 2005.
  43. tarkus: It was originally labeled as "Version 0.12", but it later got "retconned" to "1.2".
  44. tarkus: Even despite its limitations, though, I was really intrigued by what it offered--I had never been super fond of the Maxis Highways, and I saw some potential in it being an "alternative", at least in some situations.
  45. tarkus: And it was ultimately pretty revolutionary from the modding side as well--it was really the first instance of something we take for granted nowadays: the "override network".
  46. tarkus: Taking an existing network and making it act as if it's a completely new network.
  47. tarkus: Alright, onto Slide #3 (click next or follow the link):
  48. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307911
  49. tarkus: That's the extent of all RHW 1.2 could do.
  50. tarkus: Two puzzle pieces, and just a handful of draggable intersection types, plus very basic diagonal functionality.
  51. tarkus: Now onto Slide #4 (click next or follow the link):
  52. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307913
  53. tarkus: That image right there is my very first attempt at doing anything in October 2006.
  54. tarkus: All I wanted was to add one puzzle piece to the RHW--an Avenue-over-RHW-4 piece.
  55. tarkus: I had no idea that I'd eventually be making hundreds more over the next few years.
  56. tarkus: Now onto Slide #5:
  57. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307915
  58. tarkus: When I arrived in the transit modding community, it was seemingly on the decline.
  59. tarkus: A lot of the great modders of yore--folks like Tropod, the7trumpets, Teirusu, smoncrie, etc., had retired or otherwise gone MIA.
  60. tarkus: Additionally, the most requested item amongst the NAM userbase was more Maxis Highway interchanges. The old NAM: Requests thread was filled with them.
  61. tarkus: Quite a few people tried making them, as evidenced by all the screenshots of attempts in the old NAM: Development thread. But it was brutally hard work--almost all of them failed.
  62. tarkus: In fact, the only Maxis Highway interchange makers that succeeded were the team of redlotus and TheGreatChozo, who added two interchanges in 2004-2005.
  63. tarkus: One of the biggest things the RHW was missing at that point was any sort of interchange functionality at all.
  64. tarkus: All it could do at that point was intersect Streets.
  65. tarkus: It was essentially a "clean slate", if you will.
  66. tarkus: I had a lot of good discussions with the small-but-intensely-loyal RHW userbase at that time, which included folks such as Haljackey and jplumbley.
  67. tarkus: And a lot of those discussions, and seeing the general way things had gone with the transit modding community led me to a few design goals which have become the cornerstone of RHW development today.
  68. tarkus: Now onto Slide #6:
  69. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307917
  70. tarkus: The lesson I learned from seeing the "interchange graveyard" was that the pre-fab approach of Maxis Highway interchanges didn't work.
  71. tarkus: It was extremely labor intensive, the people doing it got burnt out, and there wasn't too much ultimately gained in terms of functionality.
  72. tarkus: So I came to the conclusion that going modular with the interchanges was the way to go. It'd make the modding side more efficient, and it'd allow the end user to unleash their creativity--interchanges only limited by their own imagination.
  73. tarkus: I also made it a goal to be able to replicate everything in the Kurumi Field Guide of Interchanges with the RHW.
  74. tarkus: http://www.kurumi.com/roads/interchanges/index.html
  75. tarkus: qurlix had also planned to make additional widths of the RHW back then--even showing a prototype of something he called the "XRHW" (equiv. to the modern RHW-8S). Consequent to that, ultimately, the RHW was really destined to go beyond being simply a "Rural" highway.
  76. tarkus: Rather, something that could be used regardless of the surrounding environs--a modular highway for all purposes.
  77. tarkus: Now that I've discussed some of the history of the RHW, and how it impacted the design goals of the mod, it's time to discuss the future: Project 57.
  78. tarkus: Slide 7: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307918
  79. tarkus: Project 57 is basically a ground-up redesign of the RealHighway's technical back-end.
  80. tarkus: It entails a complete re-write of the RUL2 code (RUL2 = a RUL file that handles draggable overrides), as well as a shift of the Instance ID (IID) range to the 0x57###### range and re-orientation of some items.
  81. tarkus: There's been a little bit of confusion as to how it relates to the rest of NAM development--I'll attempt to clarify that.
  82. tarkus: While it is being done in conjunction with the switch back to the "Monolithic NAM" paradigm for NAM Version 31, it doesn't entail any updates to other NAM components itself, aside from where they interface or "crosslink" with the RHW.
  83. tarkus: If we were continuing the "separate-download" NAM Plugin paradigm, Project 57 would essentially be RHW 6.0.
  84. tarkus: This, of course, begs an important question--why Project 57?
  85. tarkus: Slide #8: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307920
  86. tarkus: The simple fact is, the technical under-the-hood side of the RHW has been a mess for years.
  87. tarkus: It was already a little bit of a mess going all the way back to RHW 1.2, and then there was an attempt to fix it with RHW 2.0 in January 2008.
  88. tarkus: Unfortunately, this "fix" didn't really work out, and actually just made things worse. There was content produced under several different proposed IID schemes, and all of them ended up getting mixed together in Version 2.0.
  89. tarkus: We're finally fixing that for good with Project 57.
  90. tarkus: The ultimate goal behind this is to make it easier to add more complex functionality and stabilize it to a much greater extent, producing a better mod in the process.
  91. tarkus: Additionally, it'll make third-party texture/cosmetic modders' jobs much easier. The existing IID scheme has proven very difficult for anyone but NAMites to navigate, and we even still have a hard time (myself included).
  92. tarkus: Slide #9:
  93. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307921
  94. tarkus: That sums up the previous points there. We were using a modified SAM scheme proposed by jplumbley for most of the base network content--while this worked to some extent for some of the smaller networks, the RHW networks are much less homogeneous than SAM networks.
  95. tarkus: And it really got messy when the C-type networks showed up.
  96. tarkus: Here's just how screwed up the existing RHW IID scheme is.
  97. tarkus: Slide #10: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307906
  98. tarkus: There's a little bit of an underlying logic there, but it breaks down pretty quickly.
  99. tarkus: Now, here's how things look under the Project 57 IID scheme: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307922
  100. tarkus: As you can see, there's a much more logical, consistent pattern between networks now. That, in turn, makes it easier to mod. The Project 57 IID scheme is largely based off the similar setups for the NWM and RAM.
  101. tarkus: Slide #12: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307923
  102. tarkus: You may have heard us refer to Project 57 as "Project 0E" previously. Originally, the 0x0E###### range was going to be used for the re-alignment of IIDs, but that didn't turn out too well.
  103. tarkus: We all make mistakes. :)) Fortunately, I was able to correct my little gaffe pretty easily due to the more consistent structure of the mod.
  104. tarkus: And here's how convoluted everything was on the rotation side--the base network and analogous override network pieces were not oriented similarly, which added an additional wrinkle into writing all that RUL2 code.
  105. tarkus: Slide #13 demonstrates this: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307924
  106. tarkus: The orthogonals for the smaller networks also actually ended up going the opposite direction from the wider networks. Needless to say, it led to many headaches amongst the development team.
  107. tarkus: But the orientation of the override networks now matches the base network counterparts after Project 57.
  108. tarkus: Slide #14: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307925
  109. tarkus: This shows just how much RUL2 code has grown over the years.
  110. tarkus: When RHW 1.2 came out, the "draggable revolution" hadn't really begun yet.
  111. tarkus: Early NAMites didn't have much use for RUL2, so the file size was pretty small.
  112. tarkus: The initial RHW release only had 285 lines of RUL2 code.
  113. tarkus: As you can see here, it's grown exponentially. The RHW section of the RUL2 build in the NAM Controller when RHW 4.0 was released was about 4 times the size of the entire RUL2 build for NAM Version 19/RHW 1.2.
  114. tarkus: Project 57's new/revamped RHW code is thus far approaching 200,000 lines and there's still a lot to add to it. (The full RUL2 itself is now approaching 600,000 lines).
  115. tarkus: Slide #15: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307927
  116. tarkus: And here's a "peek behind the curtain".
  117. tarkus: You're looking at my hobby there.
  118. tarkus: That's what RUL2 code looks like--specifically, that's a segment of the code to let the EMIS cross over a ground-level RHW-4.
  119. tarkus: It'd take another 21,720 slides to show the entire file, and 10,221 pages of Letter-size paper at 10pt font to print it.
  120. tarkus: (It's gone up about 1000 pages since Maarten's presentation.)
  121. tarkus: Slide #16: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307928
  122. tarkus: Now another important question: how will Project 57 affect my existing RHW systems, with all the very fundamental changes to the mod?
  123. tarkus: Fortunately, we've taken steps to ensure that your existing RHW systems continue to function--and can be updated to the new specs.
  124. tarkus: The entire RHW 5.0 file (minus a few subfiles for icons, etc.) will become a "Legacy Support" file for RHW 5.0 and earlier systems.
  125. tarkus: Additionally, recursive, "invasive" RUL2 code has been added to convert RHW 5.0/earlier systems to Project 57 RHW specs just by clicking along them.
  126. tarkus: We did a similar thing in the transition from RHW 1.3 to 2.0 back in 2008.
  127. tarkus: Now that I've totally "geeked out" on the technical side, it's time for what you've all been waiting for.
  128. tarkus: Slide #17: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307930
  129. tarkus: Teaser time!
  130. tarkus: Slide #18: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307931
  131. tarkus: This here is an overview of some of the stuff currently in development or in a rough prototype that I'd like to discuss today.
  132. tarkus: The main focus is the Multi-Height System, and I'll also touch on the improved stability, additional elevated networks, and some new Flex items.
  133. tarkus: Please, also, note the disclaimer on the elevated items--we have limited modeling resources, so the functionality there will probably continue to drag behind the ground-level versions.
  134. tarkus: Slide #19: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307934
  135. tarkus: This is an overview as to what all is planned for the Multi-Height System. The network levels in italics already exist in RHW 5.0.
  136. tarkus: Suffice to say, there's a lot of new networks and heights going in--with these network widths, we're looking at a system containing more than 30 networks.
  137. tarkus: There has been discussion about going even wider still (possibly up to 16 lanes), though that's still on the drawing board, and those networks would be limited to L2 height.
  138. tarkus: To clarify what all these numbers mean, L0 = Ground Level, L1 = 7.5 meters elevated, L2 = 15 meters elevated (existing elevated content), L3 = 22.5 meters elevated (top deck of DDRHW), L4 = 30 meters ("High Elevated").
  139. tarkus: Now onto some teaser pics.
  140. tarkus: Slide #20: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307938
  141. tarkus: This is the first ever true multi-height interchange I ever built. This was actually a pre-Project 57 prototype of the L1 (7.5 meter) MIS system being used here, started by mtg, which I later expanded. (Still one little stability issue there if you have a good eye)
  142. tarkus: As I mentioned earlier in the goal of having everything in the Kurumi Field Guide of Interchanges be possible with the RHW, the multi-level stack-type interchanges are really the last remaining hole in fulfilling that.
  143. tarkus: RHW stacks are really what we've been reaching toward with development over all these years.
  144. tarkus: Now onto Slide #21: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307940
  145. tarkus: Here you can see all sorts of new content--elevated wider RHWs at L1 and L2 height, being crossed over by new heights of ERHW-4.
  146. tarkus: That's an L4 (30m) ERHW-4 going over all those big wide elevated highways.
  147. tarkus: Slide #22: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307942
  148. tarkus: Here's a look at both the new additional heights and improved stability . . . Maarten told me this looks like an M.C. Escher drawing.
  149. tarkus: That's all 5 levels of the RHW-6S there.
  150. tarkus: And for those of you who have wondered why we stuck the Double-Decker RHW (DDRHW)'s two decks at 15m and 22.5m, the next two slides should shed some light on that.
  151. tarkus: Slide #23: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307943
  152. tarkus: An L1 EMIS going underneath.
  153. tarkus: And Slide #24: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307946
  154. tarkus: An L4 ERHW-4 going over top of a DDRHW-4.
  155. tarkus: And a few more teasers in the next slides on the Multi-Height System.
  156. tarkus: Slide #25 shows that diagonal functionality is in place for the ERHW-4 heights:
  157. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307948
  158. tarkus: Slide #26 shows an L3 ERHW-4 crossing OVER a Monorail line and an Elevated Light Rail/Tram line.
  159. tarkus: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307953
  160. tarkus: And here's another look at the improved stability . . . not that anyone needs to do this particular setup, but you can with Project 57.
  161. tarkus: Slide #27: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307956
  162. tarkus: Here's another improved stability situation that may be of more use (and is often requested).
  163. tarkus: Slide #28: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307958
  164. tarkus: If you want to run light rail down the middle of your ERHW stretch, now you can.
  165. tarkus: Now onto Slide #29: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307961
  166. tarkus: One of the other big developments underway is the FLEXCurve system, developed by jondor (the same guy who figured out the seemingly impossible RHW-on-Regional-Transport View setup).
  167. tarkus: FLEXCurve is essentially a ground-level version of the familiar FLEXFly system.
  168. tarkus: It was designed with multi-height RHW setups in mind from the get go, as you'll see.
  169. tarkus: Here's Slide #30: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307963
  170. tarkus: As you can see there, both it and FLEXFly are interacting with the L1 ERHW-4 . . . essentially, the makings of a compact T-interchange are there.
  171. tarkus: (It'll get even more so once we get into FLEXFly-over-FLEXCurve situations, but that's probably still a ways off.)
  172. tarkus: The next two items I'd like to discuss are in an early prototype stage.
  173. tarkus: Slide #31: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307965
  174. tarkus: The first of these is FLEXRamp.
  175. tarkus: Essentially, it's a FLEX rendition of ramp interfaces, basically designed off a slight modification to the Draggable Ramp Interface (DRI) system.
  176. tarkus: It creates the flexibility of the DRI, but with the ease of use of just plopping the ramp setup.
  177. tarkus: As the number of ramp interfaces has expanded exponentially over the past few releases (and will keep doing so as the new heights/widths get integrated), this may present a way forward in terms of menu management.
  178. tarkus: Slide #32: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307966
  179. tarkus: Plus, perhaps most importantly, it'll pose a solution to one of the most often-heard complaints about ramp interfaces: their intolerance toward any kind of slope/incline.
  180. tarkus: As you can see here, this Type A FLEXRamp is clearly on a hill, and isn't flattening it.
  181. tarkus: Slide #33: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307966
  182. tarkus: Additionally, because of how I modified the base DRI setup in the Individual Network RULs, using some trickery, the auto-connect functionality (which is hardcoded) doesn't rear its (usually ugly) head.
  183. tarkus: This hints at the fact that we could, in fact, have straight ERHWs going over top of ramp interfaces, further allowing interchanges to be come more compact while maintaining realistic scale and modularity.
  184. tarkus: Slide #34: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307971
  185. tarkus: The next item I'd like to discuss is FLEXTrans--it's essentially an RHW version of the Draggable Transition setup introduced to the Network Widening Mod (NWM) in its recent Version 2.0 release.
  186. tarkus: The auto-connect here also posed problems preventing the "double-stub" trick used on the NWM from working in an RHW situation.
  187. tarkus: So, I started looking for a solution, and may have found one with the "Disruptor" technique, which nearly got deployed in RHW Version 5.0.
  188. tarkus: (Slide #35 appears to be a duplicate of Slide #34) so let's skip ahead to Slide #36: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307971
  189. tarkus: That there is a "Disruptor" in action.
  190. tarkus: A trick RUL1 setup has been used with the Street dead-end stub to create a "disruption" in the auto-connect, which thus allows for two different RHW widths to meet and transition.
  191. tarkus: Slide #37: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307977
  192. tarkus: This does have the benefit of being able to be built through fully draggable means.
  193. tarkus: However, the disadvantage is that it's not particularly conducive to larger setups (much as Draggable Transitions are with the NWM).
  194. tarkus: Given the functionality gain, it may merit looking into alternate setups to "Flex" larger transitions.
  195. tarkus: Slide #38: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307978
  196. tarkus: One of the biggest discussions amongst the NAM Team is improving "crosslinking" between different NAM components.
  197. tarkus: It's been a pretty long road (pun intended) to do so just because there's so many things to crosslink, but here's a look at some of the stuff we're going to try to fix up this time around.
  198. tarkus: And here's a list of a few other features under consideration/in planning.
  199. tarkus: Slide #39: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307980
  200. tarkus: Lastly, here's a peek at one of them.
  201. tarkus: Slide #40: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307981
  202. tarkus: A couple last closing things I'd like to touch on . . .
  203. tarkus: Slide #41: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307982
  204. tarkus: As mentioned earlier, the next NAM release, NAM Version 31, will be a "Monolithic NAM".
  205. tarkus: It'll be the first of its kind since NAM Version 20 back in December 2006.
  206. tarkus: All of the current main "separate-download" NAM plugins, including the RHW, as well as the NWM, RAM, SAM, HSRP, and the lesser-known Rural Roads Plugin, will be merged into the NAM itself.
  207. tarkus: They will be selectable as options in the installer, so just as always, you'll have the option to customize your installation with the features you want.
  208. tarkus: And as a bonus, it'll make the file maintenance (particularly with crosslinking between items) much easier on the NAM Team side, and be more user-friendly in the long haul.
  209. tarkus: The filesize will, of course, be a bit larger. I'd anticipate somewhere around 45MB for the Windows installer, and around 85-90MB for the Mac/manual .zip file.
  210. tarkus: But as our research has shown that the "separate-download" plugins are being adoped by more and more NAM users, the actual increase in bandwidth, coupled with the simplification of packaging, will actually make things more efficient and effective.
  211. tarkus: Slide #42: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307984
  212. tarkus: Another question likely to be asked: when are the Project 57 RHW and Monolithic NAM being released?
  213. tarkus: As per standard NAM Team policy, there's no scheduled release date or timeline for release. It's done when it's done.
  214. tarkus: And besides: we like to surprise people. ;)
  215. tarkus: Slide #43: http://www.majhost.com/cgi-bin/gallery.cgi?i=3307986
  216. tarkus: And that brings us to the conclusion of this seminar--thank you to everyone for coming, thanks to Brian, Maarten and the ST Staff for their help with this, and to everyone who has supported the NAM Team and the RHW over the years!
  217. gurning_chimp: Is RTMT ever likely to be included in a monolithic NAM?
  218. pagenotfound: what exactly does this "disruptor" do for transitions?
  219. b22rian: before we begin our Q and A session
  220. mrtnrln: Wait everyone!
  221. gurning_chimp applauds
  222. meister1235 And me, because i'll post a Log somehwere :)
  223. meister1235 gurning_chimp: no
  224. b22rian: a big round of applause please for alex :)
  225. vlasky applauds
  226. durfsurn: clapping
  227. suzaku comes back from working on SimGameStuff and applauses
  228. meister1235 applauds
  229. bakercity: clap
  230. mithokey: Very nice Alex :)
  231. mrtnrln: If you want to ask a question, type "/me raises hand"
  232. buddybud: huzzah!
  233. ee99 applauds
  234. tarkus: Thank you all--you're all too kind. :D
  235. b22rian: please everyone lsiten to maartens instructions, thanks :)
  236. riiga applauds
  237. meister1235 raises hand
  238. pagenotfound raise hand
  239. mithokey raises a hand
  240. tarkus: Meister
  241. b22rian: we have the entire nam panel to answer all questions :)
  242. durfsurn: me raises hand
  243. katherman111: "/me raises hand
  244. riiga: Obey Maarten or I'll give you a warning :P
  245. anotn: tarkus: it is us who should thank you
  246. meister1235: Are the old rul Codes still available somewhere?
  247. _swamp_: whew
  248. katherman111 raises hand
  249. aaaling: Can I provide "base" textures for some of the CPs /me raises hand
  250. _swamp_: Question
  251. cackz applauds
  252. b22rian: let us begin maarten
  253. b22rian: please raise your hand
  254. aaaling raises hand
  255. pagenotfound: guys one at a time
  256. _swamp_: Have you thought of improving upon the Quadruple decker RHW6-c? http://www.majhost.com/gallery/gafibla/SimCity4/qdrhw6-c.jpg
  257. tarkus: meister1235: The old controller builds are still floating around somewhere in the hinterland of our Private Development Exchange.
  258. xyloxadoria: Okay guys one question at a time
  259. b22rian: thanks chris :)
  260. b22rian: maarten ?
  261. aaaling raises hand
  262. tarkus: Alright, I think pagenotfound is next.
  263. b22rian: yup :)
  264. b22rian: rob ?
  265. b22rian: thanks chris
  266. tarkus: xyloxadoria: Thanks, Chris!
  267. durfsurn: Will TRAM in road on road etc become draggable
  268. mrtnrln: durfsurn: No
  269. b22rian i have no idea what happened to maarten
  270. anotn: You mentioned a difference between modeling network pieces and bats, what is the difference beside the export method?
  271. mrtnrln: This is simply because it's a dual network, and therefore it will cause problems with intersection interfaces
  272. tarkus: durfsurn: There was an experiment with it using RUL0 AutoPlace, but that method was also the same thing that caused the infamous Car Ferry CTD with NAM Version 28.
  273. tarkus: anotn: The key difference is the fact that network models are True-3D as opposed to orthographic projections.
  274. pagenotfound: what exactly does this "disruptor" do for transitions?
  275. mrtnrln: anotn: BATs are dumbed down models; it's actually an image printed on a simple 3D Model...
  276. tarkus: pagenotfound: Basically, it stops the "auto-connect" and provides an interface between, for instance, an RHW-6S and an RHW-4.
  277. tarkus: You'd drag an RHW-4 out, place a disruptor, connect the RHW-6S into the disruptor and it'd turn into a transition.
  278. aaaling: Can I provide "base" textures for some of the CPs?
  279. mrtnrln: If you wouldn't place a disruptor, the transistion becomes highy unstable
  280. pagenotfound: you mean where that ugly stub that sometimes happens when transitioning?
  281. mrtnrln: aaaling: Not neccesary.
  282. mrtnrln: I can make them in basically 10 minutes
  283. vlasky: Will there be development of road tunnels or how they're called underwater bridges that I have seen in the sc4devotion thread?
  284. tarkus: pagenotfound: Yes.
  285. aaaling: That's fast! But mine are the American Textures!
  286. b22rian: vlasky: great Q :)
  287. mrtnrln: Textures are not the most effort with these pieces; it's the RULing and making such puzzle pieces that takes up most time.
  288. tarkus: aaaling: Maarten's well-versed in worldwide highway markings. :)
  289. tarkus: vlasky: That is a good question.
  290. tarkus: The "underwater bridges" awhile back were a project of smoncrie's.
  291. mithokey: Sorry if I missed this, but will the flexfly have more than one lane eventually?
  292. mrtnrln: mithokey: Yes, there are plans for a 2-lane FLEXfly
  293. tarkus: Unfortunately, smoncrie has been absent quite some time, and I don't know that anyone is going to be continuing that work . . . but we have some interesting other stuff on that front, however, that will be shown in due time. :)
  294. mrtnrln: But only 45 degree curves, if I understood that correctly...
  295. katherman111: will the NAM work on a series of RHW bridges for rhw6 and larger????
  296. mrtnrln: This is simply because 90 degree curves would be too tight for such ramps...
  297. tarkus: katherman111: The good news is, choco just recently returned to actively modding, and is dusting off all his bridges.
  298. tarkus: So yes.
  299. durfsurn: Will we be able to drag el networks over/under flex ramps and will there be el flexramps?
  300. mrtnrln: Besides, I've corrected some of Choco's models
  301. tarkus: mrtnrln: Including that one RHW-6S bridge, which I've also since updated to Project 57 specs.
  302. tarkus: durfsurn: FLEXRamps will essentially work similarly to DRIs, so dragging an elevated network into the mainline of them will elevate it.
  303. b22rian: durfsurn: excellent Q
  304. mrtnrln: durfsurn: I think FLEXramps are able to go from ground to elevated setups, just like the FlexSPUI
  305. mithokey: okay, thanks
  306. tarkus: durfsurn: And yes, the eventual plan is to allow perpendicular crossings over top of FLEXRamps, further allowing for more compact/realistic scale interchanges.
  307. aaaling: I have some "single side passing lane" CP textures on my hard drive.
  308. aaaling: Cool!
  309. b22rian: tarkus: is there any further plans for the spui interchange system ?
  310. ivo_su: Will there be development around FLUPs patterns Dexter / Matt he is very smart and I think that is a real discovery (rough diamonds)
  311. mrtnrln: aaaling: I can make one with correct markings in a few minutes...
  312. lreyome254: Will the new version feature curveable RHW 6+
  313. tarkus: b22rian: Yes, there is. Probably the first new development will be an L1 Elevated FlexSPUI, which will work in conjunction with Shadow Assassin's new L1 Avenue Viaducts (planned for NAM Version 31).
  314. mrtnrln: ivo_su: It depends on making the ramps technically ready. But I guess we'll be seeing those in the NAM31
  315. aaaling: Well, for mine, the dashed half is the same frequency of the block markings CPs.
  316. tarkus: ivo_su: We are looking at FLUPs development going forward--there's some interesting stuff happening behind the scenes there, actually.
  317. tarkus: lreyome254: That depends on whether or not someone makes models for it.
  318. pagenotfound: i thought rhw tunnels didnt work
  319. mrtnrln: aaaling: you don't see that kind of markings in the rest of the world; often the dashed lines are the same lenght as the lane seperation lines.
  320. tarkus: Model-based elevated items will generally lag 3-4 versions behind their ground-level counterparts (unless we can use existing geometry).
  321. tarkus: pagenotfound: The normal tunnel technique doesn't.
  322. motorstorm: I've seen some images over at SC4D of super-stable MIS networks, being able to be dragged through multiple adjacent networks with no override. Will this super-stablility be seen on all levels, 0-4 in the next release?
  323. mrtnrln: motorstorm: Yes
  324. aaaling: Will the wider RHW bridges be Maxis Highway based?
  325. tarkus: motorstorm: Yes. All 5 levels of the MIS are being coded for at once.
  326. tarkus: aaaling: Yes, they will be.
  327. brenn21: tarkus: so i noticed you mentioned RHW tuleps... is this going to be like puzzle pieces
  328. mrtnrln: Or they will be puzzle piece based...
  329. pagenotfound: will flexfly pass over all of the levels but the highest or what?
  330. tarkus: brenn21: Yes, it's going to be just like the existing Road/Avenue TuLEPs.
  331. riiga: brenn21: Yes, just like regular TuLEPs.
  332. durfsurn: Will there be a "NAM Components" or similar seminar at any point? Like the development of FLUPS other crosslinking among others?
  333. riiga: brenn21: http://i705.photobucket.com/albums/ww55/anonymson/Tulep1.png
  334. tarkus: pagenotfound: Yes, there are plans for FLEXFly/FLEXCurve on every level between L0-L4.
  335. riiga: That's an old development pic.
  336. vlasky: tarkus: will there be any development of on-ramps 9similar to train viaducts that connect to the bridge directly) for the road networks?
  337. mrtnrln: There is a development going on by Vince (Blue Lightning) that will build side by side and wide bridges using a combination of the DBE and the puzzle piece method.
  338. riiga: of mine.
  339. pagenotfound: will there be double deckers for rhw 6?
  340. mrtnrln: pagenotfound: Probably not...
  341. brenn21: riiga: looks good
  342. tarkus: durfsurn: That's a good question. I'm not really super involved with FLUPs development, so I probably wouldn't be the best to ask on that front. But I'd like to see more NAM-related seminars of that kind, certainly.
  343. katherman111: tarkus: nice
  344. mrtnrln: Planning transistions for the DDRHW-6 is kinda tricky...
  345. pahs1994: How many tiles will the L1 ramps be?
  346. shadow assassin: 4
  347. pagenotfound: mrtnrln: http://www.majhost.com/gallery/gafibla/SimCity4/qdrhw6-c.jpg but what is this?
  348. durfsurn: Will a AVE-6 SPUI be implemented eventually as well?
  349. durfsurn: like a AVE 6 spui
  350. durfsurn: as in perpendicular el over L0 flex ramp
  351. tarkus: pahs1994: There will also be a short 3-tile one.
  352. riiga: pagenotfound: it's a photoshopped image.
  353. _swamp_: :))
  354. ganaram di: pagenotfound: A phothshopped picture.
  355. pagenotfound: oh D:
  356. mrtnrln: pagenotfound: That was from "before I knew better" :{
  357. mrtnrln: :P
  358. tarkus: Yes, the eventual plans do involve creating an AVE-6 FlexSPUI, as well as FlexSPUIs for Type B (Dual-Left) TuLEPs.
  359. _swamp_: pagenotfound: I made that in photoshop :P
  360. pahs1994: Cool. will the 4 levels of RHW have on slope transitions also?
  361. shadow assassin: but there will also be a longer 4-tile ramp for 0-L1, as well as transitions from L1 to L2
  362. durfsurn: Will there be a NWM seminar?
  363. tarkus: durfsurn: That's a good question. I'd be open to doing one.
  364. suzaku: I don't think my question ever went through. Is it possible that SimGameStuff (my website) could be a mirror of the Monolithic NAM? Or mirror it now being that ST is unable to mirror it due to a 20 meg file limit? Sorry for asking so much, I just haven't really had a confirmation.
  365. mrtnrln: durfsurn: Probably. Problem is, someone has to take it
  366. b22rian: just a few more questions guys
  367. b22rian: im sure alex is quite tired from the seminar thanks
  368. tarkus: xyloxadoria: Chris, thank you for your efforts here!
  369. tarkus: b22rian: Thanks, Brian
  370. riiga: suzaku: That is something we will have to discuss internally.
  371. b22rian: yes we appreciate both chris and daniels moderation :)
  372. mrtnrln: Thanks Chris for keeping everything running orderly
  373. tarkus: suzaku: SC4D just went back up--we'll need to discuss it amongst the NAM Team.
  374. durfsurn: Even though im not NAM i could help?
  375. pagenotfound: why you so awesome :P
  376. tigerbuilder: Thanks everyone
  377. mrtnrln: durfsurn: The NAM is always open for help
  378. mrtnrln: If you can contribute something, we would be willing to take it ;)
  379. durfsurn: Will there be a "NAM Components" or similar seminar at any point? Like the development of FLUPS other crosslinking among others?
  380. durfsurn: As in seminar help.
  381. mrtnrln: You might get yourself into the NAM Team eventually this way...
  382. tarkus: I guess we're all headed to the post seminar room.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement