• Moose

Tarkus

Member
  • Content Count

    3,060
  • Joined

  • Last Visited

  • Most Liked  

    11

About Tarkus

  • Rank
    Corporate Climber
  • Birthday 10/15/1985

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    Oregon

Recent Profile Visitors

197,360 Profile Views
  1. It's also possible there's some sort of load order issue involved. The RRW does change the IIDs of the base Rail network, but not intersections or puzzle pieces. If the RRW wasn't in your Plugins folder, you'd probably be seeing blank stretches on either side of the puzzle piece. My suspicion is that one of the alternate versions of the Maxis Rail textures (either the SFBT set or the dedgren set) is lodged in there some how, and is loading after the RRW textures. Take a look for either SFBT_Rail Textures Mod_Darker Textures.dat or zzz_Dual_Rail_Texture_NAM_Upgrade.dat in your Plugins folder (probably in z___NAM somewhere). There have been some installer and file architecture-related issues with efforts to prevent folks from ending up with both RRW and non-RRW components not working as intended, so it's certainly possible something like that could have happened. We've had to keep the RRW as a non-default for the past few releases due to complaints. Initially, they were somewhat justified, as the version that shipped with NAM 32 was rough, but now, it's mostly subjective complaints about its color scheme. Given that it's actually the only rail standard we're developing now, and the RRW texture customization efforts are mostly in place (thereby satisfying those previously concerned with its aesthetics), it may be that we make it default for NAM 36. By the way, in case anyone is wondering what's happening with NAM 36, it's been in internal testing since mid-May. That testing has actually been going very smoothly, but heavy batches of RL for a few of us since then have been torpedoing our ability to finish the last few things. Additionally, I'm in the process of completely re-writing almost all of the documentation. We're ditching the PDFs, as they proved to be functionally impossible to maintain (as evidenced by the severe lack of documentation updates since 2013), and we're going back to a more modern version of the old HTML approach we used up through NAM 30. -Tarkus
  2. As custom regions and plugins aren't default equipment for the game, the process of re-installation should not affect them. If you've done anything to the default regions that come with the game (Berlin, Fairview, London, New York, San Francisco, and Timbuktu) that you'd like to save, however, you'd want to back those up, as the re-install will put clean copies of those into the Regions folder, overwriting the existing ones. In any case, it would not hurt to use this as an opportunity to back up all your regions and plugins, particularly if you're attached to them. I'd just go in and select the Plugins and Regions folders in the My Documents\SimCity 4 folder, right click and hit "Copy", find a suitable location, right click and hit "Paste". If you're going from a disc copy, if you know which files were causing the patcher to hang up, you can alternatively just copy the original files off the discs into the game's directory, and this should suffice (speaking from experience). -Tarkus
  3. They're simply supposed to be a more rural-looking version of the Road network--no sidewalks, and (at least the appearance of) passing permitted. They're basically Road Cosmetic Pieces. The NAM doesn't change the actual drive side and never has. The NAM's installer reads the registry, and picks the appropriate box based upon that. There are boxes for "RHD" and "LHD" on there, but generally, users should not be messing with them, as all you'll end up with is the same drive side and a borked NAM installation. The only time someone should check a different box on the drive side is if they changed their drive side through a Locale swap and a shortcut command line, using smoncrie's trick, instead of through the registry, as the NAM installer cannot detect that sort of change. If you're looking for dirt roads, you should check out the Street Addon Mod. There's multiple options there. -Tarkus
  4. Thanks, Cathy--looks like there was at least one (Battlecat) that hadn't gotten the image link switched over to the on-site folders. Unfortunately, it's also wiped out a few folks' avatars, however, as they were using off-site hosting for theirs on Photobucket. Indeed, for pretty much anyone out there who gets into transit modding, NAM Team membership is the pinnacle. It's a sign you have skills to be useful to the biggest mod in the SC4 world. I still remember how elated I was a little over 10 years ago, when I was brought onto the team. The MODPACCs, being a newer invention, might not have quite the same level of tradition associated with them as the NAM, but being included would, IMHO, be a certain sign that one's creations are valued enough to be part of a curated "taster" to get users acclimated into the world custom content. -Tarkus
  5. The NAM is actually a really interesting case, as it is a product of the game's file architecture. Each of the RUL files that tell the game how to construct transportation networks has a specific function, and only one copy of each RUL can be loaded into memory by the game. As a result, the only real way to ensure cross-compatibility with all mods that involve RUL modification is to assemble all third-party RUL additions and edits are assembled in a single, unified source. It has essentially required all of us who modify RUL files to work together. That's certainly come with its own set of challenges, but it's something that everyone (well, just about) in the transit modding community has agreed was necessary for the greater good. Functional airports and seaports have a similar restriction, in that there's a single exemplar file for each that defines all the allowable ports. The former Aerospace Consortium (AC Team) handled the airports--the seaports, however, were the victim of political wrangling, so there's two conflicting controllers out there. The API for the LEX is REST-based, so it sounds like there's already a window there for compatibility. It's also open-source, so ST is welcome to use it. Getting to simmaster07's idea, there's even a Python wrapper for it already. I'm in the same boat with you on all the technical details, so I'm going to see if I can alert Casper to this. Indeed, if we're going off APIs and the like, ModDB isn't going to work. It's just a place to upload mod files (very large ones, even). The way the NAM Team uses it is as an extra point of redundancy in our official distribution network, to ensure the mod remains available, in cases where SC4D and/or ST may be down and/or needing to conserve bandwidth. If we are going with pre-assembled packs, and as long as we're not all-in with it (like many were with Photobucket--SC4D actually had been hosting CML images there ), it can be a useful tool, as long as one is aware of its limitations. -Tarkus
  6. As of right now, because the NAM Team's FTP account for ST has been down since sometime before the release of NAM 35, the NAM downloads here on the STEX actually point over to ModDB, and ModDB is presently beating SC4D by a 4:1 ratio. The STEX pages are getting a lot of clicks, however (the GOG article likely helped a lot), but I don't really have reliable stats on them due to the situation. That's also obviously skewed by the current logistics, however, and my older stats do support your theory. I do have my figures for NAM 33 and 34 handy, both of which were releases where the NAM was directly hosted on the STEX. Both ST and SC4D beat out ModDB in terms of their share of overall downloads--ST by a wide margin, SC4D by a slight one. With NAM 34, the market share three months after release broke down to 60% ST, 25% SC4D, 15% ModDB. With NAM 33 (which only lasted a month as the "current" NAM release), it was 56% ST, 24% SC4D, 20% ModDB. One positive with ModDB is that the mainstream gaming media does actually browse around there, and the NAM's presence on there did actually start getting them to pay some attention to the SC4 community in late 2013. Rock, Paper, Shotgun picked up the NAM 32 Pre-Release, and then the full release of NAM 32 ended up being PC Gamer's "Mod of the Week"--both outlets mentioned and linked to SC4D in the process. While the gaming media had kind of been forgetting we exist since C:S was released, and became a bit of a darling for them, we are starting to get on the radar again, evidenced by this Kotaku article from earlier this week. The NAM usually goes straight to #1 on ModDB whenever there is any sort of press about it outside the usual SC4 community outlets . . . I'd imagine the creation of these MODPACCs would be pretty big news, even now, and if we can leverage it the right way, we might be able to parlay that into increased traffic here. I'm also in agreement that we need some sort of a build put together first. A rolling release of different types of packs might also be a good way to sustain interest in the project over time. That's certainly a possibility--links all over, at the very least. I think we can use this as a gateway, if we set it up right. The webpage and zip-packed file is obviously going to be easier to keep around. @simmaster07 actually designed a pretty awesome PHP-based online NAM installer back in the NAM 29 era . . . sadly, however, it's not around anymore, as he didn't have a permanent place to host it. I'd also agree that the existence of the MODPACCs and a client aren't mutually exclusive . . . arguably, they're both solutions we need. The MODPACCs can be for an entry point, and the client can be for when we get them hooked on SC4 custom content. Another comparison would be the RHW ramp interfaces. We have two newer overrideable implementations of them, the draggable versions (DRIs) and the FLEX piece versions (FLEXRamps). We intentionally maintain both . . . some users prefer not having to reach for the menu, but others don't want to memorize the drag patterns, and prefer to just plop the FLEX pieces down. Sometimes, it's necessary to have different points of access. -Tarkus
  7. Regarding SC4D, we have a way of putting the brakes on bandwidth consumption built right into our exchange software, thanks to @CasperVg. There's a daily cap, and there are different tiers of it--there's one for regular users, as well as one for donors (which is about triple the regular user cap). That would be our mechanism for keeping people from being gluttonous at jeronij's expense. We can adjust the caps if it appears there's a need to do so. If, on the ST side, things are being directly downloaded from the STEX, there's obviously the AdFly routine in place already, to recoup some costs. Now, if we start going to a user-side client, it depends in large part on how exactly it is going to be accessing the files on the exchanges, if it'll be automatically registering an account to use the tool on the exchanges, or if it'll take in the user's existing accounts and work that way. The LEX should automatically still cap things that way (there already is a LEX Downloader tool out there--wouanagaine did the first edition, Casper made the newer Java version), and while I don't know all the mechanics of the current STEX setup, I'm not aware of there being any sort of quota on how much registered users can download from here during a certain timeframe. We could, in theory, code a cap on STEX bandwidth usage into such a tool if needed, which could somehow be upped for donors, by providing them with a validation code of some sort once they donate to ST. Going back to the model of packs on the exchanges, there's also the question of whether or not packs like this would actually increase bandwidth usage. As far as how bandwidth would be counted by a webhost, it's my understanding that there'd be no difference between someone "binge downloading" 2GB of plugins in the current setup, and someone downloading 2GB of MODPACCs. 2GB is 2GB. The effect on the server may end up being different, downloading 300 small files versus 5 much larger files, but it would make no difference on the actual bandwidth meter. Granted, though, I'd imagine there would probably be a "rush" on the MODPACCs when they first go live, similar to what one would expect when a new NAM version is released. The first "monolithic" NAM (NAM 31.0 in March 2013) did put a bit of a run on SC4D's bandwidth. That initial rush, however, does level off and plateau, and given that there's not likely to be regular updates to the MODPACCs like there is with the NAM, that wouldn't be a recurring pattern (unless there's an article in the gaming press that causes a sudden, brief surge). There is also the ModDB route--that'd mitigate bandwidth concerns, but it would potentially cut the traffic to the SC4 sites and exposure for potential donations. -Tarkus
  8. We have been discussing this a little bit on one of our senior staff boards at SC4D, and vortext, one of our Global Moderators, suggested offering the packs with a prompt for an optional donation (minimum of $0)--basically, the Radiohead In Rainbows model. While the MODPACCs (yes, I'm all in on that acronym) certainly don't need to be all-inclusive--that's beyond the scope--I would think that dependencies would need to be included, as the idea here--at least as I understand it--is to lower the barrier to entry, and beat the seedy underbelly types at their own game. The way we do that is with self-contained, plug-and-play sets that, unlike theirs, are above the board, clean, and tested. The use of a set folder structure will prevent duplicates from being installed, though it wouldn't inherently stop some redundancy in the packages themselves in their initially downloaded form. If that redundancy deemed to be sufficiently undesirable, there is the option of creating a single, combined dependency, containing all the ones shared in common between the different packs. I don't think a single dependency would be a bridge that the potential userbase of the MODPACCs would be unwilling to cross. As this is all in the stage of hypotheticals still, we'd probably actually have to produce some internal prototypes in order to really determine the best way forward. Additionally, I think this thread is worth discussing in this context. Of course, if server-side dependency tracker coverage expands, or the client-side scripting ideas that have recently been discussed take off, we may be looking at something else entirely at that point. -Tarkus
  9. NAM 37 will be right up your alley. The new FlexSPUIs will actually be interfaced with the upcoming FLEX Turn Lanes, providing several new configurations in terms of the number of through and turn lanes. Here's a taste: -Tarkus
  10. On the LEX side, there's a lot of support for doing this sort of thing, from both staff and the creators I've heard from. I think if there's a reciprocal arrangement in place with the distribution--the packs go on both STEX and LEX (and maybe ModDB, for the sake of additional bandwidth/access)--and proper credit is given, I don't see how any rational person could argue that it is not in good faith. In this era of the community--not that I expect ST or SC4D to go anywhere--having the redundancy in distribution is a no-brainer, anyway. The idea of doing this under the auspices of some sort of custodial account, as @T Wrecks suggested, is also a sound idea--probably named something that describes the goals of the consortium behind the account, and, in true SC4 community spirit, something that would create a memorable acronym. This is the other side to the equation, and similar to an idea I've floated a number of times in the past. The LEX Dependency Tracker is already a model of this sort of thing--it was @CasperVg's phenomenal idea--but it's presently restricted to just the LEX. If such a system were to be extended to the STEX, and subsequently crosslinked with the LEX's tracker, it would indeed solve a lot of these problems. There'd be no need to even worry about permissions, as the files would be downloaded from their initial sources (though we'd probably still need to do some repackaging to minimize installer fatigue). Casper did make his API open source and put it up on GitHub, and while he has been pretty busy with RL, I do know he would be interested in seeing his invention propagate further, into a cross-site solution. The account linking issue is a tricky one, and letting unregistered users download without some sort of cap or means of recouping revenue is going to run up a ton of bandwidth. The SC4D Staff did discuss the prospect of allowing unregistered users to download after it was allowed on the STEX, but the bandwidth concerns nixed it. There's also the matter of software. SC4D relies entirely on free and/or open-source software--SMF for the forums, and the custom LEX software for the download side, which are also on completely separate databases. ST, however, uses IP.Board and quite a few other proprietary software packages in its current form, and I do know the idea of having everything integrated directly in with the same database is a priority here. You'd probably need the benevolent @Dirktator himself to answer the question as to whether or not it would be feasible to integrate something like Casper's system with the software ecosystem here at Simtropolis. -Tarkus
  11. Speaking as the person who jeronij has more or less left in charge of the daily operations of SC4 Devotion over the past few years, and one of the people who helped draft up the current version of the SC4 Devotion Site Rules back in 2012, the rule includes what you've described, but that was simply one part of it. It was also largely aimed at the folks in the "seedy underbelly", who, off ST/SC4D, decided to take matters into their own hands, without concern for the original creators, and released unauthorized, uncredited "modpacks" or plugin folder dumps, often through channels used for piracy. The rule was essentially a codification of this 2007 post by RippleJet, and also inspired by the Dirk/Will Wright accord. We have indeed terminated the memberships of people who have violated it, though termination was dropped down to a short suspension if the distributor apologized and/or at least attempted to remove access (hard to do if they chose to use a torrent, because of the nature of "seeding"). What we're talking about here is a repackaging that is being done above board, and with a lot of public discussion and forethought being done before jumping into it--things the seedy underbelly doesn't care to do. It's always been my view that the sites, which are held to a higher standard and are more likely to follow due process, are the ones that should be managing this sort of thing, keeping it from devolving into a free-for-all. If we don't do it in short order, though, I fear we may lose the window. The main things that have prevented this sort of initiative happening before now are infrastructure, strict interpretation of community policies, and politics. We've come to a time when I think just about everyone is past the politics--even those who were around for the messy years--and the strict interpretation of policy was, at least in part, a product of those politics. There may still be a couple isolated permission landmines we'd have to dodge, but I think, by and large, we're at a point where we can work through that and come to a sensible balance. The infrastructure side of things has had a lot bigger impact on the SC4 world than many realize. File size is one area particularly affected--there's only five files larger than 25MB that I can think of in the community--two are the Windows and Mac versions of the NAM (260MB for Windows, 428MB for Mac), and the others are Gobias' Berner Oberland Terrain (64MB) and Sudden Valley Texture Pack A (56MB), and Lowkee33's LK Terrain Textures 01 (57MB). I suspect the number of files larger than 10MB would actually be surprisingly short, too. This is ultimately a vestigial remnant of long-time limits on file size on both the STEX and LEX, both of which were pegged to a mere 10MB for quite some time, unless you got approval and had someone around to FTP it onto the site (which, in the case of ST back then, required Dirk personally). It's hard to believe now, but a lot of people still had dial-up internet when we started, which, if you were lucky, could get up to about 0.05Mbps. Bandwidth was also a lot more expensive. The packaging we've been left with was certainly shaped by this, producing the small, compartmentalized downloads we have now. -Tarkus
  12. That's the RealRailway (RRW) option.
  13. Knowing the intricacies of the old, absurd community politics, I have to admit I'm a little amused at the concept of a Pegasus file requiring a CSX dependency. Getting to the matter at hand, the biggest issues with "cherry picking" are the labor involved in that kind of repackaging (a lot of "surgery" in the Reader), and the aspect of documenting just what has been plucked out of the larger dependency, particularly in the case of users who might later end up downloading the full dependency file. One would probably have to get down to cataloging full TGI addresses in order to communicate this, and that's not going to be intelligible to people who are not well-versed in the technical side of SC4. It may introduce some inefficiencies in terms of disk space, but given increasing power and storage with computers over time, and the fact labor is a precious resource with repackaging efforts (particularly nowadays in the SC4 world), I think prioritizing conservation of the latter over the former would give such an initiative more of a chance of getting off the ground. If there's concern about duplicate files being loaded, I agree with T Wrecks that such a concern still exists within a model where dependencies have been divided. Using a set, default folder structure would be the best way to ensure that duplicates are not created in the Plugins folder. If we are in fact talking about creating these sorts of packs in the model of the NAM, or of the Morrowind Overhaul that jaredh mentioned, an installer may be warranted, as that's a viable way to easily enforce a folder structure. The biggest issue with installers at present is navigating a glut of them when going on a "binge download" spree (on the order of hundreds, in some cases). Considering that most anti-installer types are okay with installers being used for larger, multi-option downloads like the NAM, I think users would be okay with navigating a small number of them, particularly if there's significant payoff at the end. If there are advanced users who don't like the particular folder structure chosen, there's nothing stopping them from doing what they already do, and reorganizing it to fit their needs. Of course, should cross-site dependency tracking come to fruition, we'd could simply pass file lists through that system, and aside from simply replacing the installers for small stuff with plain .zips, repackaging would be almost entirely unnecessary. Fortunately, in the case of girafe, he's still quite active (and is a staff colleague of mine at SC4D). It's easy enough just to ask. With older content, it can be trickier, as the original creator often is not around, so you get into the question of whether or not the exchange is effectively the guardian of the files in absentia. That's been the crux of a lot of these accessibility matters of late, and one of the real questions we need to answer decisively. I think it would be instructive to look at the manner in which content was brought into the fold for the STEX Collections and the LEX DVD. The SC4D Staff is effectively the custodian of a lot of the older files hosted on the LEX--including many major dependencies--and there have been some inactive LEX uploaders who have reappeared and explicitly affirmed that their files are in our care. Speaking as part of SC4D Staff, we share a lot of the same concerns with file accessibility--both literal and functional--and we are interested in potentially collaborating and pooling resources as part of these efforts. We want to see a comprehensive solution that benefits the whole community. -Tarkus
  14. This, to me, sounds like it could be the most workable solution, and one that could definitely help users getting up and running easier with certain styles of building and playing the game--for instance, a plugins set designed for building Paris-style cities, one for building US-style suburbia, and so on. It wouldn't be feasible, of course, to have them include absolutely everything in those genres, but we could certainly give the users a sizable assortment to whet their appetite, and use the packs as a launching pad toward further exploration of the exchanges. It is, most likely, going to require some repackaging of existing content to ensure quality and ease-of-use, particularly when we start getting to the matter of dealing with cross-site dependencies, which are very commonplace with many popular files. -Tarkus
  15. My understanding from the context of Haljackey's post is that the NAM's installer would be included as part of the download (and the pack would be updated when the NAM was), or there'd be some other sort of linked setup (which we could actually do right now with the LEX over at SC4D). Including a pre-installed NAM, aside from perhaps a very basic install, would be problematic for all the reasons you indicated. Our biggest concern on the NAM Team is always technical support liability. -Tarkus