MirceaKitsune

Yesterday when packaging an old FM in which I used this, I noticed the script was crashing the latest TDM version. This was caused by a variable name conflict, likely a default script later using the same name. I fixed that and updated the pk4 in the first post, since nothing else changed it's still version 1.1.

Quite a newbie question: Does anyone have a link to the wiki page for setting up a map item? Its internal search isn't helping, or I don't know what to search for! Strangely enough, despite making so much progress with several FM projects, this is the first time I actually add a drawn map to my FM.

There's an interesting question with this, which if I'm not mistaken I approached in another thread long ago. I've considered making a big special project in TDM, which if I did I'd have wanted the option to distribute it as standalone: The idea was that the mission would be in the FM list like any other, but also packaged with a copy of TDM containing only the base pk4's the map uses. If this secondary distribution system were considered, I'm curious if there's be any issues with putting it in places like Itch or GoG or similar. Free of charge to respect the non-commercial licensing and wishes of the team in that regard, but I wonder if there's anything in the licensing that goes against posting your mission embedded in a copy of TDM.

Fantastic changes once again. At this point it looks pretty finished: Anything else that wasn't done yet? Especially now that a menu option was added, I'd really like to hear the developers take on this.

Thank you for the rapid fix! Updated recompiled and can confirm everything's working well once more. I haven't updated DarkRadiant in 6 months so unfortunately I couldn't narrow the problem to a more specific date.

Given the slow updates I switched my DarkRadiant Git clone from Codereader to the Orbweaver origin. Everything seems to be working well except for an immediate breaking issue: In the 3D viewport entities without models no longer display the little box you click on to select them, just the arrows showing their angle. Meanwhile in the 2D viewport, I'm seeing lines that seem to stretch infinitely to the right. Here's a shot of the issue on a FM I'm trying to finish, letting @OrbWeaver know hoping the issue is easy to replicate and fix (Linux / KDE / Wayland).

Custom lockpicks can be defined and I believe a few FM's already use them, including a prototype I have in the works where I made an electronic lock breaker. I understand the animations and item attachments can be customized however, which is a good thing: I presume a custom lockpick can use a custom one-handed animation if necessary.

Isn't it bound to N by default, or did I change it? But yes, I think that's the cvar: For me it's always been N for the longest time, I use it to toggle the green / yellow / red squares and check how portals close off each other.

Based on other comments mentioning this, as well as being busy with other things for now, I decided I'll skip on replaying this until visportals and location areas are patched. I partly want to encourage learning how to do those essentials: I think your FM's have good potential, but some of those aspects are basics without which they usually aren't ready. I don't mean to say what to do or give homework, but if you decide to fix those last aspects: Add a visportal inside every door, also around the corners of corridors to cover their entrances. See about adding at least one or two locations with different music and ambient lighting, to get a hang of how location separators work and isolating rooms. You can use the N key in-game to toggle viewing portals, they should be red when a door is closed and green when it's open or no door.

Hmmm: Could those textures not be a power of two, or use a special type of compression or encoding? I always use the highest setting and find even that low-res these days so I wouldn't notice it then, but it's the only thing I can immediately think of.

More insight on what I meant earlier with definitions being hard to attribute: Suppose you have a definition of the form... atdm:something { "a" "1" "b" "2" "c" "3" } I decide to reimplement it. I open a text editor to do so. Given its simplicity, I end up writing the exact same thing by hand since that's what makes the entity work. I can't prove or disprove that I didn't copy it since no one knows what I did on my machine. Even if I did, the result is the same anyway... would it even make a difference if I retyped it from memory? What I could do is change a few of the parameters so it's more original; Say a = 3, b = 2, c = 1. Or I remove c. Or I add d = 4. Or write them in reverse as c, b, a. What counts as good enough? There's no clear line that I can think of! Not unless it's a long definition with a lot of parameters, so it has a clear structure attributed to someone writing it... in which case one could just shuffle them, change a few values, add or remove some parameters, use original code comments and it can't be traced back via any specific elements. Other assets can be attributed as they have much more complexity and chances at being different. Like if I draw over an existing texture to change a few pixels, you can tell it's the same texture and I used large parts of it without making them myself. Of course if my texture was just a single color (1x1) I could post a copy and believably claim I made it myself and just happened to get the same one color, as it would be silly for anyone to copyright any value within the range 255x255x255 that's already been used by someone somewhere countless times.

I played this FM recently and didn't see that issue. I finished it right before the new year, I always run the latest dev snapshot so whichever that was by 30-12-2024: If something broke in TDM to cause it the change must be within the past 2 months.

Thanks for that notice and observations! Is that my port of the anthro characters? The originals weren't created by me but I integrated them myself, their author released them as CC0 and I kept the license for my fork. Scripts and defs are an interesting question: If they count as code, they need to be GPL as one of its clauses is all code distributed with the source code must also be GPL. Of course definitions may not count as code depending on who you ask, plus the engine code and game code may not be distributed in such a way as to trigger that requirement. A fun aspect is how the defs can be rewritten from scratch to say the same thing while being unique: When is it no longer licensed to the old author? Maybe if I just change the default health value on an AI it's technically my own definition... if not then I may need to redefine all parameters and make them uniquely mine, or something in between. Since no one knows what I'm copying in my local text editor, no one can truly say when a configuration block becomes unique and can be relicensed.

This reminded me of something I kept forgetting, I think this is why I ran with capped FPS: The main menu still doesn't provide an option to fully disable the cap, only to set a higher value for it. There's no unlimited value for the "Max FPS" field, you can go up to 300 then it loops back to 30. Shouldn't that option be provided, or does the engine not allow fully disabling capped FPS and still requires a limit? Actually why not mix the "Uncap FPS" and "Max FPS" settings? It might reduce clutter to have one field. Options would be Capped, Uncapped, then all the different numbers. Even more so, why not mix Uncapped and 60? Technically it should be the same thing, feels redundant to have both under different names. Unless of course there's an important technical distinction between the two modes that shouldn't be removed from the engine; Do "com_fixedTic 1" and "com_maxFPS 60" practically do anything different, any reason not to remove the legacy var entirely and use maxFPS to get the capped FPS of the old days?

Are there more details on this? I have an 144 Hz monitor, I enabled vsync and set the FPS cap to 144 as well. I figured that's the best way to not waste processing power, since how could it help to either render more visual frames or physics calculations than the monitor can display? Besides, few areas in few FM's will run at 144 FPS from a few camera positions and angles

With the Beta window closing and 2.13 release drawing near, does anyone think this can be improved at least to some extent? While it's not a gameplay breaking issue, I still see it as a very obvious problem: The AI behaves in absurd ways and often doesn't detect where it was attacked from, seemingly due to alert locations not being sent or overriding each other, in which case it's hopefully easy to find its wiring and try something different that offers better results.

The Github repository should still work. I should definitely consider further improving this mod at some point: Porting a new character this way was one of my biggest early achievements modding wise, would still love to see this used in FM's. Just so much to do including other missions I'm hoping to finish in time.

I don't know if I can reproduce that exact same issue (Linux, amdgpu) but frequently see something similar and always did. The TDM engine has this habit of making a mixture of textures flash for a frame during saving / loading / other circumstances. I can only imagine it's related to the frame buffer and some deep gimmick in the renderer. It's rare and brief so it doesn't bother me, but it would be nice if we could figure out what does it and get rid of those weird flashes.

No portals and area locations in the new version either? That was one of the biggest issues with the initial map: It's very lucky this is such a small FM else performance would be tanking.

Thanks for the update, I may give the new version a try. Curious to see how you've improved at it and what has progressed. The original needed a lot of fixes, but especially for such a small FM it's quite doable.

Cheers, can't wait for the release! For @stgatilov@nbohr1more@AluminumHaste and other code devs: With the beta cycle coming to an end and this issue seemingly breaking intended functionality, do you think it's possible for #6565 to be checked out before the release please? I wouldn't poke about small bugs, but this prevents me from designing my entity setup the way I intend it to work, without a fix such FM's won't be playable in the next release. I plan to have interactive items appear after completing objectives. For static objects it's easier to use the hide spawnarg and trigger them to show up, as opposed to using an atdm:teleport which is currently the only workaround besides using a script. Right now anything with "hide 1" doesn't have collisions or become frobable once shown; I suspect the engine doesn't load the collision model and treats "hide 1" as "noclipmodel 1" although the entity is meant to show up later. Example for frobbing: I have a readable journal I want to appear in a room after the player completes an objective. I give my journal the spawnarg "hide 1" so it starts invisible and unfrobable, set the journal as the objective completion target. When completing the objective and triggering the journal, it will become visible as intended but can't also be frobbed so the player can't read it. Example for collisions: I want a large statue to appear after the player explores an area. I add it as a func_static give it the hide spawnarg then have a trigger_once target the statue. Currently the model becomes visible but collisions don't activate, the player will see it but is able to walk through the mesh even if it's not "solid 0" or "noclipmodel 1".

Done: https://bugs.thedarkmod.com/view.php?id=6609

Saw this video and had many questions. The one about the ridable horse was answered; Turns out it's an old definition that's been commented out for years as it was never finished, hope that may change in the future as it would be great to have by default. Would love to know where we can find that werewolf monster though! Is it still available and free to use in other FM's? It looks well polished from what I can tell, but I presume there's a reason why it wasn't added yet. Speaking of which: Are there plans to work more on the werebeast? Apart from lacking some animations I noticed the bones aren't even named, like instead of "head" it's something like "bone18": This may be a problem if it's fixed in the future, in some projects I'm attaching things to the head or back using the existing bone names, if those FM's got finished before then they'd need to be patched or will crash.

Yes, this is mainly for new arrows with custom functionalities. I doubt most FM's would add radically different weapons, especially since those are generally hard to do and require new 1st person models. I also suggested redoing the weapon registration system to get rid of the old engine slots and have them like items, but that's a bigger change and no one's yet announced any plans. So in the meantime the simplest solution seems like at least registering the unused slots so a FM can modify the entities without having to touch the player definition. You can already modify the existing arrows that way, like how some FM's have a bow that looks a little different and fires faster. But if your FM wants to add an unique arrow without touching existing ones, like say an earthquake causing arrow that alerts a larger area to distract guards, there's currently no entity to bind it to.

With the 2.13 Beta around the corner, I wanted to ask about a specific solution to a specific problem regarding custom weapons. A while ago I made a post where I designed a flash arrow which I suggested introducing to vanilla TDM: For various reasons others didn't feel it made sense so the idea went dead. I didn't mind much since at worst I can feature it in my own FM's. But there's one obstacle with that I hated and wished to see removed: You have to change the player definition for the weapon slots, your FM must copy and override the whole player entity just to add a spawnarg pointing to your weapon entity. If atdm:player_base ever changes in core the FM needs to copy and update it, all just for one parameter. From my understanding there should be a quick way around this; Simply add predefined entities for those slots which FM's can override without having to touch the player def itself, authors are given the entity names for those slots and can set them to whatever they desire. The engine has 16 weapon slots and we have 5 unused, I'd reserve 1 just in case and provide the last 4 to FM's since that's a more standard number. The suggested change should be simple: In tdm_defs01.pk4/def/tdm_player_thief.def entitydef atdm:player_base add spawnargs for def_weapon12, def_weapon13, def_weapon14, def_weapon15 and have them point to a named entity by default. If for example we have "def_weapon12 atdm:weapon_custom1" the mission can define a custom arrow just by including its own definition of atdm:weapon_custom1. By default they should be assigned to null entities that don't do anything if placed as is but won't crash the game either. Here's a full example of how my imagined modification would look, curious if this works without breaking anything if anyone can check: // Placeholder for the last default weapon until one is added entityDef atdm:weapon_empty { "inherit" "atdm:entity_base" } // Empty definitions for custom weapons the FM can override entityDef atdm:weapon_custom1 { "inherit" "atdm:entity_base" } entityDef atdm:weapon_custom2 { "inherit" "atdm:entity_base" } entityDef atdm:weapon_custom3 { "inherit" "atdm:entity_base" } entityDef atdm:weapon_custom4 { "inherit" "atdm:entity_base" } "def_weapon0" "atdm:weapon_unarmed" "def_weapon1" "atdm:weapon_blackjack" "def_weapon2" "atdm:weapon_shortsword" "def_weapon3" "atdm:weapon_broadhead" "def_weapon4" "atdm:weapon_waterarrow" "def_weapon5" "atdm:weapon_firearrow" "def_weapon6" "atdm:weapon_ropearrow" "def_weapon7" "atdm:weapon_gasarrow" "def_weapon8" "atdm:weapon_noisemaker" "def_weapon9" "atdm:weapon_mossarrow" // grayman #2787 "def_weapon10" "atdm:weapon_vinearrow" // grayman #2787 "def_weapon11" "atdm:weapon_empty" // reserve this slot in case TDM adds one more default arrow in the future "def_weapon12" "atdm_weapon_custom1" // weapon slot for custom entity that can be defined by the FM "def_weapon13" "atdm_weapon_custom2" // weapon slot for custom entity that can be defined by the FM "def_weapon14" "atdm_weapon_custom3" // weapon slot for custom entity that can be defined by the FM "def_weapon15" "atdm_weapon_custom4" // weapon slot for custom entity that can be defined by the FM