Jump to content
The Dark Mod Forums

demagogue

Active Developer
  • Content Count

    5571
  • Joined

  • Last visited

  • Days Won

    63

demagogue last won the day on January 16

demagogue had the most liked content!

Community Reputation

1116 Deity

About demagogue

  • Rank
    Mod hero
  • Birthday 09/22/1976

Profile Information

  • Gender
    Male
  • Location
    Tokyo
  • Interests
    international law, cognitive science, piano/guitar

Recent Profile Visitors

11855 profile views
  1. These are a few threads I found. Don't forget TTLG has a long history of talking about FM ideas too-- https://www.ttlg.com/forums/showthread.php?t=134149 https://www.ttlg.com/forums/showthread.php?t=133048 https://www.ttlg.com/forums/showthread.php?t=33693
  2. I don't have the icon. My avatar image is poorly scaled in the new system, so I was trying to change it a few weeks ago, basically right after the migration IIRC, and found no way to do it. I registered in 2005, so I don't think it's registration date either.
  3. I think the wip maps were put up for adoption. Some of them were adopted for the campaign to begin with. I scripted a big campaign that really excites me, just called The Dark Campaign. Basically it opens with a siege of Bridgeport from the Jazirats (the Arab/Abassids equivalent), and the player is Pakdamani (Persian/Zoroastrin equivalent), which is Jazirat territory (but his ancestors left for Bridgeport to escape persecution) but most people in Bridgeport don't know the difference, so he's kept in the Jazirat quarter which is closed off like a ghetto. So the first mission, the player has to break out of the ghetto and try to escape the city (I like the image of flaming boulders from Jazirat catapults striking buildings as he's sneaking down streets to get out). But on the way out he gets tangled up in the battle preparations and things get complicated. But then again I script & map out FMs all the time. I probably have dozens of maps drawn out & stories written. It's the building part that's the trick!
  4. I can't encourage you enough to give it a try. You definitely have a good eye for the look and feel of our world, so I'm certain you could make a great FM! And if it's any help, Dark Radiant is muuuuuch easier to work with than Dromed. The results also look a lot better. And you also have us who will help you as much as we can.
  5. Really cool! I only remember somebody did a Thief texture pack once, but this is a much bigger thing. Thanks for your work!
  6. I learned (or re-learned) coding with DoomScript and TDM's C++ sourcecode, and I found it valuable. Maybe the best thing that makes them good for learning is just that small bitesized chunks of code can do really cool things that you immediately see in game. It's better for motivation. I wouldn't defend C++ as "good or fun to work with", but I'd at least acknowledge that it forces discipline early on, whereas something like JavaScript might encourage you to be sloppy. All of that said, I think Python is the best for casual programming and is probably best all other things being equal, but you don't see awesome games you want to play around with the coding for in Python.
  7. The model is going to be listed in the spawnarg list, and I think you can just use the address from that. (If it has the address. I don't have DR in front of me now to check that.)
  8. Just use the model and not the entity. That is if you want it to be forever inactive, like it's just a scrap of metal in a heap. If you want to activate it later and have it start "off", then I don't know offhand, but the first thing I'd do is search the spawnargs (click off the box that says hide hidden spawnargs) for one that looks like it does that job, and change it so it spawns turned off but might be turned on later (however it's set up to do that; I'd first look up if that's a thing it does, and then I'd try just changing the spawnarg, and if nothing works I'd just teleport an active one in its place by script). Edit: You could change its visual and audio acuity to 0 so it's blind and deaf. Then it's "on" but doesn't do anything.
  9. Just use the model and not the entity. Edit: I don't see how to delete this. See my revised answer two posts below.
  10. The system originally comes from Thief 2 (and probably Thief 1 and Ultima Underworld before it), and Sparhawk did a pretty good job porting it to TDM, considering he wasn't a T2 mapper so was just going by hearsay. The one tip I sort of remember is that if your stim is static and diffuse and it's sometimes not firing, it's sometimes better to use a proximity stim than a touch one, since a proximity stim will always trigger.
  11. I don't know where to post this, but it feels like it doesn't need a thread of its own. I found a cool article on the history of the BSP Tree algorithm from its origins in military sims to Carmack's implementation of it in Doom. Of course BSP Trees are used in Doom3/TDM as well, so this is in our direct lineage, and I think it's good of us that work with TDM to know some of the backstory to our ancestry.
  12. The mechanic in Thief2 was the big bots were ko'd by a waterarrow to the boiler, for logic and gameplay. (I can't recall the small and child bots.) We can do something different but in that vein. We might make a kind of "command" widget for our bot and have it ko'd by blackjack only to that. It's a challenge but has a gameplay logic and it explains why one bj hit could work. So that's my candidate proposal.
  13. I saw the idea as equivalent to the old rule that sound assets should be without environmental effects in the vanilla version, since the effects should be added when it's put in-game, and grime is a kind of environmental effect on top of the original. I think the idea is, with a clean original, you can then tailor the asset to different environments or vary the amount of it. But practically speaking, assets are made to fit with certain environments that fit our gameplay and aesthetic, and it's probably better to just tailor the grime to the asset in its native version than relying on generic grime decals that then get overused and aren't always very fitting to the asset. So I'm okay with the trend in that direction.
  14. This guy's photogrammetry work (3D modeling from photo scans) inspired me today. https://sketchfab.com/miguelbandera/models It's so naturalistic. I wonder if there's a practical method to get a photogrammatried scene in model form and overlay it on top of our brushwork. I'd love to have some scenes like this for an FM. edit. It's a mix of highpoly but low res. It might be best actually for background cityscape and architecture the player doesn't get too close to.
  15. That's one of the most characteristic and consistent bugs in this whole game, and the one (or nearly the one, I think I brought it up on page 2 or 3) that I started this very thread for, the so-called black walls of death. Yeah, it usually means complex brushwork broke the boundary between leafs, like because of a rounding error... Things like tiny slivers, either overlapping, or there's a sliver gap, or weird angles intersecting, or things going off grid. And the culprit brushwork is usually right where the artifact starts so you know where to look. And the easiest way to fix it is usually to just rebuild the architecture around it with simpler, flush, and on-grid brushwork. That's a more descriptive way to just say "yeah, what he said". Generally speaking you want leaf-sealing BSP brushwork to be flush, on-grid, all 90-degree or anyway not-sliver-angled simple affairs (maybe not always, but when there's no better reason not to, and especially around leaf-border areas where the sealing matters) and leave the slivers and wonky angles and detail-work to non-sealing architecture you convert to func_stats that just overlay on top of the sealing brushwork. Edit: A leaf is the area sealed inside of visPortals if you didn't know, but I think that's an early thing everyone learns.
×
×
  • Create New...