Newsletter #1

User avatar
SimulatorSam
Global moderator
Posts: 6239
Joined: 05 Mar 2014 17:52
Location: United Kingdom
Contact:

Re: Newsletter #1

#11 Post by SimulatorSam » 22 May 2015 08:08

Katixa wrote:Only thing to worry about mostly is the infamous "load order" to make one mod work, or some mod overwritte certain feature from another mod.
That wouldn't matter anyway, because if you subscribed to a mod, you can still change the load order. (As seen in screenshot)

User avatar
Edwin
Posts: 195
Joined: 13 Mar 2014 23:46
Location: The Netherlands

Re: Newsletter #1

#12 Post by Edwin » 22 May 2015 08:17

RootKiller with an orange nick.... one has to wonder!

More on topic. How about simpler changes to the mod system. I would propose an extension to the SiiUnit whereby you could include a previous version (from the mod before or the base if it is the first loaded mod). This way, an sii file only needs to include the actual changes and would reduce the number of conflicts.

It would also be helpful to change the system a little so that the map rectangle can be extended instead of replaced. So it would determine a bounding box around the entire map area instead of using the last loaded map mod.

User avatar
Reinhard
Posts: 5003
Joined: 20 Dec 2012 16:46
Location: Nimby, District of Berlin

Re: Newsletter #1

#13 Post by Reinhard » 22 May 2015 08:39

RootKiller wrote: Unfortunately for now we will not change modding support dramatically as we cannot simply break backward compatibility.
Excellent ! :D

Katixa wrote: So what happens when two mods change the same variable, or the same object on the map?? Well, here's where mod load order comes.
Exactly like it is now.

Sorry Katixa, no offense, but I disagree. If two different mods changes more than one of different same objects, loading order gives you nothing. You got the changes of one and lose that of the other. With potential disastrous consequences, because there might be other changes from both mods still present. With your attempt, you will provoke much more of these problems.

Same for changes to the map: there was a time not too long ago where you could only use one map mod and that was it. Ruled out any conflicts. Now we have sectors. Even with that simplified approach, it is hard work to interweave two maps or keep progress with map patches and DLCs. Hard work for the map modder. A map user can only use what is presented to him, and to use several maps which aren't developed in cooperation is a futile attempt. Loading order or not. But I'm glad it is possible now.

Releasing map mod changes based on object level would multiply this problem by magnitudes. Only one example: one person adds a road from west to east, another one a road from north to south. Where is the crossing? How to merge the landscapes near these roads?

This idea would only fly if you restrict the changes a modder could apply to a bare minimum. Sorry, don't want that.

(EDIT: fixed nasty typo)

User avatar
supric
Posts: 1237
Joined: 08 Jun 2013 09:44
Location: Russia, Tula

Re: Newsletter #1

#14 Post by supric » 22 May 2015 10:18

Reinhard wrote:Sorry Katixa, no offense, but I disagree. If two different mods changes more than one of different same objects, loading order gives you nothing. You got the changes of one and lose that of the other. With potential disastrous consequences, because there might be other changes from both mods still present. With your attempt, you will provoke much more of these problems.
"Layer assignment" already works partially in the game! Look to the traffic_data.sii mods. You can assign just some of params of the whole set of traffic prams, because they have default values and it will work correct :)

So, mod loading mechanism needs a little improvement: game must load values from every mod, next mod values overrides previous.

Okay, there can be some issues with "list" files (cargo.sii, city.sii, etc) or something else, but it can easy solve a huge heap of problems with game_data, economy_data, traffic_data with different mods.

User avatar
bumbumek
Posts: 3773
Joined: 02 Jun 2014 13:14
Location: Poznań, Poland

Re: Newsletter #1

#15 Post by bumbumek » 22 May 2015 12:38

Great idea with this newsletter, it should come out definitely more often :!:

eem2004
Posts: 9
Joined: 29 Dec 2012 11:30

Re: Newsletter #1

#16 Post by eem2004 » 22 May 2015 13:44

A big thanks for the newsletter. It would be nice to get one each month, or when you update the game,
as often I get busy for game stuff and don't check blog for a while and find out from other players a update
has come out. It is a great way to connect and be kept in the loop about other games.

The layout is good and well thought out and it is the personal touch of keeping us updated and learning more
about what is happening at SCS

I hope to see many more
For Ultra High Poly Truck Models Visit:
Hd Truck Mods

User avatar
Reinhard
Posts: 5003
Joined: 20 Dec 2012 16:46
Location: Nimby, District of Berlin

Re: Newsletter #1

#17 Post by Reinhard » 22 May 2015 13:47

supric wrote: "Layer assignment" already works partially in the game! Look to the traffic_data.sii mods. You can assign just some of params of the whole set of traffic prams, because they have default values and it will work correct
I see. Interesting, but it convinces me only for files like "\def\game_data.sii", where totally unrelated data is aggregated.

What should a modder do with such an attempt: if he only changes those values which must be different from the base to achieve a specific goal, he often relies on the integrity of the others. Which means these aren't changed by other mods. So if he want to be sure, in future he would change all the values in question even if not needed in the process of modding. Which is not what you want.

With the current approach, it immediately reeks of problem if two mods operate on the same file. This we can easily notice and analyze. With "Layer assignment", this opportunity is out of the window, because different mods operating on the same files becomes standard. Detecting and locating problems gets harder.

No enhanced modding concept releases us from the need to analyze the full content of conflicting mods, anyway. This is a process well supported by data comparison software tools (WinMerge and such), provided a clash of files is identified.

So my suggestion for a mod-manager enhancement shouldn't be a surprise: support the detection of file clashes. Telling us what files are the same in the list of currently active mods. Straight and simple concept, but very useful if many mods are used.

User avatar
Katixa
Posts: 262
Joined: 06 Feb 2013 20:19

Re: Newsletter #1

#18 Post by Katixa » 22 May 2015 15:58

RootKiller wrote:Unfortunately for now we will not change modding support dramatically as we cannot simply break backward compatibility. Modders are currently familiar with our current mechanisms of modding and changing it is not a good idea.
Thanks for the reply. I understand. But as I see it, there's not need for a sudden dramatic change. You can keep mod loading as it is now, while eventually implementing tools and changes that improve the modding system. In a few months all the new mods would use the new system.

MinecraftMarioGuy53 wrote:That wouldn't matter anyway, because if you subscribed to a mod, you can still change the load order. (As seen in screenshot)
You got me wrong, that's exactly what I was talking about. Meaning that the only "worry" for the normal user is to keep a correct load order ;)

Reinhard wrote: Exactly like it is now.

Sorry Katixa, no offense, but I disagree. If two different mods changes more than one of different same objects, loading order gives you nothing. You got the changes of one and lose that of the other. With potential disastrous consequences, because there might be other changes from both mods still present. With your attempt, you will provoke much more of these problems.

Same for changes to the map: there was a time not too long ago where you could only use one map mod and that was it. Ruled out any conflicts. Now we have sectors. Even with that simplified approach, it is hard work to interweave two maps or keep progress with map patches and DLCs. Hard work for the map modder. A map user can only use what is presented to him, and to use several maps which aren't developed in cooperation is a futile attempt. Loading order or not. But I'm glad it is possible now.

Releasing map mod changes based on object level would multiply this problem by magnitudes. Only one example: one person adds a road from west to east, another one a road from north to south. Where is the crossing? How to merge the landscapes near these roads?

This idea would only fly if you restrict the changes a modder could apply to a bare minimum. Sorry, don't want that.
No offense taken. I understand your concerns, but I'm afraid I don't agree. Bethesda has been using this system for years with Elder Scrolls series (from Morrowind to the current Skyrim), and I've been modding there for a lot of time, without any issues.

Load order indeed works because it just simply overwrittes a previous "something" changed by another mod. For instance you install a mod (A) that improves general truck values (brakes, suspension, engines...), and there's another mod (B) which improves engines, even more. You just need to make sure load order is A-B to keep engine values from B. There can be some incompatibilities in some special cases, indeed, but that's up the the user to care about, similar to what we do now. In many mods in Skyrim you can read author notes telling "not compatible with this, not compatible with that", either because the creator knows, or because people eventually reported and (if not fixable), it's included on a list.

About the map, of course if you have two mods that add a road on same place, they will collide, or either crash the game. Again, here it's just a mod compatibility problem, and it's up to the mod user to take care of the situation. What is NOT correct, if you want to dive into Steam Workshop, is to have a map system that requires to have just "one mod", or just "one mod per sector". Try talking to normal players about "sectors".... sec-what? ;)

A mod that improves city quality by adding walkers, decorations, etc. in all cities, should NOT be overwritten by another mod that adds a couple or forklifts on companies to make backing harder. Both should be able to co-exist. Currently we don't have those kind of mods here because people is discouraged both to create them, or install them, because having one means not having another. For instance I would gladly make changes to the map as I did in Haulin, GTS, ETS and ET, but I just don't want to miss any updates from patches.

Getting back to Skyrim, I don't know if you are into that game, but you can have a mod for instance that places a building somewhere, and another one that places another building just in front of it. In ETS2 that's impossible because a whole sector (and worse before, the whole map) is "the mod". There are of course cases where a player house is just in collision with another famous mod, and if enough people requests, maybe the modder agrees to move the building a bit, to make it compatible with the other mod. If not, players have to choose, one or the other, of course...

So yes, these collisions happen.. but only on certain cases with certain mods, and if you ask me, it's better than having a mod overwrite a whole sector (which by the way could have been updated by SCS on a patch and you won't see it).


I understand there can be a bit of "neophobia" when important changes come... but it's just that after working with a good and robust modding system, it scares me to think there will be a Workshop with this current system. It's not a bad system, don't get me wrong... all my respects to the team for creating it, taking care of it, and improving it... but it's just a bit... rudimentary? Not sure if that's the word to express it.

Regards :)
Every day above ground is a good day.

User avatar
Reinhard
Posts: 5003
Joined: 20 Dec 2012 16:46
Location: Nimby, District of Berlin

Re: Newsletter #1

#19 Post by Reinhard » 22 May 2015 17:57

Katixa wrote: About the map, of course if you have two mods that add a road on same place, they will collide, or either crash the game. Again, here it's just a mod compatibility problem, and it's up to the mod user to take care of the situation. What is NOT correct, if you want to dive into Steam Workshop, is to have a map system that requires to have just "one mod", or just "one mod per sector". Try talking to normal players about "sectors".... sec-what? ;)
I don't understand this. You are suggesting a system where every little part of the map can be changed independently, everywhere, with an isolated mod, correct?

And then your suggested treatment regarding the for sure everywhere arousing conflicts is: "it's just a mod compatibility problem, and it's up to the mod user to take care of the situation." ? Did I get that right?

Is it possible that you are not very familiar with the map editing process of this game? I'm not talking of "load order problems". These handle incompatibilities. The problem I see with your approach is about how to make map mods compatible. And I have no idea how this should work without destroying most of what's possible with map editing right now.

User avatar
Katixa
Posts: 262
Joined: 06 Feb 2013 20:19

Re: Newsletter #1

#20 Post by Katixa » 22 May 2015 18:19

@Reinhard: Maybe we're not understanding each other :)
I'll try to explain myself a bit more.

Currently map editing works this way: When opening the editor, it loads base map, and in case you have sector files in the mod folder (or a whole map), these overwrite default map. So basically, if we have a mod with just one sector changed, a whole sector with its mountains, roads, signals, prefabs, models, movers, etc is loaded, replacing the base sector.

Forget about this.

The world or map edit I'm suggesting (similar to what Bethesda does), is just that the editor simply tracks changes done, item-level. The map mod file itself does NOT contain the sector, or even the map. It just contains the information for the game to apply THAT specific modification. For example: "Add itemId xxx to position XYZ", in case someone added a parked car on a village somewhere. This is the only information that gets stored in the map mod when you save it in the editor. It's some kind of plug-in.

This means that when the game starts, it loads the default base map, and applies this modification in memory. It's the same engine that loads and generates the map, but just applying the change included in this mod.

I don't know how SCS stores the map in the binary files, but I guess all items have an unique identificator. So all map mods should coexist without issue, being the only "problem" mods that change same specific area. For instance someone decides to decorate a toll with a couple parked trailers, and someone else decorates same toll with a couple of parked cars. You would either see both trailer and car models somehow merged, or either have a CTD, I don't know, but it's up to you to fix that uninstalling one of the mods.

I don't know if this cleared things up a bit...
Every day above ground is a good day.

Post Reply

Return to “Newsletters”

Who is online

Users browsing this forum: No registered users and 1 guest