Jump to content
The Dark Mod Forums

MirceaKitsune

Member
  • Posts

    1910
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by MirceaKitsune

  1. What was the command to check? I haven't added most of the actual detail so it will likely increase. I positioned my lights strategically and visportal everything quite aggressively thus I'm not worried: At the moment I'm not dropping under 60 FPS anywhere which is a good sign. I added some pockets for the stalls where I'll probably have moors selling food (decoratively obviously). Also remodeled the open-air restaurant / cafe thingie to be more fancy and detailed, tables and AI and such will be added much later.
  2. Market area and restaurant with the basic outside detail done. It was thankfully easy to create a colorized / toggleable version of the new lampion model: Only disadvantage is you don't see a light source inside which sucks a little, might end up using a flame like for candles later. The ones on strings swing which gives off a nice effect as the light moves around!
  3. Ohhh: r_useEntityScissors is indeed 1 now, that must be why I feel slightly smoother FPS. A very awesome and welcome change early in the 2.12 snapshots
  4. Very nice. I get the impression performance may have improved for me as well by some 3 FPS, though that's judging based on what I remember it being from a particular position and angle a few weeks ago. Eager for entity scissors to get fixed as those were a big FPS boost, will definitely enjoy playing with that once it's stable.
  5. Here we go! Fixed a lot of little issues and included prefabs for the rustic versions: If you need to change anything particular, check the spawnargs the new prefabs override on the keypad and button entities... skins colors and sounds are all customizable, I even wrote editor vars explaining what they do when you select each field in DarkRadiant. electronic_keypad_v1.1.pk4
  6. At least the numbers in the rustic version look roughly the same... albeit those are a bit more "Times New Roman" by comparison, I used the Monospace font provided in Manjaro as it struck a good balance. Not sure what else to use for the cancel and confirm buttons... I grabbed the symbols from the existing decals for those, will see if I can use better textures as a quick solution. There are some interesting designs for sure. I initially wanted to base mine off a steampunk calculator I did in fact have when I was around 7, likely one of the first digital calculators in the world... I can barely remember it as this box you plugged into a power outlet with a bright green LCD display, must have been something amazing for its day
  7. Thanks for the feedback! I'm in the process of fixing remaining issues and missing features. Since you expressed wanting to use it I'll be making and including rustic skins as well for the next version. The sound is the keypad going into input mode, it can be disabled via spawnarg if you want. As for a screen showing the player's input, that would require a GUI setup, doable but would require massive changes I didn't have planned so I hope it's alright if I skip that... in my campaign I'll be justifying it as a security feature, someone standing behind you can't see the code you typed in nor the number of digits, you have to know the full sequence then confirm manually. Here's what I have so far skin wise, let me know how you think it looks. Remember you can use unlit skins if you don't want glowing numbers but rather have them painted, this is just the default configuration: Once I post the update I'll also provide a better description of how to set the spawnargs for the result you want, maybe default some of it in the prefab.
  8. Strange, it shouldn't be doing that. That question mark box typically appears when a model definition can't be found. Can you see and add the keypad or buttons as a func_static from the model browser? EDIT: I see the problem. The def defines the path as "models/darkmod/electronic/keypad.lwo" but I included it in "models/electronic/keypad.lwo" when packing. Sorry about that! Just change the directory structure for now. I should re-pack the pk4 but wanted to wait in case I'll update anything else.
  9. Thanks, that is good to know. Only issue I noticed with deforming glass is any other glass material seen through it will be invisible which can look ugly. Performance wise it's still good, volumetric lights remain the biggest hit so far though that's also manageable. I have a pretty crazy visportal setup which can look scary due to the quantity used but is actually working quite well.
  10. High rise hotel for Asian / Arabic city hub. Still in early stage with only this building done following two days of messing with stuff, it will be a heavily themed city. The elevator works great now and can be taken to any floor, though most only have the hallway and can't be entered for sanity's sake.
  11. Don't mind me: Just abusing our steampunk assets to create cyberpunk city hubs. I'm sure certain people can tell what this one was inspired by... hey not even Hell's Kitchen is as interesting as my design
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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
  18. 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.
  19. 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.
  20. 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.
  21. 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?
  22. 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?
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...