Dragofer

After some further research, it really seems to be caused by the inbuilt trigger behaviour for any entity that has a "gui" spawnarg. I created a random func_static, gave it a valid "gui" spawnarg and triggered it twice which resulted in flashing a blank parchment for a frame (after some reloading). So it's unlikely the fault is with the scriptobject.. The question is: does any entity in any map rely on this inbuilt "gui" behaviour? If no we can just remove TriggerGUIs from idEntity::Activate. Do we have a way to extract all entities from all released maps that have a "gui" spawnarg? Edit: extracted all existing "gui" spawnargs from released maps, removed duplicates and removed those that contain words like "message", "map", "text" etc. in order to look for potential non-message GUIs. I looked up the remaining 32 entries in their respective maps to check what kind of entities they're given to with the following results: Turns out that quite a few of these entities (i.e. the func_statics) rely on TriggerCall being part of the base idEntity::Activate method in order to call up their GUIs. So it's not some forgotten legacy code we can remove. We could add a custom spawnarg to the entityDef for atdm:gui_message to disable this behaviour for them - no FM overrides this entityDef, btw, so it'll apply to all FMs - but it won't fix other entities that call GUIs and don't have this spawnarg.

So there's this: When reproducing this bug, it seems there are always multiple messages involved. The first message in the training mission isn't affected, so it suggests the bug begins with the 2nd message. Also supported by the fact that if you view the 2nd message first it's fine, too. This comment in tdm_gui_message::showMessage() seems to be aware of a flickering issue due to "multi-trigger" and therefore checks whether a gui has already been created for that particular message entity. However, the value of the float variable "gui" is unique to each message entity, so the check doesn't work if a different message entity has created a gui. So a possible attempt at a solution could be to turn the gui handle into a global variable shared between all message entities (I renamed it to dragofer_gui to ensure there are no conflicts with other scriptobjects that have some kind of "gui" variable): tdm_message.script Would be nice if someone who can reproduce the bug can try whether this makes any difference. In this implementation it will not show the next message overlay if the old message overlay is still present. If this approach works we might consider destroying the existing message overlay.

This works, including for doors made from brushes in DR: vector center_offset = 0.5 * (object.getMins() + object.getMaxs()); vector center = object.getOrigin() + sys.VecRotate( center_offset, object.getAngles() ); Turns out that getMins() and getMaxs() don't take current orientation into account, they only state the bounds when the entity is in its default orientation. Therefore you need to rotate the offset by the object's current orientation.

Does it happen in TDM 2.10 too? You can have multiple darkmod folders with different TDM versions.

I was trying to resolve 0005914: Add subtitles to New Job when this occurred: 0006197: Subtitles not shown during cutscenes.

This pack has been added to core assets. Unless you expect to release an FM in the next month, you can just upgrade to a beta build and set the required TDM version to 2.11 in your FM's darkmod.txt. I've already played what Wellingtoncrab calls the sequel to Iris... it's nice, it's got lots of this loot in it and manages to showcase them in a variety of lighting setups... no story, no AIs, and just 1 room, though.

I meant more this: if you use the compass when the door is opened and when it's closed, do the flames spawn in different positions? That would suggest that getMins() and getMaxs() still work correctly on moving doors.

Doors might sometimes work differently in some ways because they can be created from scratch from brushes in DarkRadiant instead of using real models. Nevertheless, I believe getMins() and getMaxs() still work as expected. For getting the orientation of a model, getAngles() is all you need, but it probably won't work for "models" created in DarkRadiant. The "rotation" spawnarg only sets the initial orientation anyway, and I'm not aware of a way to convert it to angles. Have you noticed any patterns for where the "center" gets placed relative to a door? Does the center move when the door moves?

Why do you swap the body?

Yeah, I believe theyre relative to the entity origin and can therefore just be added to the entity origin. object.getOrigin() + center Mins and maxs are almost identical here because you're working with a crate whose origin is in the center of the model anyway, but with something else you might get i.e. mins = -5 0 -5 and maxs = 10 30 10 relative to origin, with center = 2.5 15 2.5

Bounds are like a cube that completely encases the model. The cube is always aligned with the x, y and z axis, so if you rotate the model the cube will grow or shrink to make sure the model is still exactly contained inside the cube. You can get the coordinates of the bottom left and top right corners of this cube with getMins() and getMaxs(). Exactly halfway between them is the center of the model.

You could getMins() and getMaxs() to get the minimum and maximum coordinates of the model bounds, then add half the difference to the minimum coordinates to get the center of the bounds. Alternatively, if you know the offset between the entity origin and the center of its model bounds when it isn't rotated you can rotate that offset by the current getAngles and add it to the entity origin. vector center = getOrigin() + sys.VecRotate( offset, getAngles() ); If you're working with bound objects you can use getWorldOrigin() instead of getOrigin(), as the latter just gets the offset relative to the bind master.

Likewise, I was thinking of secretly finalising a very horror-themed mission for this contest but time got the better of me. Nevertheless it's budged yet closer to release.

Should the player be there when the ragdoll falls? If not, you can unhide an invisible ragdoll that already lies in the correct position: 1) Create a ragdoll entity in DR 2) Start the map in TDM and place the ragdoll how you want it to be. 3) Use the saveRagdolls console command. This generates a new .map file in your base install maps folder, where the ragdoll has a bunch of new spawnargs that make it spawn in that exact position. 4) I don't think it's 100% safe to override your .map file with the generated .map, so the best is to open another instance of DR, open that new .map, copy-paste the ragdoll to your original .map, copy-paste the new spawnargs to your original ragdoll and get rid of the other ragdoll again. 5) Set the "hide" "1" spawnarg on your ragdoll. When you want the ragdoll to show up, trigger the ragdoll (or use show() in a script). Alternatively it may also work to set "skin" "invisible" and change that to "visible".

My problem is with this: if you have 2 files of the same name, and 1 is packed and 1 is unpacked, since 2.11 TDM won't start because "File x was loaded twice". It looks to me like an error in the 2.11 code changes to the file loading system. I think there's a misunderstanding. FM/FM and Core/Core overrides are definitely a problem and should post console warnings because (a) you never need multiple copies of the same decl inside core or inside an FM and (b) you don't know which one wins unless you're familiar with the ruleset above. What I think is benign is FMs overriding Core decls or files, either done intentionally or when a custom asset becomes a core asset. This should not generate error messages, and adding new decls to core should not have any effect on FMs.

I think this is what went wrong: the same file exists both packed and unpacked in the FM folder, but instead of the unpacked file overriding the packed file you get the blue screen error "File x was loaded twice" that stops TDM from starting. If my understanding is correct, these are the new mechanics in 2.11? FM decls/files always override Core decls/files of the same name, regardless of packing state (FM/Core) Unpacked files override packed files of the same name on the same level (FM/FM or Core/Core) Among packed files, the file in the .pk4 that's loaded last wins (.pk4 name lexicographically last i.e. z) The decl in the file with the earliest filename wins (filename lexicographically first i.e. a), the file's packing state or .pk4 name don't matter.

Yeah Id just assume that the unpacked decl would override the packed decl, as per the regular rules for decl priority.

Found the cause: if the same decl file exists twice - in a packed and unpacked state - TDM won't start. I had unpacked nobleaffairs.pk4 and didn't remove the .pk4. And I was working on Seeking Lady Leicester until I packed it into a .pk4 for a bug report and I could no longer start TDM afterwards ("happens occasionally"). Removing the .pk4 fixes both cases. I think it's becoming clear that when reporting bugs, "it happens occasionally" just means you haven't figured out the reproduction steps yet.

On some occasions I've been unable to start TDM with an FM loaded (i.e. Noble Affairs or Seeking Lady Leicester) due to a blue-window error with a message about some decl file contained in the FM like "Flanders.mtr is loaded twice". It only seems to happen occasionally, and I'm on 2.11b01 right now. I suppose this is a consequence of the new logic for resolving conflicts between core/FM and packed/unpacked decls?

Im on Windows with an RX 460.

The fact that simply renaming your .exe to one of the games used for benchmarking GPUs raises performance suggests that there's something intentional going on here.

I'm also getting horrible performance on latest SVN (10250) with AMD, whereas 2.11b01 seems normal. r_usedebuggroups was 1 but setting to 0 seems to make no difference even after a restart. It seems to be related to shadowcasting: my fps drops from capped 60 to 6 if I switch on a player lantern around shadowcasting objects.

@Araneidae do you remember whether you KOed anyone in that run of CoS0? That could explain the failed stealth objective, otherwise it may be a core bug.

Hi, Ive been looking at your files but it seems the textures arent included - do you happen to have a link to those?

Looking at that mission, its ghosting objectives checks for: 1) no AI alerted to level 2 or higher (should correspond to standing still for a moment) 2) no AI on team 1, 2 or 5 KOed (default: Builders, guards, neutral street people). If you KOed someone that would explain it (or an AI got KOed for another reason and the objective isn't set to check for player responsibility). Otherwise there could be a bug with how component 1 is set up. In any case, stealth score doesnt figure here. The stealth score fixes are available from 2.11 beta 02, right now we're on beta 01.