#objectTuning
Explore tagged Tumblr posts
Note
Hello green Plumbob!!! I hope you´re not that busy for my question <3 basically, I want to say that I started to learn about coding, and how to do it a few days, so I learned that code for TS3 it´s hard and I´m not dumb (lol) so my question as a future modder (I hope) why TS3 is harder than code in TS4? and: how I make my experience about undertanding terms and code more easier?
Heya!
Hopefully you’re doing great! That’s a great question actually! There are actually a few reasons as to what’s different between ‘TS3′ and regular coding as well as what’s the difference between TS3 and TS4′s coding? And how come TS4 has more script mods?
TS3 VS Regular coding:
TS3, is, of course, a game ;) So a game uses a different sense of coding, logistics wise! It’s a bit of the same by comparing coding a game to coding a website. Both *use* code to execute the end result, but in the end, the way it’s executed is entirely different, despite that we might be using both C# or whatever for it :)
Just for a reference, compare the unity documentation : https://docs.unity3d.com/ScriptReference/GameObject.html
with ASP net: https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio
Both uses the same language, but the approach is different ;)
TS3 VS TS4:
This is a bit longer so I’m putting it under a 'Read More’...
TS3 and TS4 both work on the same engine. So you’d think, even if TS4 uses Python, you’d have the same work process right?
Wellll... yes and no! And this actually inspired me to do the same thing for ts3, but let’s take a look at a TS3 object mod and a TS4 object mod:
C# code for a TS3 Decorative object:
public class SculptureVase01 : Sculpture { [Tunable] private static EnvironmentMotive kEnvironmentTuning = new EnvironmentMotive(); [Tunable] private static ViewTuning kViewTuning = new ViewTuning(); public override EnvironmentMotive EnvironmentTuning { get { return kEnvironmentTuning; } } public override ViewTuning TuningView { get { return kViewTuning; } } }
Python code for a decorative TS4 Object:
class Rug(GameObject): INSTANCE_TUNABLES = {'flammable_area': ObjectFootprintFlammability.TunableFactory()} def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self._sort_order = 0 @distributor.fields.Field(op=distributor.ops.SetSortOrder) def sort_order(self): return self._sort_order @sort_order.setter def sort_order(self, value): self._sort_order = value lock_instance_tunables(Rug, provides_terrain_interactions=False)
Probably the whole TS4 code is all gibberish to you (it is to me too, even though I have written things in Python :p) But, the plus side of this (and why we can’t read it easily as programmers I guess) is because it’s made with a mindset of “We’re loading data in as dynamically as possible! With the help of some helper functions!”.
Believe it or not though! This is EXACTLY the same code logic as our TS3 C# code. In fact, really all the TS4 code does is “Check and set the instance tuning for this decorative object”. All of TS4′s code is made with this same nature.
But then the question still stands, how come TS4 modders release script mods so easily?
Well (TS4 XML code for decoratives):
<?xml version="1.0" encoding="utf-8"?> <I c="Rug" i="object" m="objects.decorative.rug" n="object_rug" s="14958"> <U n="_components"> <V n="focus" t="enabled"> <U n="enabled"> <V n="_focus_score" t="globally"> <U n="globally"> <E n="base">LOW</E> </U> </V> </U> </V> <V n="retail_component" t="enabled"> <V n="enabled" t="reference"> <T n="reference">110393<!--retailComponent_Default--></T> </V> </V> <V n="state" t="enabled"> <U n="enabled"> <L n="states"> <U> <L n="client_states"> <U> <T n="key">39478<!--FireState_Burn_Incinerate_Burning--></T> </U> <U> <T n="key">39479<!--FireState_Burn_Incinerate--></T> </U> <U> <T n="key">39612<!--FireState_Burn_Incinerate_Not_Burning--></T> </U> </L> <V n="default_value" t="reference"> <T n="reference">39612<!--FireState_Burn_Incinerate_Not_Burning--></T> </V> </U> </L> </U> </V> </U> <L n="_super_affordances"> <T>13328<!--debug_Reset--></T> <T>13326<!--debug_ObjectDestroy--></T> <T>103888<!--cheat_set_as_head--></T> <T>106859<!--simRay_Transform_Object--></T> <T>74457<!--fire_ReplaceBurntObject--></T> </L> <U n="recycling_data"> <L n="recycling_values"> <U> <E n="Bucks Type">RecycleBitsBucks</E> <T n="Value">0.75</T> </U> <U> <E n="Bucks Type">RecyclePiecesBucks</E> <T n="Value">0.25</T> </U> </L> </U> </I>
Given how TS4′s XML code for decoratives basically looks like TS3 rug interaction: internal sealed class RugInteractionProxy : Interaction<Sim, Rug> { [DoesntRequireTuning] private sealed class Definition : InteractionDefinition<Sim, Rug, RugInteractionProxy> { protected override string GetInteractionName(Sim actor, Rug target, InteractionObjectPair iop) { return "NeverVisible!!!"; } protected override bool Test(Sim actor, Rug target, bool isAutonomous, ref GreyedOutTooltipCallback greyedOutTooltipCallback) { return true; } protected override void AddInteractions(InteractionObjectPair iop, Sim actor, Rug target, List<InteractionObjectPair> results) { results.AddRange(Terrain.Singleton.GetAllInteractionsForActor(actor)); } } public static readonly InteractionDefinition Singleton = new Definition(); }
So, Generally speaking, anything I’m not comparing can usually be found within a TS3 OBJD or the XML/ITUN file of that object. Lets’ get to comparing!
“ super_affordances “ Is TS3′s AddInteractions() function.
“ client_states “ is basically either the states or the JAZZ scripts mentions
Some TS4 XMLs also have references to a ‘test’. TS3 does too. In the case of a rug decoration, however, it’s not necessary
I personally, therefore, think that the whole TS4 modding experience is just way easier. In fact, you barely need to do any programming! If you need to, you can just easily check other ObjectTunings, notice anything that your ObjectTuning has and just dump it in there ;) Easy as that!
For ts3, you just need to continuously make a C# script, hope that it works, make an ITUN/XML file for it, change the OBJD and OBJK accordingly... etc. It’s way more work than necessary. Besides, XML is easier to read than code ;) Another thing though with TS3 is the lack of code documentation. So therefore it becomes 10 times harder than it actually is.
For me, it took quite a bit before I sort of grasp it (and even now I still encounter things where I have no idea what they do :p) but that’s the power of testing & print statements!
how I make my experience about understanding terms and code more easier?
Ask a LOOOT of questions to the people who have done it before! :) They’re usually really quick to reply and usually after they share their findings, it’s much easier to understand the basics :) Another thing I personally do is, read EA’s code first before proceeding. Try to make sense of it. Don’t just copy-paste code you don’t understand and hope for the best. If you do so, however, I’d recommend using print statements on almost every line and just do ‘ToString()’ for a lot of variables used ;) Just know, ILspy is your friend!
Hopefully that answered it a bit! :) Sorry for the long list of things 😬!
31 notes
·
View notes