Jump to content
The Dark Mod Forums

Dragofer

Member
  • Content Count

    614
  • Joined

  • Last visited

  • Days Won

    57

Everything posted by Dragofer

  1. That atdm_puddle entity is merely a patch-like model that fits to the shape of the lake and bears one of the 2 water textures. You can just as well use only patches, as I have done. Regarding what's under the 2 surfaces, it might be that the water brush top is very close to these so you might not see it just by zooming the camera in. Maybe you could try shift-clicking + hiding one thing from the lake at a time in your orthoview until you find an entity that could be the water brush?
  2. The double surface sounds similar to what I have for my ship showcase map, where one layer displays the reflection while the other layer blurs (lifted from Arcturus' castle & pond demo map for animated grass). The easiest replacement would be to delete all traces of Bikerdude's water and then duplicate your own water from the other part of the map. If you can't see Bikerdude's water box, maybe you have the filter for nodraw or visportals enabled? If you sometimes fall out of your water I'd have two possible explanations: A ) the water brush doesn't reach all the way to the bottom B ) your water entity consists of multiple irregular shaped brushes, i.e. triangles. This was problematic when I custom-fitted water brushes around my ships because I'd keep falling out of the water. I got it to work by, step 1: recreating the broken brushes from scratch (copy-paste does not suffice), step 2: giving each brush its own water entity.
  3. This was leading up to Halloween in 2015 so details are fuzzy, but IIRC an AI will start patrolling if it's assigned a target after having had none. So I had to clear all the AI's targets and then add an inaccessible path_corner node as a target. There were almost certainly more steps involved, it was all very fumbly and I settled for a simpler solution. I consulted with grayman at the time to find out that there's no clean way to stop an AI patrol. I'll put that into the bugtracker. Edit: bugtracker (bugs.thedarkmod.com) still seems offline.
  4. This is something I used for a custom AI script in an early alternate version of Down by the Riverside (Tales of the Riverside), which you can find [url=http://forums.thedarkmod.com/index.php?/topic/18402-fan-mission-down-by-the-riverside-by-dragofer-20160925/&do=findComment&comment=407828]here[/url]. The script is able to make an AI stop patrolling upon reaching its next path node. If you want the AI to stop immediately it would involve teleporting the path_corner to an inaccessible location, as I recall it. (I was aware of the StopMove event but in my experience it only caused the AI to twitch while carrying on with its patrol. Might be good for a free-roaming AI like a zombie though?)
  5. @Hagatha When I played the mission I also tried to get past there to no avail, ended up noclipping past only to realise that you're not supposed to go this direction as it's a one-way path. I don't remember the correct route anymore unfortunately, but if I remember correctly you should look into some of the openable windows.
  6. Technically speaking what you want to do is very simple. All it takes is to open DarkRadiant twice to open both maps, then select & copy-paste (via ctrl c & v) between them. Names get updated automatically, so if both maps have func_static1 to 100 then the new arrival's func_statics will get renamed 101 to 200. If there are spawnargs referring to these names they conveniently also get updated. What you'd have to watch out for is that you'd probably have multiple ambient_world lights, location setting entities etc. Whether this is advisable at this point is another question: 1) For your first map you could reasonably expect to have your hands full just getting a feel for how all the parts of a complete mission work. The generally advised practice on these forums is therefore to aim to get everything to work on a smaller scale, as each step already takes longer than usual if it's your first time and mistakes are easier to correct, before moving on to more ambitious projects. 2) Each mapper works differently. I've taken over a harbour map from this thread but spent considerable time figuring out how the map's been put together and then reshaping it into a state I personally can work with. For example, rooves and subterranean brushwork were highly irregular, both requiring a redo before I could add attics & basements without getting confused. This kind of work is something I'd recommend putting in if you find a map idea here that you want to see to fruition (i.e. I have a high affinity for maritime environments and also had a large ship looking for a new home). But if you just want to have some more content in your map then I'd say it'd probably be more wholesome for you to use (mostly) your own work. This is just my personal opinion based on my own experience, though.
  7. Personally I find torches to be a crude form of lighting that would feel overwhelming in places where people live and work, with their bright light, crackling sound and open flames. That's a matter of aesthetics, so there'll surely also be mappers to whose taste it would be to employ torches in a more versatile way. What I wouldn't do - anymore - would be to let realism be a major factor in the decision. In my early days I went to some lengths to ensure my map was realistic enough, for example only adding moonlight to rooms which had windows actually facing the moon. At some point I realised that such striving got into the way of building my maps in the best possible way, seen from the gameplay, aesthetics and time-efficiency perspectives. In that particular example, the poor lighting in the non-facing rooms would be much likelier to be noticed than the more realistic portrayal of the moon's lighting. Realism does do a lot of good - TDM and Thief arguably simulate stealth and industrial society fairly realistically - but it can be taken past a certain point where small improvements come at a cost in other areas. Thus, if a mapper's intuition is that a torch would fit best in a certain locale, then I wouldn't want to interfere with that.
  8. The dilapidated old house at the western waterfront of Wrecker's Reach. A local glancing upwards as he hurriedly walks past in the dark of night might notice a window lit up brightly from within, but he would rather not think about how this could be. (This is also the same house that'll feature an excerpt from an eerie short story written by Spooks.)
  9. Brilliant, I'm very pleased with the direction you took this: not only a gentleman scientist's of an early design, but also a beautiful wooden box for it to stand on. Please do make this available to the public as soon as it's ready. My thoughts exactly
  10. Figured out this was caused by targeting the doors from lamps. My doors have windows in them that used lit & unlit skins, and that part works alright. But lamps also will open/close the doors in certain situations: 1) if the door is open and the lamp is extinguished the door closes. 2) if the door is closed and the lamp is relit the door opens. And a second bug, which was at the root of my problem I posted about: if the lamp is extinguished at map start the door will start way off elsewhere. Didn't make the connection between lamps and doors until now because I always tested the skin changes only by extinguishing lamps while the doors were closed, which does not correspond to one of the 2 situations above. Will post a bug report of this later on.
  11. Anybody got some experience with troubleshooting doors that start way outside of their frames? I've got a couple that start on the floor below, then when frobbed they slowly float back to where they should be. While they're floating they can still be 'opened' & 'closed' normally. It's variable which doors are affected, it changes every few days.
  12. Thank you duzenko for looking into this, I've attached a test map with some of the offending interiors. leaks.map.txt
  13. Yes, it would need some careful thought to figure out whether culling of models from closed visleafs could become more effective without having unforeseen consequences for models that touch multiple visleaves. However, the problem exists also for objects that are fully contained within a single visleaf. Patches that are flush with sloped or diagonal sealing geometry are highly likely to leak despite having all their vertices precisely along the line (my ship interiors use 1:2 and sometimes 1:4 slopes on an 8 unit grid). Well I'd assume the engine draws a box around each object and finds that it intersects the diagonal line into another visleaf. An opt-in would be immensely helpful, i.e. a spawnarg to tie an entity to its origin's visleaf, or until the next door (i.e. if the object spans a multi-visleaf hallway). The simplest form of this would already save hundreds of drawcalls in multiple places for me.
  14. Something I'd wish for would be for there to be no more leaking of indoor objects to exterior visleafs. Particles are especially notorious at this. My harbour has several hundred drawcalls coming from the ship interior's sacks, beams etc. despite being built in quite a clean way. Maybe a rule could be made that if something's bounds are 90% or more within a closed visleaf it doesn't get rendered? I do remember SteveL having offered to look into this some years ago
  15. Wonderful, this is pleasant to come back to after a weekend away. The upright design together with the wooden box stand does work quite well together. This is certainly important too, and that's a formidable collection of slides in that chest. My own idea was to go with something more modest like these boxes in the image below as they'd fit better into a ship cabin, but ultimately the choice may depend on whether or not you want the individual slides to be moveable and player-usable. Certainly no shortage of vintage microscope slide designs - remarkable how artistic they were compared to what we work with today: If the player should want to look at the slides under the microscope the Stim/Response system could be used to insert it when it comes close enough and change the frob response of the microscope to trigger a camera when frobbed. Not really sure if this is something the typical thief would be interested in, though.
  16. Thank you for sharing these additional steps, it works like a charm now - I do import meshes quite often, and additionally some shading issues I was having went away now that I started playing with the auto-smooth slider. Didn't need to use those settings before, but I believe this is just a more advanced exporter that takes more factors into account.
  17. Thank you for the great work of providing up-to-date exporters and refining them, it really is much appreciated. Unfortunately I can't get any smoothing with the scripts in this thread, though. Got the latest Blender 2.79b and the 2.79 versions of the scripts from Orbweaver's Github and tried various combinations of checkbox settings. Is there maybe something specific I have to do, beyond setting face shading to smooth and ensuring no double vertices? I've seen there was discussion of going either by smoothing groups or vertex normals in this thread.
  18. Maybe noclipmodel 1 will work? Also, could it be the def_attached items (primarily the head) are what's colliding because they're still solid? You could look up the relative names of the attached itemsby looking at the name_attach spawnargs, then put spawnargs like this on the AI: set noclipmodel on *name* 1
  19. Wiki: Systematic Method for Adding Pathfinding to Uneven Terrain During some recent browsing of the forums I came across not one but two members posting about the difficulty of applying monsterclip to uneven terrain. I realised I could share my approach to making such terrain passable for AI, which Ive first used for the beach segment of One Step Too Far. ​ Concept​ This will create a grid of monsterclip floor brushes. The top surface of each brush is raised or lowered to match the height of the terrain at that location. Steps are added wherever theres a great difference in height between two adjacent brushes. The map boundary is traced by brushes created on an 8-unit grid.​ ​ ​ 1. Preparing the grid​ Start by making a large monsterclip brush that covers your whole terrain. Its height should span from the bottom of the map area to above even the sky, so that itll be easy to click on from above.​ ​ Go to your preferences and ensure your clipper tool does not use caulk. Switch into top-down view and use the clipper tool to cut this brush up into blocks so that you get a grid. A good size would be 192x192 units per block, but you could use smaller or larger blocks if your terrain is highly uneven (i.e. boulder landscape) or quite flat, respectively.​ ​ ​ Delete any blocks that do not touch your terrain. If you have a structure with worldspawn brushes within the terrain, like my mansion here, then enable the filter for entities and use the clipper to remove those parts of the monsterclip brushes that overlap with the house. ​ ​ 2. Using the grid​ Disable the filter for entities, set your DarkRadiant grid size to 8, go into side-view to select the protruding tops of all your monsterclip brushes, hit v to swap to vertices mode and lower all the top vertices just enough that the highest point of your terrain is still covered in monsterclip. ​ ​ ​ Now use the resize tool to lower the top surface of each block so that it intersects with your terrain. This doesnt have to be very exact because you get around 30 units tolerance in both vertical directions. If you see that a brush is completely covered by impassable entities you can delete it.​ ​ ​ ​ 3. Making steps between the blocks​ Some blocks may be considerably higher than their neighbouring blocks, so that steps must be added. Not all AI can handle 16-unit steps, so itd be best to use 8-unit steps for this method.​ ​ Start by hiding everything except monsterclip: enable the filter for monsterclip, select & hide your whole map, then disable the filter for monsterclip. Now use the camera view to identify where steps are needed and add them as shown.​ ​ ​ ​ ​ 4. Monsterclipping the perimeter​ Unhide your map and create a tall brush that spans from your lowest block surface to the top of the map area, which you then delete again. This will inform DarkRadiant how tall you want brushes to be that you create while youre in top-down view.​ ​ Switch to top-down view and trace your terrains boundary, i.e. trees, rocks, walls with monsterclip brushes on an 8x8 grid. Use the camera view to ensure that these objects are completely behind monsterclip: AI can get stuck on any pieces that might stick out, such as branches. Objects on the terrain such as rocks and trees can be monsterclipped normally.​ ​ Remember that AIs need over 32x32 units of space, so you should fill up any alcoves that are 32 units or smaller.​ ​ ​ ​ Testing​ If youd like to test this you can have an AI chase you row-by-row, then column-by-column while you fly backwards with noclip enabled. The AI should always follow you in a straight line.​ ​ ​ Result​ This has applied highly quadrangular monsterclip to an organic environment that should fit well to TDMs 32x32 unit pathfinding system. As the approach is systematic, all areas should be covered correctly. This may be initially more labour-intensive than doing the monsterclip by eye, but in the making of One Step Too Far I kept finding small pockets all over the place where the pathfinding hitched before making the switch. ​ ​ ​
  20. Certainly, we have Obsttorte's keyhole peeking system that could be repurposed, it permits changing the view with mouse movements. For inserting the slides you could either just use custom inventory items, or if you want the slides to be moveables repurpose grayman's audio players.
  21. As far as I can see microscopes changed mainly through increased visual weight and more uniform horseshoe-shaped stands. The differences did look fairly subtle to me, after looking at quite a range of different microscope types. Maybe my searches mainly turned up 19th century microscopes Looking at your first shot, I think the wooden box as the stand is nice, but would find the body of the microscope too frail-looking. Your third shot is quite original and would make a good basis for an alternate-universe take on what a microscope looks like. In any case this would be a general purpose model so inputs & ideas from more people are a good thing to have, and from my own experience I liked to combine my favourite elements from each of the concepts when I modelled the hookah.
  22. As part of my mission I'd like to have more than a handful gentleman scientists studying and cataloguing specimens discovered on an expedition. A vintage, well-used microscope would be an essential asset. No doubt that this would be a versatile model for many other settings as well. What I'd like most would be a simple, worn-textured model like in the first shot. The other shots show additional or alternative style elements that could be interesting to use.
  23. I didn't think I'd see my merchant ship within a harbour at 60 fps, but 2.07 made it happen (formerly 40 fps). Thank you for the excellent work.
  24. This is what I remembered too, but the wiki page linked to in post #2 contradicts this after an edit made by Springheel on 2nd September 2016, which was left unchanged by grayman during later revisions of the same paragraph. So this would suggest AIs should be using elevators efficiently nowadays.
  25. I'd also say to begin with laying out (whiteboxing/greyboxing) the map to get an idea of how the planned pieces can fit together, and from there focusing on completing single rooms or buildings, like Melan or demagogue suggest, the rationale being that if the original idea was too ambitious, the excess can be removed from the whitebox. Another strength of producing complete scenes is that all elements of style are worked on together and should therefore fit together better. For example, lighting can be placed in such a way that it illuminates objects of interest, and objects can be placed to cast shadows that are interesting for stealth gameplay. This would be more difficult to achieve if object placement & lighting were separated into two mapwide worksteps weeks apart.
×
×
  • Create New...