Dragofer
-
Posts
2631 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
14 hours ago, Skaruts said:
@Dragofer does your version work in 2.12? I'm confused about what to download. I tried one z_addon_stealth_statistic_2_07.pk4 that I found somewhere in this thread, but it didn't work.
I tried out @kcghost's version (it works on 2.12), but I found that it interferes too much with my usage of inventory items, so I'd like to try out yours to see if it's more comfortable to use. I think I've seen a youtuber use it before.
As the file name implies it's for v2.07, which was the last TDM version before a hook for custom user addons was added. It therefore overwrites the main TDM script file with a version from 2.07, which means several newer missions won't work anymore.
It looks like I made an updated version that should be compatible with all 2.08+ TDM versions, as per datiswous' post. Practically it's an inventory item that triggers a GUI message popup whenever you activate it in your inventory.
-
On 6/5/2023 at 10:17 AM, datiswous said:
Is it possible to teleport the player to different areas depending on a condition? For example a gui selection.
It would be nice to have a gui-selection menu opened up when you click on the door. You only get teleported after making a selection in the gui.
Yes. You would modify the function that gets called when the player frobs a teledoor to offer the player a GUI selection, wait for his input and then update the entity variable for which teledoor it's paired to, before the teleportation begins.
-
26 minutes ago, joebarnin said:
In a TDM script (in real time) I want to calculate the angle between two points ('vectors' in the scripting language). It's basically arctan - but there is no 'arctan' function in the TDM script language. Is there any way to call an external script or function? Like, jython?
Worst case, I can hard-code a table of values, but that is kludge-a-rific.
The way Id do it is sys.VecToAngles( point2 - point1 );
That gets you a set of angles from 0 to 360 - if you need their overall magnitude you could use sys.vecLength( angles ); Alternatively you can convert them with sys.angToForward( angles ); if you only need the angle on the horizontal plane.
You can also use anglemod180( angles ); to convert angles to the range -180 to +180. I believe that function only lets you do 1 angle at a time.
@thebighwere you able to get persistantargs to work?
@MirceaKitsuneI think you'd be better off respawning an AI with the desired properties. I highly doubt TDM allows you to alter an AI to that extent.
-
1
-
-
15 hours ago, snatcher said:
In the above screenshot secrets are missing. Not sure if secrets get displayed in the next screen or since there weren't secrets in this mission secrets just don't show up.
Secrets only get shown in the stats screen if the FM uses the official system. Before that was introduced a lot of FMs used a selfmade system.
-
1 hour ago, Frost_Salamander said:
Sorry I wasn't being clear. I'm looking at having a version of this that could be packaged with a fan mission. So the .pk4 would be placed in the FM folder, not TDM root. In that case would the game pick up those other entities from the core TDM files?
Yes, overwriting individual core entities with custom .def files in an FM archive is now uncomplicated after the overwrite rules were changed in a recent TDM version. The FM will be isolated from any future changes to the player entity, however - even if they may be rare.
-
1
-
-
1 hour ago, Frost_Salamander said:
ok thanks - so are you saying that def_weapon spawnarg could be added via a script, or not? I was going to try that anyways and see.
You can always add it via script, but itll be too late because the spawn frame code events have already happened. i.e. the lantern won't be part of the weapon index.
1 hour ago, Frost_Salamander said:This is a generic def file for player-related entities. If you overwrite a core def file you have to include everything, otherwise those entities will be missing from the game.
-
3 hours ago, Frost_Salamander said:
And in def/tdm_player_thief.def an extra weapon attachment is created for the lamp. If this could be done dynamically in a script we could remove that file as well. Has anything else in this file been changed (or do we need to get the diff viewer out...)?
Adding that def_weapon spawnarg is indeed the only change made for this lantern. In fact the file is outdated because it doesnt have the bobbing spawnargs that were added in a recent TDM version.
It doesnt look like there's a way to replace this via script, currently. Player.cpp does various stuff with the def_weapon spawnargs in the spawn frame, including setting up a weapon index. There's also stuff that seems to be called after map start like idPlayer::UpdateWeapon which reads out def_weapon spawnargs, so any dynamic approach should include appending a def_weapon spawnarg for the lantern to the player entity.
All in all, adding custom weapons is quite limited. Besides the requirement of the above core file overwrite, we only have 2 extra hotkey slots for custom weapons with no way to set them via the menu. In a previous dev discussion it was decided that we already have too many hotkeys so some alternative approach should be tried i.e. a weapon wheel like in Dishonored.
-
15 hours ago, HMart said:
Is the lamp a weapon? Unless TDM weapon system is different from Doom 3, weapon models should have the "depth hack" thing enabled, that "hack" (that is how idSoftware calls it
) makes sure the weapon never intersects with geometry.
in the code:
bool weaponDepthHack; // squash depth range so view weapons don't poke into wallsDon't know if there's a way to enable that without messing with c++, stgatilov or others may know.
This is true, but the fact is that the viewmodel only consists of a bare arm (animated model), with something bound to it (static model). The depth hack only applies to the arm model itself.
If you want to stop the lantern clipping through walls you have to make a new version of the animated arm model that has the lantern integrated into it.
-
13 hours ago, datiswous said:
Have you figured this out? Do you mean the 3d-view (so how it shows in the game world) or when you click on it and opens fulscreen? I ask this because I remember I stumbled onto something when doing fixes to StLucia (making the church book visible in color in the game-view).
Thanks for asking, Ive figured it out in SLL for making those self-fading readable items. I think it was a matter of setting the colours in the GUI stages in a certain way.
-
Are you sure that's the materials' names? Usually materials that use textures from the props folder dont have paths in their names. You can look them up in the DR media browser or in the model chooser for that model.
-
I think setSpawnArg is intended for setting spawnargs on entities that you're going to spawn. You can use it on sys followed by sys.spawn()
-
1
-
-
The most likely cause imo is that the objects are further from the map origin, the larger coordinates leading to minor rounding errors.
-
1
-
-
The family portraits were generated using AI by Wellingtoncrab, using ingame screenshots of the characters as a starting point. It took a lot of iteration to get the appearance shown in the portraits.
-
2
-
1
-
-
The lantern has seen some improvements by myself, Amadeus and Goldwell. If I shared that file on Discord its probably the version that has those improvements.
-
1
-
-
I think we can wrap up this thread now because
-
8 hours ago, wesp5 said:
What is the advantage of the volume comparison? Should I include it in my patch too? Also I don't really understand what the result of the removeFrobPeer function is, wouldn't this prevent containers from being closed again?
The volume comparison checks that the "lid" mover is actually smaller than the "body" froblock, which is probably true for almost all containers and probably only for some non-container setups. So its an additional indicator.
RemoveFrobPeer seems redundant because setFrobable(0) is already being used to completely remove all frobability. Unless some other script reenables frobability of the body?
-
2 hours ago, wesp5 said:
@Dragofer, is this different to what you provided to me for the patch already in the middle of 2022? If so, what are the advantages?
I believe my version also used spawnclasses (froblock + frobdoor) to identify frobable containers, but the volume comparison is new and may help improve accuracy in edge cases. The removeFrobPeer function is also new, but since the body is already being set to non-frobable I'm not sure of the added benefit of this function.
-
I had to pseudo-bind those clasps to the safe door by letting them translate to an absolute world position depending on their own and the safe door's rotation, via the scriptobject. Looks like a bug that this falls apart when the whole safe is rotated.
-
I believe you can set a custom use_action_script spawnarg that gets called every time you use a lockpick-class item on the door.
-
You can either spawn the entity with a target spawnarg pointing to the parent entity, or set it later via the addTarget event.
https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_Special_methods#Spawning_entities
-
1
-
-
Has anyone figured out how to change the font colour in a readable? The font images have a recolour-friendly white base colour, but the GUIs always seem to set them to pure black regardless of matcolor setting
-
4 hours ago, marbleman said:
Any reason this attachment is no longer available? I thought it was because TDM god updated, but I can confirm this still works on 2.11.
Its still available, but you have to be logged in to download forum attachments.
-
The AMA is to take place on https://www.reddit.com/r/pcgaming/
-
1
-
-
5 hours ago, datiswous said:
I don't think it's neceserry to have a hidden forum for devs (just make it read only for regular users, but at least we can follow your internal discussions), except if there are things in it that need to be hidden to normal users. I guess that is the case then. No hard feelings, just an observation. It would be nice though if it stays seperate and devs would not link to it in regular forum posts. And maybe some of the decissionmaking should be posted about outside the internal section?
I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs.
6 hours ago, datiswous said:Btw. of which members does the team consist currently? I see a lot of (I think) inactive members with dev status. Originally The team page adressed this, but it is not updated anymore (no idea why) and usually if somebody says something about that, it is ignored.
Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.
-
1
-
1
-
Newbie DarkRadiant Questions
in TDM Editors Guild
Posted
Your approach is basically how I did it with the custom AI alert behaviour in Iris. You can only steer AIs while they're unalerted, so my script would tell them to approach the source of the commotion. Once they come close enough to see the problem, TDM's stock AI routines would take care of the rest.