NAM Issues Thread - PLEASE POST YOUR NAM QUESTIONS AND PROBLEMS HERE

[mgb204]

Just to be sure I'm understanding you, are you e-mailing the files to yourself to get them onto the iPod Touch? If so, that's going to bring a lot of potential problems into view, because as I said, the file/folder structure can not be altered or this simply won't work.

Is there not a way to simply plug in the device to a computer, then drag/drop or copy/paste files between the two? This is how all Android phones work, they just appear like a memory stick would when connected to a computer. I'm not all that familiar with the inner workings of iOS, but it's seems unthinkable that you can't copy files to such a device.

@Andreas, unless I'm mistaken the Touch variant is like an iPhone without the phone, so should be suitable for web browsing, unlike the regular iPods.

[Tarkus]

I may see about just getting them uploaded and viewable on the web.

I believe I have found the issue APSMS mentioned as well, which seems to be with the "quicklinks.html" file in the /feature-guides folder.  That's corrected here now on my end--if there's any similar issues elsewhere, let me know.

-Alex

[Andreas]

@Andreas, unless I'm mistaken the Touch variant is like an iPhone without the phone, so should be suitable for web browsing, unlike the regular iPods.

That's correct, but unlike Android, there is no simple "drag & drop" between the computer and the iOS device. The only official method is using iTunes, which only allows media files and documents, but most likely no HTML content. Some third-party apps support importing and exporting data via a built-in web server (which you can access via your browser on the computer or a special desktop program when the devices are in the same network). Granted, uploading the NAM readme files to SC4D or some other webspace and providing a link would be the easiest way after all.

[Alan_Waters]

Great sorrow:



Can there be any fix?

[mgb204]

Not so much for the NAM issues thread, but more for the new features one... As has been stated, the 1st implementation of the ERRW was mostly designed to mimic the features of the original Viaduct rail, where no level 1 support existed whatsoever. No doubt, at some point in future there will be a further expansion of the L1 functionality, the biggest gap at the moment is suitable models needed to accomplish that.

The work around I'd probably use is to raise either side of the viaduct for rail by about 2m. Then you need to lower the area where the MHO goes under by 6m. Doing this will allow you to use the 15.5m L2 pieces without steep rail slopes to worry about and keeping things looking pretty realistic.

[Alan_Waters]

I solved this problem by transferring the MHW to the RHW near the bridge. It's just very sad that there are no many intersections in such a demanded route. And by the way, I would completely abandon the MHW, if not for the diagonals in the RHW, which are wider by half the cell, and look not very natural.

[mgb204]

I solved this problem by transferring the MHW to the RHW near the bridge. It's just very sad that there are no many intersections in such a demanded route.

But last I checked, there are still only 24 hours in each day and very few people to make the content everyone demands. There is only so much we can do, it will be expanded upon for sure.

And by the way, I would completely abandon the MHW, if not for the diagonals in the RHW, which are wider by half the cell, and look not very natural.

But if the RHW were narrower, wouldn't the lanes have to be unnaturally narrow as a byproduct? Similarly, the shared-tile diagonal system Maxis used reduces the capacity of networks where both directions are on the same tile, something we in the NAM team have done our best to avoid.

[Wiimeiser]

IIRC networks that aren't elevated by default can't be dragged across ground highway without creating a bridge and AFAIK this is hardcoded. Correct me if I'm wrong.

[mgb204]

No, it simply requires RUL code, models and paths to make it work.

[Kitsune]

out of curiosity .... regarding NWM diagonal intersections, is it the RUL's, pathing or models/textures that is the biggest chunk of work ?

[mgb204]

I've heard it said that the pathing is the hang up, because they will need to be very complex to accommodate some networks. Of course it's all relative, for me I look at the RUL and wince, it's certainly more complex with multi-tile networks than anything I'm comfortable with right now. Such pieces don't usually require models, it tends to be the non-flat networks where those are needed. Textures are no big deal, just a lot of work. But however you look at it, supporting just the base networks with basic support is 10's of hours of work combined, if not much more.

[APSMS]

I think it is important to remember that also with diagonals, every intersection possibility requires at least two implementations due to the way that diagonals on a tile system work in SC4. I think it might be more than that for the dual-tile networks, so there's a whole lot of bases to cover, and not a lot of time or team members that are able to handle that kind of work.

I'm certain every team member wants them to be done, but will is not the only factor here. Burnout is also a big issue and the NWM is a large thing to tackle, inevitably the best thing is to tackle it in stages but even then as stated it's a lot of work and not a lot of wow factor payoff, not to mention that unlike some systems, the NWM has perfectly usable base networks that serve just fine in a pinch, which I think is also part of the reason that they haven't been a greater priority compared to, say, some of the RHW networks/projects that have taken their place. A lot of the RHW codebase is RHWxRHW which, IIRC, simplifies the workload a bit anyways due to the copy-paste ability that I'm not sure is always possible when dealing with crosslinks between different networks (like RDxOWR, or RDxAve or RDxST), which would be essential to the success of diagonal intersection capability for any NWM variant.

So much to do and so little time!

I'm sure, if you're patient, it will be addressed but there's no telling how long that wait might be under current circumstances.

[Tarkus]

The little bit of work that has been done with NWM diagonal intersection support was done by jondor and myself during the NAM 30/NWM 2.0 cycle, and memo also weighed in on the future of it later on. 

The RULs, at least for +-intersections, aren't prohibitively difficult, no more than anything we did with the RHW, though the T-intersections are rather gnarly (especially multi-tile x multi-tile).  The textures can actually be produced through procedural generation (with a little touch-up), so they're also not a problem.  The pathing, however, is complex, and very time-consuming, and particularly in the case of the T-intersections, it actually has to be determined before RULing and even IID assignment can be done, due to oddities in how Maxis set up the base diagonal Ts (though going for the FTL "FLEX Intersection" paradigm might ease some of that burden). 

There are literally thousands (if not tens of thousands) of path files that would need to be created, however, each of which needs a couple dozen individual paths, in order to account for all the turning motions.  Once those are created, there would also need to be extensive testing to ensure that these paths work, particularly given their complexity, and the fact that, in some cases, path issues might actually require re-designing the RULs and IID scheme (which happened during the initial aborted phase of the project, when we discovered there was more asymmetry than we anticipated).  That's what has ultimately led to its shelving.

I'd definitely still like to see them done--it's kind of a "holy grail" as an NWM project co-founder, to have these networks more or less "complete"--but it's going to be a long road (pun fully intended) to get there.

-Alex

[eggman121]

Great sorrow:

Can there be any fix?

Already covered in NAM 36





The red arrows are to draw to and the white lines are where you stop the network. This works for most of the crossing for the ERRW. remember to plop blank rail pieces on the MHO to make the rail function. This can be done by placing the rail tool on the given network.

Not so much for the NAM issues thread, but more for the new features one... As has been stated, the 1st implementation of the ERRW was mostly designed to mimic the features of the original Viaduct rail, where no level 1 support existed whatsoever. No doubt, at some point in future there will be a further expansion of the L1 functionality, the biggest gap at the moment is suitable models needed to accomplish that.

The work around I'd probably use is to raise either side of the viaduct for rail by about 2m. Then you need to lower the area where the MHO goes under by 6m. Doing this will allow you to use the 15.5m L2 pieces without steep rail slopes to worry about and keeping things looking pretty realistic.

Thanks for the reply mgb204. I have most of the models from Vester that are still to be implemented.

I have been refactoring the ERRW especially the L1 variant by the way of given feedback. Here is the R2 curve with new geometry...



The new R2 curve no longer has the compounding Curve error that was introduced in the original design    . That meant that I had to redesign the R2 curve from scratch.

So I opened up Gmax (Yes I have scripts for exporting true 3d from Gmax to avoid the trap of max and its ever changing nature and prohibitive price tag) And made the models from a ortho and diag model I had on my HDD.

I have also been working on the R2 variants at L0 with the turnouts getting a makeover as well.

@Alan_Waters I could not see your pictures till now and had work so sorry for the late reply.

mgb204 Is totally correct by saying that the L2 has more functionality than the L1. The L1 should be easier to get into shape given the fact however that the L2 has most of the code that can be ported over.

L2 was always set out to duplicate the PP functionality. My view is that in time some content in the RRW/ Rail field can be relegated to legacy status once comparable and more functional equivalents arrive.

-eggman121

[Alan_Waters]

Thanks, eggman121, it worked out.



There is one more question:
Standard railway arrows work fine, but there are no smooth hands. Will this problem be solved, and for how long?

[mgb204]

Already covered in NAM 36

Ack, there goes my memory, I should have remembered the OxO crossing was there for L1, after all I remade the model (hence it has shadow). 

It's the other diagonal variants that don't exist for L1 right now, so sorry for the misinformation. It's hard to remember everything I'm doing sometimes!

[Wiimeiser]

Okay, so is it actually physically impossible to build rail in the middle of a highway because of the autoconnect issue, or what? I've found it's physically impossible to place ERRW height transitions, at any rate.

EDIT: Maybe not, but there definitely seems to be a correlation between elevated networks and this particular bug cropping up. You know, the one where the game decides for some reason to turn a rail between two RHWs into a ladder shaped mess. AFAIK it only seems to happen when the middle network is rail, can anyone confirm this? Maybe it's a RRW bug since RRW is technically an override...

EDIT2: Not sure, but maybe the way an override network is created somehow changes things.

[APSMS]

Maybe it's a RRW bug since RRW is technically an override...

EDIT2: Not sure, but maybe the way an override network is created somehow changes things.

I would have to look into what you are referring to specifically but in truth RRW is not an override network, because an override network is a network whose base has been overridden with starter technology. RRW is, instead, a rework of the Rail codebase that includes a reskin of the rail textures to boot.

The RHW consists mostly of overrides, and the NWM is entirely an override addon, but the RRW is a new way of how rail works and functions, so the issues stem mostly from the fact that everything has to be rewritten rather than the fact that it is an override; overrides will be inherently more unstable.

The STR addons to RRW are basically an override, and you can observe this in how they're less stable and have fewer supported intersections, but RRW itself isn't an override, or it would not work nearly as well as it does given all of the additional functionality that eggman121 has added onto it.

[Wiimeiser]

Actually, if I load Big City Tutorial the rail appears as default until I click on it with a network or the bulldozer, that's basically what I was talking about with the RRW being an override network.

Basically what's happening is if I put a Rail between two RHWs, under the right conditions autoconnect kicks in for the entire length of both RHWs and creates a sort of ladder effect. I've posted images some time ago. There appears to be more to it than just RHW and Rail in a specific pattern, there has to be a perpendicular update, but it appears it's more than just that. I don't know if it happens with other networks in the RHW median besides RRW.

[mgb204]

Actually, if I load Big City Tutorial the rail appears as default until I click on it with a network or the bulldozer, that's basically what I was talking about with the RRW being an override network.

But this is simply happening because RRW changes the way the textures are displayed. I.e. from a texture based to model based network. So in order to refresh existing sections, you need to click on them. This does not make it an override network which is a very specific term.

Basically what's happening is if I put a Rail between two RHWs, under the right conditions autoconnect kicks in for the entire length of both RHWs and creates a sort of ladder effect. I've posted images some time ago. There appears to be more to it than just RHW and Rail in a specific pattern, there has to be a perpendicular update, but it appears it's more than just that. I don't know if it happens with other networks in the RHW median besides RRW.

I totally get what you are saying, I understand how this could happen, but as much as anything it's a game limitation. If we removed auto connect (i.e. alter the RUL code to prevent it), such problems would go away. There was some work on that front, but it never got finished. In the meantime, build the rail last and try not to click on the RHW thereafter. Rail in the middle of highway is not hugely common, more frequently it follows a highway on either side.