ZylonBane on 12/6/2020 at 16:40
It's not emulating 256-color mode, it's emulating 16-bit mode.
FenPhoenix on 31/10/2020 at 20:04
If Le Corbeau is watching, I'd like to bring up a particular bit of undesirable/erroneous(?) behavior. The issue is that a certain small number of config values which can be specified somewhere
other than cam.cfg, get copied to cam.cfg whenever the game is run (and left there permanently), and this can cause non-obvious issues for users. The most pressing issue is that "somewhere other than cam.cfg" can even mean a fan mission's fm.cfg file. These files are supposed to be FM-specific and from my point of view at least should
never modify a user's permanent, global config.
The values I'm currently aware of that are subject to this copying are:
-"fm_language" and "fm_language_forced"
Say the user has an English Thief install, but puts "fm_language french" into cam_mod.ini. They run an FM; it runs in French. Then the user removes the line from cam_mod.ini and runs the FM again. The expected result would be the FM runs in English, but the actual result is it still runs in French because the "fm_language french" line has been silently copied into cam.cfg. The user would have to remove that too in order to get back to English.
AngelLoader in fact handles this removal from cam.cfg automatically to ensure the correct and expected language is used in all cases.
-"sfx_channels"
-"character_detail"
The fan mission (
https://www.ttlg.com/forums/showthread.php?t=150719) Ascend the Dim Valley specifies these values in its fm.cfg, and they get silently copied into cam.cfg when the FM is run. The "sfx_channels" copy is only a minor issue; the user can always change that back in the UI and it's unlikely to cause much of a problem anyway. But the "character_detail 0" line in this FM's fm.cfg is far more of a problem; this line breaks texturing in many other FMs (some humans will be textured "backwards" with their face split into two on the back of their heads and the back of their hoods on their front etc. as can be seen in (
https://youtu.be/yvEchGPODDc?t=640) The Burning Bedlam with the hanging man, and in Calendra's Cistern on the antique guy's door guard when HDMOD is used). This breakage's cause is extremely non-obvious and I only stumbled onto it after a lot of trial-and-error and then remembering the language behavior described above that I happened to know from having written a mission loader.
There may well be other values that get copied, but if so I wouldn't know what they are. Most config values
don't get copied; it seems to be only a handful that do.
Not being a NewDark dev, I can't say for certain if this behavior is intended or somehow required, but I can't think of a reason why it would be. But the per-mission fm.cfg file leaking its values out to the global cam.cfg seems erroneous to me, and counter to what one would expect and want.
fgsfds on 12/3/2021 at 04:03
There seems to be an issue with multiplayer where if there's 3 players in the lobby and the 4th joins, one or two others get kicked out. It's kind of similar to what happens in SS2 sometimes. I seemingly fixed it by raising max players from 4 to 8 (the bug now occurs when the 8th player joins instead, so maybe there's an off by one kind of error somewhere). This can be done by changing byte 04 to 08 (or any other number larger than 4) at offset 2F4FF in Thief2MP.exe and offset 2E121 in Shock2.exe (the one from NewDark 2.48). If you do that in SS2 it also allows more than 4 players to join a lobby, though we still couldn't get in game proper with more than 3.
We beat a few missions with 5 players in T2 and it worked pretty well if you don't count frequent crashes and occasional desyncs, I'd say better than the old MP mod. It even lets you spectate other players when you're dead.
One thing I was wondering about: is there a better way to skip to a specific mission other than just doing the mission skip cheat over and over? The cheat does work in multiplayer, but it gets kind of tiring to do every time it crashes and screws up the saves.
Saracoth on 23/8/2021 at 02:22
Quote Posted by voodoo47
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.
I ran into the same disappointment, but am still excited overall! (For any curious people, the games have a great system to describe how objects and creatures react to stimulation. In the vanilla game, it's used for everything from generating particles when undead take holy damage, to putting NPCs into a "knocked out" state when you blackjack them.)
I think squirrel scripting can be a workaround to these limitations, but I need to play around to confirm that. It would be nice to use pure DML, though. Not everyone is going to be comfortable learning a new (or maybe their first!) scripting language and API, and the dark engine's source/receptron system is already a powerful tool on its own.
If the issue is unclear to anyone else, receptron effects like create_obj and add_metaprop currently accept only numbers, the Me keyword, and the Source keyword. Anything else results in "SYNTAX ERROR: expected int val" errors. At the moment, it's not really possible to create a new kind of object and spawn it, nor create a new metaproperty and add/remove it.
Quote Posted by Unna Oertdottir
Confine it on dark.gam. FM authors already set the difficulty in their missions. Nobody wants endless discussions about broken stuff, you know.
I appreciate the suggested workarounds, but they appear to create fragility without achieving the intended goal. Namely, it would be nice to create gameplay mods people could install in any combination they'd like. Currently, that's not possible for some DML-only mods.
Yes, I could create a DML file that assumes the first object I create will be ID -5528, the second -5529, and so on. But if two mods make those same assumptions, they're no longer compatible with one another, even if they would otherwise be perfectly happy together. One mod thinks -5528 is a new stimulus, another mod is written with the assumption -5528 is a new metaproperty, and everything breaks. As you say, nobody wants endless discussions about broken stuff.
Or let's say someone installs the toggleable lantern mod I've seen on these forums. Being mostly script-based, it doesn't have these issues (that I'm aware of). However, if that mod loads before a script with your proposed workaround, suddenly the first object it creates is -5529 instead of -5528, and everything is broken again. The IDs coming out of CreateArch may be deterministic, but that's only useful in some narrow cases, and not helpful in this scenario.
I'm still pleased with these new New Dark features, and think a lot of fun stuff can be accomplished with them!
voodoo47 on 23/8/2021 at 19:16
very sure the dml system can handle archetype creation from multiple different mods, and unless the queued names are the same by a freak accident, everything should work.
Saracoth on 24/8/2021 at 17:02
Quote Posted by voodoo47
very sure the dml system can handle archetype creation from multiple different mods, and unless the queued names are the same by a freak accident, everything should work.
Right, and if we could use archetype names in receptron Targets and Agents, all would be well. But it seems we're stuck using guessed-at IDs that are out of any
individual mod's control, or else resorting to scripting or other non-DML solutions.
Here are two minimum viable examples I can quickly throw together. These are just toy Thief 2 examples for demonstration purposes. The first mod spawns a hostile hammer haunt variant when using the compass. The second spawns an active mine once per second per Human creature within the radius. Basso, for example. Either mod works fine by itself. When both are installed together, the second mod starts spawning haunts instead of mines.
I admit, these haunt and mine variants are no different from their vanilla counterparts, but that's just to keep the examples shorter. Adding and removing brand new metaproperties have similar issues, but the results aren't necessarily as visible and obvious as creating objects.
C:\Games\Thief 2 The Metal Age\Usermods\dbmods\TestModA.dml:Code:
DML1
CreateArch "Stimulus" "TestModAStim"
CreateArch "Haunt" "TestModAHauntVariant"
++StimSource "Compass2" "TestModAStim"
{
Intensity 1.0
Propagator "Contact"
{
Shape
{
"Contact Types" "Frob in Inv"
"Velocity Coeff" 0.0
"Frob Time Coeff" 0.0
}
}
}
++Receptron "Garrett" "TestModAStim"
{
Min 1.0
Max None
// These both result in "SYNTAX ERROR: expected int val"
//Target "TestModAHauntVariant"
//Target TestModAHauntVariant
// This would work fine on a vanilla gamesys, but for me it spawned a corpse part instead.
// (There are a bunch of CreateArch statements in C:\Games\Thief 2 The Metal Age\OSM\dark.gam.dml)
//Target -6868
// This worked for my installation
Target -6964
Agent Me
Effect "create_obj"
{
"Position" 5.0, 0.0, 0.0
"Heading" 0.0
"Pitch" 0.0
"Bank" 0.0
}
}
C:\Games\Thief 2 The Metal Age\Usermods\dbmods\TestModB.dml:Code:
DML1
CreateArch "Stimulus" "TestModBStim"
CreateArch "ActiveMine" "TestModBMineVariant"
++StimSource "Human" "TestModBStim"
{
Intensity 1.0
Propagator "Radius"
{
Life
{
"Flags" "No Max Firings"
"Period" 1000
"Max Firings" 1
"Intensity Slope" 0.00
}
Shape
{
"Radius" 100.00
"Flags" "[None]"
"Dispersion" "Linear"
}
}
}
++Receptron "Garrett" "TestModBStim"
{
Min 0.0
Max None
// These both result in "SYNTAX ERROR: expected int val"
//Target "TestModBMineVariant"
//Target TestModBMineVariant
// This would work fine on a vanilla gamesys, but for me it spawned a corpse part instead.
// (There are a bunch of CreateArch statements in C:\Games\Thief 2 The Metal Age\OSM\dark.gam.dml)
//Target -6868
// This worked for my installation, unless mod A was also installed, in which case this creates a TestModAHauntVariant!
Target -6964
// This works when both mods are installed, but breaks when only ModB is installed
//Target -6966
Agent Me
Effect "create_obj"
{
"Position" 5.0, 0.0, 0.0
"Heading" 0.0
"Pitch" 0.0
"Bank" 0.0
}
}
There's no clash or overlap in names, but both mods assume their new object is ID -6964. This is true for both mods individually, but it's not for both mods together. As noted in the comments, using the new archetype names isn't an option in this context, so it's numeric IDs or bust. This limitation is most likely to come into play with add_metaprop, add_prop, create_obj, rem_metaprop, and maybe some other effects I'm not thinking of right now.
The worst-case scenario is two authors creating DML files with these assumptions, and an end user suffering issues when trying to install both. In this example, there's nothing about the "functionality" of either mod that conflicts with the other. The sole reason they can't be used together is that both DML files are forced to rely on newly generated IDs they have no control over.
I do think squirrel scripting is a potential workaround for most (or all) scenarios, but I'm still reading up on the documentation and such. Functions like Object.Create(), Object.AddMetaProperty(), and Object.RemoveMetaProperty() accept string names, including for CreateArch-defined things. If stims absolutely must be used, implementing OnTestModBStimStimulus or similar functions should work. Stims could even be bypassed entirely in some cases, such as by using frob events or timers.
I don't mind learning new stuff, since that's part of the fun. This DML limitation does increase the complexity factor for some mods, but it is an edge case, and it appears there are script-based alternatives. It looks like we have all the tools we need to create neat gameplay mods that people can install in any combination they please, for use in OMs or FMs alike :)
voodoo47 on 24/8/2021 at 18:57
will check, but on the first glance, I think you are trying to do something that simply isn't possible right now.
Saracoth on 27/8/2021 at 15:18
If you mean with DML alone, then no, the Target and Agent limitations are an issue in some corner cases.
On the other hand, (
https://github.com/saracoth/newdark-mods/tree/original) https://github.com/saracoth/newdark-mods/tree/original ! Three toy projects I made to explore these features. They're compatible with both Thief games, and they can be installed in any order and in any combination. They use squirrel scripts to work around the DML receptron limitation, but in principal these could be pure gamesys mods.
The three mods demonstrate a mixture of add_metaprop, add_prop, create_obj, and rem_metaprop style effects. All involving brand new archetypes which can't reliably be used in receptrons at the moment. So, yes, these kinds of highly compatible gameplay mods are possible with NewDark's current features, if one jumps through some extra hoops. Maybe these can be useful examples for someone to make something even more interesting :)
It'd still be nice to have string-based identifiers for receptron agents and targets someday, since that would simplify some kinds of projects. On the other hand, squirrel scripts are going to be more convenient for some purposes. In the (
https://github.com/saracoth/newdark-mods) main branch, I've committed some revisions to these mods to make better use of scripting features. Maybe seeing the old and new mods side-by-side would even help someone understand how squirrel scripts could be used in place of sources and receptrons for some things. The first link is to a version of these scripts that stick as closely as possible to how I would implement these in act/react alone, without scripts, for educational purposes. The second link is to the latest, recommended versions of everything.
Azaran on 24/1/2023 at 04:44
So here's a weird thing. I had been copying the Newdark files manually over the years (not via Tfix), and I had overlooked squirrel.osm.
Now that I have it (I need it for a loot mod, thanks Saracoth), it makes the game unbearably choppy, stuttering as soon as I move. I know squirrel is the culprit, because if I remove it, it goes back to normal, and I currently have a decent video card and 24 GB of ram. Anyone else experience this? I'm hoping it's something that can be fixed by tweaking cam ext cfg