Jump to content
The Dark Mod Forums

LDAsh

Member
  • Posts

    234
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by LDAsh

  1. LDAsh

    Best AntiVirus?

    I recently tried ClamWin and found it extremely thorough for scanning:- https://sourceforge.net/projects/clamwin/ It detected stinky files that other solutions failed to. I actually have a whole HDD and OS dedicated to many different (premium) antivirus solutions and scan my other HDDs as external, but usually just Windows system files. I may stop that nonsense and just stick with ClamWin because it's free AND it's truly portable. I was able to extract everything from the initial EXE, update the definitions and begin scanning. I can just copy it to my different systems easily without installing anything. It's very slow, but, I interpret that as also being very thorough. I'm also in the habit of throwing files I'm unsure about up to MetaDefender:- https://metadefender.opswat.com/ As for actually cleaning out, almost any bootable solution should do. Hiren's via Yumi is something I can recommend:- https://www.hirensbootcd.org/ https://www.pendrivelinux.com/yumi-multiboot-usb-creator/
  2. https://pixabay.com/users/paulwell-2033532/ I was going to do up full materials of these, and I still might and post back here, but I thought I'd post this here anyway. I'm personally looking for stuff that isn't overtly christian but that's near impossible. I'd likely do funky edits to avoid it as much as possible.
  3. I would say it should apply to everything except for copying and pasting to and from a surface, where the texel-scale is a feature of what it's copying and pasting. Maybe there's something else I'm missing, but that's my personal opinion.
  4. Looking through the previous releases and their changelogs, it seems this was a mistake/bug and around the same time as the "texture tool" was implemented, a long time ago. So yeah, was never intentional. I'd like to (not overcomplicate this any further and) propose a very simple hackity fix - to have an option to "automatically naturalise" new textures that are applied to surfaces, as though DR is hitting CTRL+N each time for me, behind the scenes. I don't mind if it takes a tiny chug and half a second longer to do, I would already be very happy with this workaround. I wouldn't want to both A> have this eat up any more time and B> possibly break the texture tool feature by insisting on a hearty thorough solution.
  5. For those who talk about "being consistent with other 3D software out there", you have completely missed the point. There's a reason why people don't make maps with Blender or Maya or Max, and why these software end up having plugins to make environments that always orientate around how textures are applied to surfaces. Also, why DarkRadiant is the only Radiant that has decided to go down this path, even if to compare with Hammer/WorldCraft or QuArK. Like I said on the Bugtracker - "The fact that textures are different resolutions 99.9% of the time means because they are physically bigger, cover larger brushes and take more screen real-estate." (and) "...since the dawn of 3D games, has always had a consistency." If the "Default Texture Scale" setting in 'Preferences' isn't supposed to mean anything, then why would it even be there anymore? Why was it ever there in the first place?
  6. Does TDM "suffer" an inconsistency with texture sizes, and this is what has driven DR to handle the default behaviour of apply textures so differently from ALL other Radiants? Also, only 4 votes from this community?... I know where 2 of the votes came from and one of them was mine. (*apparently my mapper-buddy whom I asked to vote here, 'accidentally' voted for option 1, heheh)
  7. Go Kurshok go Kurshok go!!!
  8. After some, let's say, 'lack of clarity' on the Bugtracker, I thought it might be productive to bring a poll to all the mappers here, to try to reach a consensus on the matter. I left out the pretty obvious choice of "these should all be options" because I really want to know what each mapper actually wants the default behaviour to be. Ideally, it would be optional. ... To explain exactly what this means:- This is how DarkRadiant post-2.20 (up until now) behaves, and for me personally, needing to press CTRL+N every time (unless the textures have the exact same sizes). This would correspond to option 1. This was the behaviour prior to 2.20, which is also for QERadiant, Q3Radiant, Doom3/Quake4, GtkRadiant, NetRadiant, etc. This would correspond to option 2. Bugtracker issue: https://bugs.thedarkmod.com/view.php?id=5633
  9. Awesome! The 3 new features I've requested work excellently and I hope other mappers see the benefit in these as well. Being able to zoom right into the smallest crumbs and work comfortably is a huge improvement, and the "border measurements" are even updated. Pasting material headers is also a huge improvement because some of our folders were taking literally 15 minutes to load. I don't think the built-in texture browser is useful for entire collections, only what the map is actually using. We use a HTML texture browser that copies the header into the clipboard when clicking on an image, so if you guys are interested, I can make a post about how to easily set that up, by automagically converting your MTR files to HTML and reading images directly from a relevant folder. Not a PK4, but I wonder if that might still be possible. Thanks for your hard work Greebo!
  10. I'm going to politely disagree with these assumptions. We're talking about "scripts" as content, not source code. If we don't make a discernment here, things become too abstract. Therefore, without a clear answer, I feel that the undertaking is just too overwhelming. One could easily use data management to tweak all of these files about to make them unique from a technical point of view, but legally and ethically it doesn't sit well with me. Also, to put it simply, trying to turn an arrow into a (delayed) hit-scan bullet doesn't sound like a good idea to me. That's the only approach I've seen attempted so far.
  11. I don't mean to sound frustrated at all. It's whole reason I made a HTML-based texture browser. The first 2 have been brought up before, the 3rd relates to that (loading some 1000s of textures takes a long time for us), and hopefully all of these would be fairly easy to implement.
  12. I decided to try, one last time, to bring up some long-standing issues I've personally had with DarkRadiant, and I have just added these to the bugtracker. Some of these things, I have no idea why they were ever changed, or at least made optional. Others, I hope some can appreciate how handy they might be as we move into the future... ____________________________________________________ - Restore non-uniform scaling for texture browser. DarkRadiant used to display textures in the texture browser with relative scaling, based on the size of the actual texture. This is important for mappers to easily see what size of texture they're dealing with. In other words, the "uniform texture thumbnail size" should be optional, like it used to be. ... - Apply textures to surfaces using "normalized" scaling. DarkRadiant used to abide by the "default texture scale" set in preferences, when applying textures to surfaces. Currently, textures seem to apply to surfaces based on the texel scale of the previous texture, such as a 2K texture being applied to a surface that previously had a 32X32 caulk texture using the 32X32 texel scale, instead of the "default texture scale". ... - Paste material-header to surface from clipboard with hotkey. Ability for a hotkey to be assigned that will instantly take whatever is in the user's clipboard and paste/apply it to the selected surface as the "shader" in "texture properties", _without_ needing to use the "surface inspector". This will allow mappers to easily use other third-party texture browsers such as HTML galleries, which with modern huge textures in huge collections is much more efficient. ... - Selection by coords. Ability to make selections by exact coordinates with a dialog, preferably with an ability for a Python plugin to help automate this process, so large maps can be easily exported by exact coordinates. Basically, the dialog has XYZ-min and XYZ-max fields, then makes a new selection using those coord values. ... - Ability to zoom 2D view in, beyond current standard. Ability to zoom in with the orthographic view to a "microscopic scale", to make it easier to work on extremely fine details, so that 0.125 unit brush will display larger than just a crumb. An option to "reset zoom" would also be required, if the zoom range is to be completely unlocked. ... - Selection Sets (faces and vertices). Ability to save specific selected objects/subobjects and items, and able to restore those selections later. Things like certain vertices selected, or certain brushfaces selected among many selected brushes. Preferably these selections would be dumped to some unique config file and support multiple of them, to save and restore multiple selection sets. ... ____________________________________________________
  13. I'd still be interested in at least screwing around with this same concept. I had a look into what freyk/MirceaKitsune were working on, but I never was able to make much sense of it. All I got working was a fairly nightmarishly tacked-together Blade Runner-themed map and never got any enemies or weapons working, like they had in some screenshots. If they had any updated packages, I can't find them, but here are the links anyway:- https://drive.google.com/drive/folders/0B4ms8lQXkym7YThOQnpiTEZSeTg https://gitlab.com/darkmodule/darkmodule Admittedly, I didn't spend a whole lot of time trying to get guns to work. Will have another look later. This still leaves the question about scripts like DEF files. I understand they're obviously copyright(ed/able) but on the other hand, there isn't exactly a billion different ways they can be created, unless one wants to get tediously neurotic about it. At what point does it become a problem to just use them? To what degree do they need to be 'reformulated' to be considered as original? Is anyone even going to care? If I just omit all graphics, all meshes/animations and all audio (to vaguely generalise), is that good enough? After all, all of these kind of script files will be heavily modified anyway. And then what is the alternative approach? To manually type them all out again just to appease some sensibilities and technicalities, which seems like a huge amount of time to spend, potentially for nothing. Maybe I'm overthinking it all but it seems worthwhile to fully clarify.
  14. I wasn't trying to suggest anything too fishy... I guess all it would really do is refactor some vital content (mainly scripts and assets) to actually launch an otherwise functional bare-bones engine, that otherwise wouldn't without some validation first, such as an e-mail address or serial. In reality, it's nothing a half-witted computer-competent person couldn't do themselves anyway, if they knew what was going on = not to interfere with the terms of the license, since it doesn't cover those assets. I guess the whole reason for bringing that up is to fortify the monetisation of the PK4s and to canary-trap the project. This is FAR from "DRM", if anyone gets that idea. I don't mean to hijack or derail the thread, sorry.
  15. So it seems like the best approach would be, to strip as much of TDM right down to the bare bones, definitely removing all images, geometry and audio, except for the basic crumbs used for technical reasons to get the engine actually loading up, and distributing that freely and openly in accordance with the license - and then trying to figure a way to monetise the additional PK4s? Would that work? It might even be possible to code a custom launcher and also monetise that, and rig that up so that the engine only really even functions when launched from that, just so you might be able to do things like serialise/canary-trap that and try to prevent folks from just sharing the assets around without paying. A launcher may also allow you to refactor certain iffy details on launch, if that's neccessary.
  16. I was under the impression that MD5/PROC/etc file formats are proprietary and belong(ed) to Activision>Zenimax>Bethesda>Microsoft, whoever... Unlike MAP files, those are specific to idTech4 and compiled to binaries. I would also assume "art assets" would expand to cover script files like .DEF/etc? Because of the nature of TDM, if there are modded files like this, no harm no foul, but to do the same commercially might be risky. But please don't get me wrong, I wish it were all straight-forward and possible.
  17. I figured I'd post this, since nobody else seems to have mentioned it. D3W (ex)regular Kristus (and associates) bring more Quake-style arena-DM action to the world:- https://www.doombringer.eu/ https://www.indiedb.com/games/doombringer I personally think this is very worthy of checking out for the old Q3A fans among us.
  18. I agree and I think it's the right way to go. It is a complex tool so I don't see the need to dumb it down for newcomers. If they feel overwhelmed and just quit, well maybe they do that a lot in their life? Having all of the buttons and fields and checkboxes right in front of you means you can sit back and just look it all over, and feel more encouraged to just toy with something to see if you can figure out what it actually does.
×
×
  • Create New...