MirceaKitsune

Thanks. The issue was my ambition to make everything typical scifi which would have taken far too much effort: I'm likely going to obtain an unique and interesting mixture by sticking to the vanilla assets with small modifications and my own additions. Instead I'm going to have story based reasons explaining the style... for example, bullet weapons being banned in an international treaty so the world is still using swords and bows by the time it has computers and 16-bit music, the special arrows classified as nano-technology serving as a replacement / workaround to guns being banned from the general public. Let me know if anyone has an answer to the item question too: Was tempted to make a vending machine next but don't feel like writing a scriptobject for that as well, thus I was wondering if there's a special coin item I can define and have it deduced per frob using conventional triggers to teleport the items out of the box.

I figure this wasn't needed until now. The reason I ran into the requirement is my cyberpunk campaign uses custom music: I have a few chiptune tracks with different versions, like one for fighting and another calmer one. I set a song for the outside and the other for an underground area. Were this implemented you'd hear the transition smoothly when traveling between the two, as it stands the new song always restarts when walking between spaces which is a little uglier.

Keep in mind this is for a cyberpunk campaign I'm creating, which will have computers and other scifi elements mixed in with the existing assets. For the standard theme this should in fact use different models or skins to look more rustic, possibly removing the screen and replacing it with a bulb. The screen is a decision I went for later, it was meant to be a sort of neon lamp for the color to indicate its status... in the end I went ahead and added a screen as well which you can set to nodraw to disable.

That's also a great idea to simplify the system: Technically we can just use one bow and re-texture its arrow to represent the projectile currently selected, and of course affect what actually gets fired with that. Technically we can even make the flashmine / flashbomb its own weapon on the 4th slot, finally we'd have a first person view of throwing / placing it. The ideal solution seems like giving inventory items and frobable in-world entities the ability to change the properties of a weapon, both visually and its stats or what it fires. This would also facilitate mods like upgrades that make your arrows go further or have more damage, would go well with the skill system I wanted to create anyway. Personally I wouldn't suggest any functionality changes to the default sword: It's still what you should start with unless the FM specifies otherwise. With the idea I have in mind, if you say defeat a thug by either killing him or knocking him out, he drops the movable knife to the ground as is already the case... but now when frobbing it, your sword would be set to take on the properties of a dagger, while the dagger on the ground gets replaced by the shortsword you were holding. In terms of usefulness this is mainly a detail for immersion but not only; It would have practical uses if you go for combat over stealth, given each weapon version would have slightly different stats and speeds, different players would find it better to switch to different weapons in different areas and for different enemies. Those who are in the boat that combat doesn't matter because stealth is the primary component of TDM likely won't care... for those of us who prefer a "use your own approach and whatever the world gives you" technique, this would open up new possibilities and add in a whole new fun factor.

Two questions for me: First what is the easiest way to create an in-world entity which requires an item when used? This means the entity is frobable, when used it checks if you have a given stackable item in your inventory... if you do it triggers its targets and subtracts 1 of that item, if you have none left no targets are triggered. I can make a scriptobject if necessary, but this seems like something basic which I've seen done before and should already possible just that I haven't found how. And something else; I have two songs which are structurally identical, same length and content just a variation in tone. I assigned them to two different zones the player can walk between directly. Is it possible to make it so when you step into the other area and ambiance changes, the new songs fades in from the same position the old song is at so you hear a seamless transition? By default the song in a new area starts playing from the beginning, I was wondering if there's a flag to always run the timer for inactive ambiance so when you return to a zone you hear its song resume as if it had been playing all along.

The electronic keypad is something I've wanted for a long time, along with laser tripped alarms which are next on my TODO list. I'm happy to announce they're a feature I just finished as part of a futuristic campaign I began working on! The version included here is extracted into an individual pk4 for other mappers to use. I may improve mine over time like using a GUI for the screen, for now this is a simple but finished version which does exactly everything intended. It consists of the custom script and def, models created and exported from DR reusing existing sounds and textures (only text labels had to be created), as well as prefabs for model sources and quickly placing a keypad on your map (broken or unpowered versions included). The device is operated using 12 buttons forming a numeric keypad inspired by old mobile phones, stand close look at each key and frob to input: Give your keypad a "text" spawnarg to set a password (multiple codes supported), entities targeted via "trigger_on_success" will execute when the correct code was typed, you may also set "trigger_on_fail" spawnargs to trigger targets when a bad code was written. Existing input can be cancelled with * and must be confirmed using the # key at the end, once unlocked pressing any key will re-trigger targets and lock the device back up. One aspect I'm unhappy with: I couldn't find a way for the script to directly access the entity triggering it. Because of this I had to define an additional "atdm:target_callobjectfunction" targeted by buttons which itself targets the keypad. This is only an annoyance for sanity's sake as I hoped I'd only need the keypad entity and individual buttons, yet there's also a little yellow cube sticking around which every button has to go through. Let me know if you're aware of a way to work around this; I know the script can use sys.onSignal(SIG_TRIGGER, self, "foo::bar") to run a function when triggered, but there doesn't seem to be a way to access the entity doing the triggering which is required to know which button was pressed and get its symbol. Here's the initial version with a few screenshots of how it looks and works. Feel free to use them in your FM's and share the result here! I'd love to see missions where you need to find codes in readables and remember them to access places, even having to piece them together from different sources... remember you can also use short passwords which are typed like an SMS hence the letters on the keys, for example "abe" would be "11122" (a = 1, b = 11, e = 22) 0 acts as space though I wouldn't write long sentences as they can be annoying to type in. electronic_keypad_v1.0.pk4

Thanks for clarifying! Oh I forgot I spoke about this once, I do remember I thought about it before but forgot bringing it up. Indeed the base declarations would need to be redone... I presumed this would only be the internal ones thus everything would be backwards compatible. Getting them out of the player's entityDef was my main concern: That feels like a legacy limitation similar to the 60 FPS cap, a case of the way things were done back in the day but no longer need to be done now. The question in my mind is what do weapons do differently from other items that requires them to be declared so differently. On my idea to allow multiple sword types, your comment helped me realize this would already be possible in an easier way: Granted we only want the player to carry one weapon of a given type at a time, this can be done by changing the model / skin / stats of the same sword weapon and blackjack. So if you're holding the sword then frob a builder's hammer, the hand with the sword lowers itself out of view then the sword turns into a hammer then the hand goes back up without the camera noticing a change. There isn't any limitation in the engine to reskinning a weapon in realtime correct? There's only one problem here as far as I'm aware: The md5mesh for the first person view hands also contain the sword as part of the model. The sword part of the mesh would need to be deleted and only the hands kept, then the sword attached as a separate entity using the same lwo model as the longsword you see guards holding or on maps as a decoration.

There's another ability this would make possible which is another reason I wanted the suggestion up, always felt this would be amazing in terms of immersion and interacting with the world: If you look at Moveables/Weapons/atdm:moveable_* you'll see a lot of weapons the AI can wield. Wouldn't it be great if instead of just the longsword the player could use any of them and benefit from their different stats? Imagine picking up the hammer of a builder and using that to whack enemies, or the bent sword used by moors, not to mention the dagger I mean come on you're a thief you should be able to use a knife! We can in fact achieve this without needing a custom set of hands per weapon: We only need the existing hands and animations, the weapon just needs to be attached to the hand bone as a separate entity. Any sword you pick up would use the same hand mesh and animations, all that differs is its weapon model the sounds and functionally stats. For example the dagger would work just like the sword except you shouldn't be able to parry with it, stat wise it would have a faster attack rate for slightly less damage. Only issue I see is long and heavy weapons like the lance would require both hands and different animations; Unless someone feels like animating them those can remain off-limits to the player, we have a convenient excuse in that the player is a thief who isn't trained in using heavy cavalry stuff. For items a similar trick can be used to make them visual: Have a first person hand as its own md5mesh / md5anim and give it a few holding animations for different grips. Items would be attached to the hand bone with an offset: Potions, readable books, keys... all can be rendered in the hand by simply changing the model of the attached entity, if needed just using a different finger animation that matches the size of the object being gripped.

I'm aware this might have been thought about before and there's probably a reason why it hasn't been improved. Since many good changes are happening including lifting of legacy limitations, I felt this is worth thinking about granted it's not too breaking. There are two technically independent yet related subjects I wanted to address here, both with the same goal of better unifying weapons with other inventory items: The internal weapon definition system, then how GUI and inventory could be improved so weapons are treated more closely to everything else. Technical limitations: TDM still uses an old and limited method built into the engine to define weapons, something idTech has done since its early days. This comes with a few problems: You can only have up to 16 weapons registered, weapons need be listed in the global definition of the player entity, and it's simply redundant. I was wondering if as a target for 2.12 or later, it would be possible to remove the legacy weapon slots from the engine and store weapons like other items; This would allow a FM to define any number of custom arrows / guns and do so without having to override the player def, just define your arrow like you would a custom lockpick as a derivative from its base class. It doesn't feel right to for the engine to designate two types of items ("weapon" and "literally anything else") with the former going through a special hardcoded registry while inventory items already do the same thing more simply. Only ability I know is unique to weapons is drawing the first person hands and animating them: Items would need a generic ability to define a md5mesh / md5anim set for hands when selected and operated, which would be awesome since other objects could use this as well. Everything else seems like it should fit into place: The arrows are just a projectile spawned at a given position angle and velocity, technically you could already create an inventory item that spawns a flying arrow when used (I think)... the ammo and projectile are already defined as standard items too, it's only the "shooter" that uses the legacy engine registration as an extra dependency. Inventory wise weapons presently have a special status, in that they can be selected and operated independently from items: I'm aware changing this may disrupt what players are used to so changes are questionable. I support having a single selector for cycling weapons and items together, even merging the "use item" and "fire weapon" keys to operate whichever is selected: If we did that we could technically implement a first-person hand displaying whatever you have selected... some things like the lockpicks may need a custom animation but imagine how good that would look when picking doors, heck you could even see the bag in your hand when "loot" is focused! Only real complaint I see is some players want to keep an item handy without having to deselect it when switching to a weapon, like being able to quickly use a health potion while drawing the sword to attack: We can solve this by having hotkeys for more essential items similar to the lantern and spyglass, like a "use health potion" button so if you have a potion you may instantly heal... we'd be freeing up three key-binds with an unified inventory anyway (prev item, next item, use item) which is also an advantage. Do share your thoughts and if you can think of a better way.

Thanks. The issue is that once an entity is spawned in the map it gets an unique name, like "atdm:whatever" becomes "atdm_whatever_1"... seems you can't work around that in a mere def, but at least there's a script function for it so that's great. For now I went with a prefab where buttons will be independent, that's clearly going to a better option in the end; If things go smoothly I may finish keypad doors for my campaign, could share that separately on the forum in the meantime as I'm sure others would like to play with it One more question in the meantime: With the current entity setup, is it difficult to define a custom lockpick and make it consumable? I see I should easily be able to create my own "atdm:playertool_lockpick_base" derivative, giving it an unique letter for "lockpick_type" which should then work in any door's "lock_picktype"... I'm also seeing a "type" spawnarg with its own letter and wonder what that's used for as well. But what about making it consumable? So that like health potions, you can pick up multiple instances of the item, then each time you unlock a door via picking or successfully apply the lockpick to the door one item is subtracted. For what seems relevant I'm seeing "inv_cont_use" / "inv_item_count" / "inv_stackable" spawnargs, are those everything I need or would the lockpick script need changes?

I'd like to make an entity using a custom scriptobject, which is going to require a set of buttons to be pressed in the right order. At the moment I'm running into an issue similar to doors spawning their own door handle: I want the entity to spawn the buttons itself, but if it does so via def_attach how can I make the buttons target the parent entity when pressed? Is there some solution to this limitation... either to target a referenced entity that's placed on the map at runtime via def, or in this case could I at least make the scriptobject on the main entity identify the buttons without them having to target it?

If it's a WxWidgets / GTK issue yeah, it would need to be reported with them. I might look at that code and in case I understand it enough make a few changes to test and recompile. At worst maybe there's a specific trigger we can work around without issue.

A little detail I'd like to sort out if possible: I've started working on a campaign which plans to use the existing style and assets in a more futuristic setup. One thing I'd like to make is light switches with an LED that shines in the dark. Model and skin are no issue, but I was wondering if there's a way to make it turn off when the light switch is enabled: Can an atdm:mover_lever have a skin_lit and skin_unlit like lights? If not I'll either have it always on, or attach the LED as a separate entity maybe giving it a small light too.

Some prefabs need correcting after adding them to your map: I usually Make Natural the textures on brushes where possible or snap stuff to at least a grid unit of 1 with lower just when strictly necessary. Other than that they seem to be in proper shape: Will likely make more of my own over time which will also be designed with cleanness in mind.

I know this is probably not the case but figured I could hope: At the moment is there support for non-english characters inside readables? In my campaign idea I plan to have the player travel to different places in the world, thought of leaving a few messages in different languages to make it more immersive... problem is that to my knowledge there are no Chinese, Russian, German, etc. characters. Same with common smileys and symbols, it would be interesting if you could use those in places... I figure anything non-unicode would just appear as an empty space or box however.

A quick one I can probably add to this list: Could and should we have a script to detect intersecting brushes? I always want to go for a clean style of mapping, but as you add to a structure you often need to cut / merge brushes as you add more detail: If you aren't careful you can end up either with unwanted holes or walls cutting through each other... while the former isn't possible to automatically detect, the later should technically be. Also useful would be a script to detect brushes that can be merged, if they form a convex shape and the textures on parallel faces are identical: I always look for those as well, it's rarer for any to get lost but there are sometimes cases.

Weird. Thanks for confirming that though, one useful piece of information. So it might only be doing it on KDE / Plasma in this case. I wonder if it would be reproducible on a virtual machine, normally it should only drivers and high level stuff differ... if yes it would be possible for someone to test on VirtualBox, would require setting a VM up but not changing the actual OS. Does anything come to mind in terms of things I can try myself? I always compile DR from Git: If a specific line of code comes to mind feel free to suggest a change and I could recompile and test with it.

Easier to manage, especially since I plan on throwing time into a large campaign where I'd reuse copies of a lot of complex stuff: If I want to make a change I just edit one def and update it on all maps. Might try this one out and see the results: IIRC def_attach is the reverse of bind, thus a door handle should recognize its door when addressed this way. Edit: From what I looked in existing defs it's not possible. You can specify a door_handle spawnarg but it must be an entity in the world. I'm going to define a custom default door to change some basics, but it's clearly best to place the door handle manually with the current setup we have.

Another little thing I'm looking to address: I was wondering if it's possible to define a door with a handle as one entity in your FM def. The reason this might not be possible is it requires two entities, an atdm:mover_door and mover_door_handle: I could def_attach the handle to the door with the proper offset... issue is I normally need to specify the door entity to bind to by name, does using def_attach automatically bind in a way that connects the handle to the door and has it move?

No, that setting makes no difference: Same behavior both when running DarkRadiant in Wayland mode (always), or when running it in X11 mode on Wayland session (starts after using the clipper tool). The good news is I seem to have discovered what's triggering this... not in the code which I'm not familiar with, but in practice which seems obvious now. The bug seems to be caused by the mouse cursor not being locked during movement, the pointer moves together with the camera which doesn't happen under normal circumstances. This surely causes DR to interpret it at the new position each time and accelerate the further you go from the original position of the pointer when the view was first clicked. The exact behaviors (normal and broken) I'm seeing in both the 2D and 3D views as follows: Normal: Right-clicking causes the mouse cursor to disappear as you move the view around. Once you let go of the mouse button or click it again to disengage, the cursor reappears at the same position on the screen as before you clicked. Broken: Right-clicking no longer causes the mouse cursor to disappear while the view is controlled (a separate but minor annoyance). As you move the view around, the mouse cursor also moves on the screen instead of being locked.

Thanks: tdm_custom_scripts.script it is then. Yeah I can #include each separate scripts from there then. Otherwise I asked this on Discord but no one knew an answer yet, and since it's useful to know during map design I'm putting it here too. I had a few questions about light optimization, surprisingly I never checked this to know for certain how it works practically: When you use a spot light with the light_target spawnerg set, is it more performance effective than an omni light? I'm presuming it only calculates surfaces within the cone, rather than in all directions emanating from the point like standard lights. Or does it still calculate in all 6 directions regardless? Are light entities that poke through walls discarded when their room is closed off by portals? Obviously if a light shines through an opening it will be rendered even if the room it's in is closed off, but does the engine know if that light has no path to shine in your current room? Best example is a torch placed on the back of a wall in one room, you're in another room that shares this thin wall with the first room, the first room is closed off by the portals: Will that torch still use up FPS just because it touches the room you're in, or does the engine realize the torch doesn't intersect the necessary portals to form a possible path to your location along the way and can thus be ignored?

Had a question I should probably ask about to prepare: When you create a single FM you may have a custom script by naming it the same as the map, like my_fm.map / my_fm.script. Now if you're developing a campaign, can you have a script that's loaded for all maps in that campaign? I only remember using tdm_custom_scripts.script / tdm_user_addons.script and forgot which does what... don't want them overriding actual addons though, are they the right choice for campaigns?

Is there any news on this please? @greebo what do you think it might be? I wouldn't poke too much about an issue, but since I switched to Wayland I'm struggling to run DarkRadiant properly due to this one problem even with the X11 mode override to mitigate it: As Frost Salamander confirmed the exact same behavior also happens on Windows, albeit more rarely and triggered by different circumstances... something must be breaking DR's interpretation of mouse input in a special circumstance.

Was going to ask why in the world such a nice effect isn't included in vanilla but PeterSpy answered that. Can't wait for TDM to finally have PBR with this effect and more! Let us dream for 2.12

This is a consequence of not yet having a proper reflection system: Windows use a static blurry cubemap to simulate some level of reflection. This will probably be improved later someday, for now you'll have to use a window without any reflection at all or with the mirror pass for it. Don't know if there's one by default, if not it should be easy to make a custom material.