sNeaksieGarrett on 25/6/2019 at 01:12
I guess I didn't make myself clear, sorry for the confusion. I meant that I was going to test to see if your idea would work for a third party script in a multiplayer session, using the #script line you mentioned. I wasn't trying to test gen.osm in singleplayer.
But now I'm wondering if maybe gen.osm is the problem here in this FM. I'm thinking I should try your suggestion and retest multiplayer.
Update: Swapping out the gen.osm from multiplayer with the original gen had no effect whatsoever on the multiplayer client's ability to use a cookie on a plate or use the broom. I guess it is just an inherent problem with multiplayer that client players cannot do certain things, or at least with this fan mission. (But then I guess I am being daft, as the whole point of the mp patch's gen.osm was to make it mp friendly, so I should have figured swapping the osms wouldn't make any difference.)
Update 2: So, I was doing some more testing and decided to try loading the NewDark version of A Thief's Holiday. Interestingly, the multiplayer log file does not show that "script.osm" is being loaded when launching this mission but other .osm files that were included in the FM install were listed. Why the game doesn't load that specific script is beyond me. Further to that, I had this in the dml file, "#script "script" , however that doesn't seem to actually work. Having that line didn't force the game to load the script.
What I find puzzling is your previous post suggests that you had some success with adding that line to your dml; but for me, it failed, suggesting to me that the #script idea doesn't actually work.. and yet, how do we explain how it worked for you, then?
Update 3:
So, interesting development. I decided to try testing Running Interference, to see if there was any issues with the client player frobbing objects.
I've discovered that there is something definitely off about multiplayer when it comes to interacting with objects. As the host, I could pick up a key, use it to unlock a door with no problem. As the client, I tried picking up the key and then using it on the locked door but the client player could not get the door to unlock. Furthermore, I noticed that after the client player dropped the key, the host could not re-pick it up. I had also frobbed some items on a table as the client and the host could not frob those that the client had touched.
It sounds like it is a bug within the multiplayer patch, or an inherent design choice. This testing leads me to believe that the custom script from the FM I was playing has nothing to do with the use object issue.
Can anyone else try testing Running Interference and see if you can replicate the same behavior? Since I used an original mission for this test, I can't imagine it would be any different with someone else, as we have the same mission, so probably a waste of time, now that I think about it.
Another thing that occurred to me is how SS2's multiplayer functions and if this was a problem in that game as well. I can tell that whoever developed this patch for Thief 2 must have tried to mirror the code from SS2, since it was already done for that game. I can tell for example that it uses the same exact menu setup with how to join a game and whatnot, as I fired up SS2 earlier tonight and the process/menus were exactly like Thief 2's.
voodoo47 on 28/6/2019 at 06:18
bit of a limitation in the dml archetype creation system, hoping to have it lifted in the future - if connecting multiple dml created archetypes (using receptrons in my case), everything needs to be referenced by archetype names (as the ids may/will end up different for each gamesys) - the 1.27/2.48 dml system only allows archetype ids for Receptrons target/agent object, making it impossible to set multiple dml created archetypes up properly (as you do not know the id of the target/agent object, because you are dml creating it as well).
basically, if your dml mod requires creation of several new archetypes that need to be connected via receptrons and you need to reference one of them in the target/agent field, you are out of luck.
Unna Oertdottir on 28/6/2019 at 06:53
Create an object first, and test it. set game_mode_backup 0 and note the object ID. You can use it in the dml, since it's the same obj id next time. Creation and obj id will also be displayed in monolog.
voodoo47 on 28/6/2019 at 06:58
yeah, but this will only work for one particular gamesys of one particular version, defeating the purpose of the dml being universal. might as well just edit the gamesys and avoid the shenanigans altogether (that's what I did with the ultimate difficulty hdmod conversion).
Unna Oertdottir on 28/6/2019 at 07:57
Universal? What does that mean?
voodoo47 on 28/6/2019 at 10:38
it means the dml mod can be used for any kind of gamesys* that is out there - vanilla, T2Fix, hdmod, or a fan mission of your choice without having to edit the gamesys in the editor (a good example would be the (
https://www.systemshock.org/index.php?topic=9662) Big Droid Immortality Protocol mod, which was restricted to SCP until now, because it required edits to the gamesys - with the ability to create dml archetypes, it now can be converted to be universal, and work on any kind of game, vanilla, Secmod, whatever you fancy).
*assuming the author was at least partially sane, and didn't construct their gamesys like a Pollock painting.
Unna Oertdottir on 28/6/2019 at 10:54
Confine it on dark.gam. FM authors already set the difficulty in their missions. Nobody wants endless discussions about broken stuff, you know.
voodoo47 on 28/6/2019 at 11:15
uhh.. what? I'm talking about universal mods here.
hard thief kyd on 3/7/2019 at 21:01
By The Builder! 1.27! With multiplayer! 'Tis not just fine but truly great.
Who is Le Corbeau, but the Hand of The Builder? What the Builder wills, Le Corbeau...does. What the Builder wants, Le Corbeau...makes. Praise to Le Corbeau! ...And the Builder.