3DS Max 7 vs 3DS Max 8 and beyond

[Karkadann]

What are the differences and is it worth upgrading.

[rustee]

New tools and features, and yes, definitely worth. If you compare v7 with 2011 or 2012 you'll find that the tools mostly used by gamedevs (EditPoly and UnwrapUVW modifiers namely) are greatly improved. I miss the Sweep modifier in v7, which I use instead of Loft in most cases.

[N. Sigismund]

Simply, Max 8 is a far better version of Max than Max 7. You've got Pelt Mapping for one, which is an invaluable tool for lazy texturing! BUT until Cyan upgrades their build system, you should keep a focus on Max 7 if you want so see your age on MOULa. Other fan shards are fine with whatever version.

[Lontahv]

Simply, Max 8 is a far better version of Max than Max 7. You've got Pelt Mapping for one, which is an invaluable tool for lazy texturing! BUT until Cyan upgrades their build system, you should keep a focus on Max 7 if you want so see your age on MOULa. Other fan shards are fine with whatever version.

According to the wiki the Cyan provided binaries work for Max 8 as well as Max 7.

[N. Sigismund]

Ah, that wasn't the point I'm making. Cyan's build machine uses Max 7, and their way of updating MOULa requires rebuilding the game every time they do an update. Fingers crossed that Cyan finally upgrade to a modern version if that tie-in game to the Myst Movie goes ahead. At this point, Max 7 is a *major* liability.

Personally, if I was not concerned with getting an age working on MOULa, I'd skip even Max 8 and go to Max 2012.

[rustee]

Seeing how buggy 2011 is I wouldn't be so optimistic about 2012 :\

[Lontahv]

Ah, that wasn't the point I'm making. Cyan's build machine uses Max 7, and their way of updating MOULa requires rebuilding the game every time they do an update. Fingers crossed that Cyan finally upgrade to a modern version if that tie-in game to the Myst Movie goes ahead. At this point, Max 7 is a *major* liability.

Personally, if I was not concerned with getting an age working on MOULa, I'd skip even Max 8 and go to Max 2012.

I never read or was informed that we already had a pipeline for fan-created content planned out for MOULa. Server projects in the past and present have shown and are showing us that all that is needed to add extra content is a little uploading of Plasma files and running of a manifest-updating script.

[andylegate]

Ah, that wasn't the point I'm making. Cyan's build machine uses Max 7, and their way of updating MOULa requires rebuilding the game every time they do an update. Fingers crossed that Cyan finally upgrade to a modern version if that tie-in game to the Myst Movie goes ahead. At this point, Max 7 is a *major* liability.

Personally, if I was not concerned with getting an age working on MOULa, I'd skip even Max 8 and go to Max 2012.

I never read or was informed that we already had a pipeline for fan-created content planned out for MOULa. Server projects in the past and present have shown and are showing us that all that is needed to add extra content is a little uploading of Plasma files and running of a manifest-updating script.

More than likely the setting up of the GoW shard you will be able to "slip" age files in just fine, as has been done with all the Alcugs shards (pretty much proof in the pudding so to speak).

This can also be done with a MOUL:a type of server just fine too. The problem comes in, when the server must had a rebuild done to include any "fixes" to the existing content (like the last couple of rebuilds that have been done with MOUL:a to include all the wonderful fixes that you all have worked on and submitted to Cyan), once the rebuild has been completed, content that was "slipped" in will be lost and has to be "slipped" in again, where as if the build machine has the actual Max file for the new content, along with it's resources, the rebuild will include the new content (IE nothing new is lost).

"Slipping" the new content back in is not a problem if you are talking about a handful of stuff. But what happens down the road when you have 15 new Ages? 20? 60? You get the picture. It goes from a simple rebuild to a big headache.

Mark (aka Chogon) tried using one of my Max 8 files with their build machine to set up a MOUL:a type of server for a non-MOUL / Uru project that Cyan is partners with us on (it's something that Cyan is working with other companies that is not for public consumption, but is for the educational community is all I'm allowed to say at this time), and the Build Machine got very upset. I had to go back and give him the Max 7 version in order for the Build Machine to do it's job.

More than likely, this can be changed and updated so that the Build Machine will accept Max versions other than 7.0 (I have no doubt the talent here and else where can most likely whip something up quickly, and hope so, as Max 8 works a LOT better on my Windows 7 machine than Max 7 does), however, until that can be changed, it means the Build Machine that Cyan uses is limited to Max 7.0 versions at this time.

Another complication with the "pipeline" to submit and include Fan Content on MOUL:a itself is problems with their Asset Manager. As per Mark:

[05/26/2011 3:52:38 PM] Mark DeForest: The thing I need to do is modify the build machine scripts so that all the assets don't have to be in assetman - which makes it hard to add lots of assets, in particular any texture with the same name. But what I need to do is allow the assets to be retrieved from a directory - but with that I would also need to have a meta data format so it knows how to build it.
[05/26/2011 3:54:03 PM] Mark DeForest: We cheated on the XXXXXXXXXX* by using assetman and the current build system - only because there is just one age - and luckly none of your texture names have clashed with the existing tectures - mostly becuase you use *.png where as the Cyan artists use *.tga or *.jpg
[05/26/2011 3:57:55 PM] Mark DeForest: But like I have said before, I would like to solve fan created assets importing into MOULa as a whole instead - but that might be too much wishful thinking. lol
It is not that MOULa is so restrictive but that all the build systems realiy too heavly on a respositiory system that is kinda weak - something we should have changed a long time ago.

* X's inserted by me to protect the project's name at this time.

Working with Mark on this project I'm on, I have learned alot about how they (Cyan) thinks about their server and how they like to do things. I've also noticed 2 completely different thoughts about adding content to servers:

Cyans: Original Max files needed for a rebuild to add the content.
GoW: Plasma files can be just added to the server.

I know for a fact that both are true, and both will work. It's just a matter of how one group does business is all.

So I'm pretty sure, having come to know many of you here over the years, that a lot of what Mark is talking about may be something you all could help with and Fix / Change / come up with a solution for not only getting the Build Machine to accept different Max versions, but the problems with the Asset Manager too.

I would much rather build in Max 8 than using 7 like I am now.

[Lontahv]

Andy, thank you for the information about Cyan's internal workings, you gave me an understanding of the current (and non-flexible) system used for the internal game pipeline. My point was that user created content is NOT part of the game, should never be considered internal assets. Although Cyan spends 4 hours or more every time they create a new build, they really don't have to. The prp format is changed every... probably every 100 commits (that many builds). However, this is their pipeline, and that's perfectly okay. However, their internal system is not the only possible way to get fan-created ages to the fans. PyPRP2 and PlasmaMax have both shown that there are other methods of exporting ages to MOUL than through the re-export-every-build-method. Of course the fan ages will need to be updated some time down the road. However, any change to the format will be small and a tool can be built to convert the prps. The change may even just be like changing UntilUru prps to CompleteChronicle prps: you only need to change a few bytes at the start of the file. External developers depending on internal infrastructure will only cause problems for Cyan and the fans down the road. When you're personally working on a project with Cyan there is bound to be some bias toward the internal system, however, from an external view, the pipeline definitely needs work.

[andylegate]

Actually, and this I can freely talk about, I have my own personal pipeline, which consists of me sending any changes I make to the Max file, the textures, sound files, python files, and sdl file to Mark, and he does a rebuild, heheheh.

Actually, I can make changes and test them on our server, by using a special Internal Client that uses a /localdata switch in the command line. That way I can test changes I've made without Mark having to do a rebuild.

But there is a limitation to that: SDL file. I can't make changes to it and see them with the Internal Client. I have to wait until Mark does a rebuild and updates the SDL file I send him (which is actually a raw text file since MOUL uses a different format for SDL than the one POTS used).

However, the cool thing about that (and what Fans will need to do using any Fan made test server) is "Plan Ahead". I send a updated SDL file to Mark, with lines in it for "future" use, that way I can test changes later down the road, without having to bug him for a rebuild on our server.

There are some issues about doing a straight conversion like you are talking about (just converting the prp files):

Colliders: we discovered (and Mark warned me about this) that a lot of colliders that seemed to work just fine on a POTS type setup or Alcugs shard, misbehaved on the MOUL server Cyan set up for us (we tested things on the actual MOUL:a server first, then the company that is sponsering this paid Cyan to set up our own actual physical server that our project runs on).
I found doorways blocked suddenly. Walls that I could suddenly walk through, etc.

Turns out PhysX is less forgiving than Havok. I had to go in and change the shape or geometry of some of the colliders, in order to get them to work correctly.

Sound files. Seems as though POTS doesn't mind just having a .ogg file, and in just about any format.
MOUL on the other hand is a bit picky about that. In many cases, it wants a .wav file too (and not because it's a non-spatial sound, or has to be streamed). We found that many of our home-grown sound effects were not working until I made .wav versions of them and Mark added those to the server. We also had issues of the home made sound files not liking this format:

44 Khz, 16 bit Stereo. or 44 Khz, 32 Bit Float Stereo.

Instead, it wanted the home made files to be 44 Khz, 16 bit Mono.
Mark is still trying to figure that one out.

Another thing we noticed (and have not figured out yet). Let's say there is an elevator, and you have the elevator sound emitter parented to the Sub World Dummy. If you are on the bottom floor, and the elevator is several floors above you, when you call the elevator down, as it get's in range of the player, the sound of the elevator should fade in.
Instead, what has been happening is the elevator sound doesn't actually start until the emitter gets within range of the player (causing a delay when you have your responders waiting on the sound to finish before the elevator doors open up).
We thing there is something set wrong, but neither of us have had time to work on it (Mark is in the middle of doing an update to Stoneship right now).

So I'm hoping you guys can do a straight conversion, that would be wonderful. But there might be some issues with some Ages with the stuff I just listed above.

Of course I do wonder sometimes if some of our problems are due to the changes Mark had to make to the server (most of it is UI stuff, it no longer says MOUL anywhere, but uses the project's name. We had to take out a lot of the clothing, and put our own clothing in place. The Relto book is disabled, oh you can call it up, but it doesn't do anything, heh. Panic linking puts you right back at the begining of our "Age", the KI is automatically dispensed to the player when they log on (as all the Uru and MOUL ages have been removed), but it has been changed too).

I do hope you guys get your server going soon. There is nothing like seeing your Age in widescreen format, with the same high resolution. It, wow, it really makes a huge difference!