I'm posting this as a response to the latest patch (9/7/2010) and the Fast Lane Stuff release.

When working with my Custom Launcher (see my sig.), I've noticed that there are several mods out there that are using script resources. (0x073FAA07 Resources) This is a GOOD THING, we like new stuff!

Some of these are using the new (Ambitions style) V2 script resource while others are still using the V1 resource.

I'd like to take this opportunity to offer some advice on when to use each type of script resource as a way to help avoid seeing the box pop up warning you about version mismatches.

So, here is my advice: ( IMHO, if you disagree, please feel free to comment!)

Use V1 resources for any script that is for an object or a menu injection or behavior injection. For example, (almost) all of the NRaas tools are using V1 script resources and the same exact version works both pre- and post-patch. I think everyone will agree that these mods do some really complicated things.

Use V2 resources for core mods and any other scripts that rely heavily on or replace the GameplaySystems, GameplayObjects, SimIFace, etc. To clarify, you should probably only use V2 resources if the original script resource was a V2 or if you tie deeply into a V2 resource.

Note: I'm not posting this as any sort of negative comment, just simply to help people understand when (again IMHO) to use each version of the script resource.

Oh, that may explain why my ScriptError core-mod always displays that message.

Not that I'm complaining, I actually like to know when a custom Core is installed or not.

----

As for why I use V1 in my own mods : I simply forgot about it actually.

And since I create new mods by copying the package of an existing one, the V1 status has simply propagated forward.

* makes a note to look into changing that *

Thanks.

Since your mods don't tie directly into the core, I would suggest keeping the v1 version numbers... Except for the ScriptError mod, of course.

All my scripting mods explicitly reference the Core... They must do so in order to actually do anything to the game.

That is why EA Patches will occasionally break my mods :

If they change a field or function that I rely on, the mod will no longer link properly and the game will halt on start-up.

----

Since the Core is mostly stored as V2, then by the logic in your original post, all my scripting mods should also be V2.

Mind you, the versioning is irrelevant to me anyways, as I don't maintain backwards compatibility prior to the last major revision (The Ambitions Patch in this case).

So if I change all my packages to V2 on a go-forward basis, no one will even notice.

Ok. I see where you are coming from.... Your mods are sort-of in the borderline between being core and being regular script mods and it is definitely your decision in any case. Plus, since you update quite regularly, the updated version numbering on the resource isn't a big deal.

My main focus on this topic is there are a few cases where objects like a rug or a chair had script resources that were built using a V2 resource and therefore will require repackaging for each new patch, probably without any change in the actual script.

BTW... These mods were downloaded elsewhere (and I won't be naming names in any case), so it isn't like I'm picking on the creators here at MTS.

Oh, I get it...

Is there something in the Version 2 package header that explicitly ties the package to a particular Patch level ?

Is this value something that must be manually set when the package is updated ?

Exactly, Part of the V2 resource is the version number of the core script resources... Look at /program files/electronic arts/the sims 3/game/bin/code_version.txt

For the latest patch, it should read like this Where 0.RL-2.0.113 is the version of the core. The previous version was 0.RL-2.0.104 from Ambitions.

In the V2 resource, you remove the RL- part and have 0.2.0.113 as the V2 Version.

Well that explains the message I receive from using ScriptError, perfectly.

As for non-core mods, I finally understand what you were getting at in the original post.

I gather then that the package version number must match the user's Patch level explicitly.

If that is the case, it makes perfect sense to remain at V1, rather than convert to a more restrictive package format... At least until such time as EA discontinues the V1 format.

@granthes: I kind of miss the reasons for your advice. Right now, you're just saying how we should do it, but not why. I can explain why I won't follow your advice, though.

Like twallan I only support one code version (except for patch-independent VanishingScripts which I loathe), and I only use this code version's libraries to write my code. To actually find out if any given code accesses stuff that got severely changed in the past, I would have to look at outdated game code and compare it to the current game code. I don't do that, because I don't see the point and simply don't care.

For me V2 resources are a way to stop folks with outdated game versions (as in pre-Ambitions) from using my mods. A lot of downloaders are too lazy to completely read an upload posting, so that's a bit of a safeguard. And to be honest: I'm still not completely aware how the nag screen is supposed to work. Personally, I have only seen it for core mods, but I have seen users reporting to see it for standalone scripts and object mods as well. They probably just mistook the "Mod Scripts Found" notification for the nag screen, but there's no way to be sure.

Additionally, I use the version header to have a reminder whether I checked a script for compatibility issues after a patch.

For your custom launcher you made the decision to take the version header very seriously if it is a V2 resource and completely ignore V1 resources. It could just as well be reasoned that the existance of a V1 resource is a dead-certain indicator for an outdated script, or at least more certain than 0.2.0.113 vs. 0.2.0.110 in a V2 resource.

In the end, that's all just personal flavor IMHO. V1/V2 means crud when it comes to non-EAxian scripts. I decided to go with the EAxian shtick and indicate the supported code version by using V2 resources; others keep using V1 resources. There's just no way to tell from the outside whether a script is compatible or not.

BTW: That is simply not true. Incompatible standalone scripts will usually cause the game to stall on loading a world, "usually" as in "probably always".

And here I thought you were aware of that and that this was somehow intentional. Changing the version header is always the first thing I do when I download your ScriptError mod. I don't mind having an indicator for core mods, but I find it annoying that the nag screen minimizes the game and interrupts loading the game.

Ok. Either I'm misunderstanding you, or you misunderstood me.

First, it seems like you are arguing both ends of the question against the middle. For example, you state that you use V2 resources to force the version testing, then you state that a version mismatch will only cause a stall on loading. Doesn't this still keep the game from playing? Hence Crash?

Second, the "EAxian Shtick" didn't change all scripts to V2, only Core Scripts, so I don't see why this justifies using V2 for everything...

Finally, this has nothing to do with how seriously my Custom Launcher takes the version numbers. That is just the vehicle that helped me discover this little bit of information.

I appreciate your input, but am confused by what you are attempting to say; and I am in no way trying to force you to follow any particular method with your scripts.

It minimizes the game ? I run it in windowed mode, so I've never noticed. I can see that would be very annoying.

Now that I understand what causes the message, I've see about setting that core-mod up properly from now on.

I didn't state anything like that. A pre-Ambitions-patch game is incapable to load V2 resources and will simply omit them. That's what I'm "exploiting".

Again, I stated nothing like that. If the code of a custom script is actually incompatible with the game code, e.g. trying to access the setter of the FamilyFunds property which doesn't exist anymore since the Ambitions patch, it will cause the game to stall. That has nothing to do with a version mismatch and is a completely different thing than a crash. You can have stuff like that in a V2 resource just as well as in a V1 resource. As I said: The version tells you crud about the actual compatibility.

All EAxian scripts are core scripts. The framework assemblies don't count as they aren't EAxian.

ETA:What are you talking about? How are you supposed to write a script for TS3 that actually does anything without referencing the core?

Ok. This is the basis of the confusion....

Core Mods REPLACE the core. These are the V2 resources.

Other mods REFERENCE the core. These can be V1 or V2 as preferred by the mod creator.

This is the ONLY DISTINCTION that I am looking at here!

I apologize to everyone if I was less than clear.

The difference between core mods and non-core mods is quite obvious. It's a binary, non-continuous thing, not confusing at all. Yet you came up with a borderline between them. That might be considered confusing.

Let's restart: Do you still stand by your advice in the first post? If so, what is the reasoning behind that advice?

I absolutely stand by my advice in the first post.

Here is why:
1) Core mods are something that are tied VERY EXPLICITLY to the version of the game engine itself. These should use V2 resources to tie themselves to the error detection "Nag Screen" behaviour of the game. Since every new major patch will change the game engine, using a non-matching version of a mod would almost certainly result in errors, crashes, data-loss, etc.

2) Object mods that happen to have scripts in them should NOT use V2 resources. The interface specification for the functionality provided for objects in the game has not changed since the game has released. This means that an object that uses that specific interface (in the c# sense of interface) will always work correctly, no matter what other features have changed. This means that using a V2 resource on this type of custom content is just a cause of extra work on the part of the developer, or if they don't do the work, it causes frustration among the users of the mod. A V1 resource is never checked against the core version simply because it doesn't matter what version of the core is running.

As far as the NRaas stuff being borderline, I stand by that statement as well. Yes I know it isn't a CORE mod since the core packages aren't replaced. However, it does depend on features of the core packages that have changed from patch to patch. Therefore, it is not a real core mod, but it is more complex than a object mod. Some of your own mods probably fit into this category as well, though I've not looked at them to know.

Now, as far as what creators of custom content do, I don't really give a damn. I will state that creations that require me to do more work that I feel is justified to either re-download a new version or to use S3PE to edit the damned V2 resource version before it will load cleanly in my game won't be downloaded or edited. They'll be deleted and I'll look for a different creator to provide that function to my game. But that's just me and my opinion. And yes, this delete process has already happened on my game machine.

Sorry, but this is incredibly short-sighted, because this is only true if the object, i.e. the interaction tied to it, isn't supposed to do anything. The fun starts when the Run() method of an interaction gets called, and in there, the modder can basically do anything he wants. It doesn't even have to be anything fancy. I already mentioned the FamilyFunds property. Another example is showing a SimPickerDialog. You'll usually want to show co-worker info for these, so something like that got totally borked by the Ambitions patch. You can't even be sure if you only show simplistic notifications, since their styles got changed at one point too.

That is not true. For a V1 resource you simply can't tell either way, and you don't have the means to find out. As stated in this thread, twallan's mods use V1 resources, so I'm surprised that you come up with that again.

I'm glad that we're finally clear on the matter. It is about the rules you made up after all. I for one am not especially keen on following arbitrary rules.