Jump to content
The Dark Mod Forums

cvlw

Member
  • Posts

    88
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by cvlw

  1. Is objective_ent set to 1? Search it out on Objectives in the wiki for best info. If you have multiple "things" that need to be in the same location, you need separateinfo_tdm_objective_location brushes for each one. I fell into that trap trying to get started mapping.
  2. Well, I think I found the likely reason. The movable was sunk into the floor by a single grid so I bet that is the reason. Scout's honor that I designed it right at the floor. Must have accidentally shifted it down during all the keyboard/mouse action. Thanks. Clint
  3. Is the idea that movables will then fall to the floor surface at start time rather than starting right on the floor surface? Does that keep it above the surface if it is then moved around by the player? Just wondering
  4. Hello TDM crew. I have a moveable_stool_piano that seems to occasionally fall/clip into the floor when I move it or stand on it. Quite naturally, this is sporadic and not deliberately repeatable. The floor is a simple worldspawn brush. What is the technique for preventing movables from falling through the floor? Or what nuances should I be aware of? Very much appreciated. Clint
  5. Isn't it amazing how potent these "new to me" experiences are and how much more agile you get after trudging through an issue? Many a time have I been stalled simply because I had the filters on.
  6. I am in map-learning, map-making trudgery sprinkled with real life (or vice versa). I don't imagine my first pubic map will compare with the great ones that have crossed the TDM threshold, but, it will be infinitely valuable to me to make one and provide one to all of you. I hope to get it into your hands "soon!" Clint
  7. Thanks for this suggestion. It seems to address it. Clint
  8. Greetings again, all. What is the way to prevent ai from bumping into things... For example, I have a key on a nail on a wall that the player needs to get. How do I prevent the AI from bumping the key or hitting it with a sword and flinging it far away? I have the key wrapped in nodrawsolid, and the wall has monster clip all the way to the ceiling about 2 unites out from the key. Yet, an AI will still bump it or hit it with a sword in hand. Possibly have the AI just too close no matter what? Appreciated. Clint
  9. Ah thanks. I will look into this. Much appreciated. Clint
  10. Hello again. Hopefully quick question: I have a glass pane in an inside office-like room. The glass is "textures/darkmod/glass/clear" texture. The glass reflects ghost-like images of an outdoor scene. A screenshot is attached here. Is there a simple clear glass without this effect? Thanks Clint
  11. Thanks for the great suggestion. This seems to be why the AI was walking through the door. The relight_position did not help this particular situation. So I experimented: 1) by converting the wall the switch is on to func_static... the ai found the switch properly. 2) by setting the wall to worldspawn and moving the orign of the swtich lever just outside of the wall dimension... the ai found the switch properly. I am using the prefab flip switch {prefabs}\Switches\small_wall_switch.pfb. It looks like when the switch and plate is flush against a worldspawn brush wall, the origin of the switch lever is inside the wall and throws off the AI from the relight. Does this make sense to the techno-experts? A switch origin cannot be inside a worldspawn brush and be used for relight? For now, I crafted a switch plate replacement that pulls the lever out of the wall dimension. I added the relight_position, too, to be thorough. So far, all of this seems to work now. The intended AI is much less of a dumdum, now. Thanks again. Clint
  12. Greetings again, all. I have a situation with a switched electric light and an AI not relighting it when switched off. The switch is on the wall about mid-player height. The light is atdm:sphere_brass_celiing with spawnarg shouldBeOn=1. The AI has: canOperateSwitchLights=1, chanceNoticeLight=1, chanceOperateSwitchLights=1 ... to seemingly ensure it will go and flip the light back on. However, when I switch off the light, the AI comments on the dark but walks to a nearby door and opens it, not the light switch. I have tried moving the switch ALLLLLL the way across the room and the AI still favors the door. Ideas on what might be the issue? Much appreciated. Clint
  13. I was toying around with my current build and did just that and it is looking great [in my inexperienced opinion!]. The ragdoll is set right above the landing {hide=0, solid=0, frobable=0, nodrop=0}. The objective location triggers a relay that teleports the boxes out, triggers the crashing sounds, triggers the mine_cloud.prt particles which nicely hides all the magic in smoky clouds, triggers the ragdoll, and triggers a SEED with wood debris to show. It looks just like the body falls and smashes the boxes in faux real-time. Even if the player jumps down with the body, it is all nicely camouflaged. The ragdoll is not kicked around by aggravated AI like I was dealing with in previous posts. The SEED is solid=0. So, none of the final objects are in the way. This is all turning out nicely and has been a great experience making a fun effect. I will save the dropping of bodies on spikes for some other entirely wholesome mapping effort. Clint
  14. I am interested in positioning how a body lands. Maybe have it fall into a box, land on a dais, or become impaled on a spike or fence post. I have been experimenting with the player tossing a body and controlling how it falls and lands. The AI entity, when KO/dead, falls and lands in random ways that can't seem to be controlled. The ragdoll replacement entity looks to be more controllable in that respect.
  15. Thanks for the ideas Dragofer, Geep. The player is actually tossing the body as mentioned in some prior posts of mine... still working on that vision. So, the player will likely see it. I am finding I can do almost entirely what I envision by creating the ragdoll, horizontal and face down, above the "landing" spot and cvar hide=1. At my controlled moment, I "target" it to bring it into view, drop it, and teleport out the original body. Additionally, I have the nodrop=1 on it which gives it a T-pose that looks strikingly natural when landed. This eliminates the usual random-ish tumble from a tossed body and allows controlling of the process. So far it seems promising except for differing orientations at the moment of body swap. So, I think I am getting closer. Clint
  16. Hello again. I want to teleport a ragdoll to a point in the air and fall horizontally, face down and to land face down. I have the ragdoll entity defined to flop face down at map start in a hidden area. When I trigger the atdm:teleport, the ragdoll is teleported standing up and falls feet first, no guarantee to land face down. Is there a way to keep the ragdoll "lying face down" at teleport? Thanks. Clint
  17. Hello TDMers. This is, hopefully. a quick TDM mapping "fundamentals" question. I apologize if this has been asked in the past. I wasn't finding this searching the forum. Consider a mapping task that can be achieved either in scripting or with DR objects: Is there any benefit to one over the other such as performance? Does it matter if the end result is a map that works? As I venture forth in mapping, I am often overwhelmed by the objects in DR. Scripting seems to get me what I envision faster. The script concepts feel easier to search for on the wiki, too. I hope to do things right and avoid painting myself into a corner by doing things wrong. I appreciate the advice/opinions. Clint
  18. Hello Greebo. I have worked with the new 3.6 for a couple hours. I was able to work just about the same as before the changes on 3.5. Usability: the windows risk docking quite aggressively even if not intended. I am liking that the properties parent window holds all of these child windows in one place rather than in separate windows. Perhaps make docking the parent Properties window optional? I like moving this window around and even moving partially off the screen if I don't close it. If I move it too far in any direction, it gets sucked into a dock. Potential bug: The surface inspector (S key) pops open the entity window at the same time. This happens unless the SI is docked in the parent property window. I tried some other undocked windows and only the SI and entity window did this as far as I could tell. Actual bug: the sizing of the objects within the Entity window (N key) resets when closed and needs to be dragged back out every time it is opened. This is the area shown in the attached screenshot. Hope that helps for "version.Next." Thanks! Clint
  19. Hello Greebo. Thanks for the work on the tool. I appreciate all the work of others on previous releases, too. A bit of "User Experience" feedback on 3.5 versus 3.4. I have a small laptop screen and use DR with a camera pane and a single grid view as shown in the attached image for version 3.4. I switch the view with control-tab . The docked window under the camera is slimmed all the way to effectively hide it. I rarely use it in favor of the entity window (key N). In 3.5, the ability to resize a docked window down to a thin bar is lost. It seems to force a minimum height which reduces adjacent window size. Then, as mentioned in a previous post, the window cannot be closed and stays in the forefront or must be docked. So a request is to make these windows completely resizable and closable. Appreciated. Clint
  20. Hello again. When I use r_showprimitives 1 and con_noprint 0 the values show on the game screen. However, they quite often print so fast that they blur together and I cant tell what the values are. I have tried messing with con_speed and con_notifytime values to no effect. Is there a way to somehow slow down the text printing from these commands? Thanks Clint
  21. Ah, thanks JackFarmer, Dragofer. I will get to particle customizations, as they say... "soon!" Very much appreciated. Clint
  22. Hello TDM crew. I am wondering how to address the situation JackFarmer noted here: JackFarmer question on particle dripping through brush I wish to have a simple drip particle. However the drips fall through brushes and modules. I am not {yet} ready to edit particles. Is there any way to stop particles with a brush or such? Thanks Clint
  23. Thanks for this. I can use clear;dmap [map] right in the console.
  24. Is it possible to combine console commands into a single call? I am hoping to do a clear + dmap [map] in one console call. Maybe some other combos if it is possible. Appreciated. Clint
  25. Is this the proper way to create a trigger hurt with specific damage, in my case a 5 damage: 1) make intended brush 2) texture as trighurt 3) convert to entity trigger_hurt (not damage_triggerhurt_5) 4) set def_damage arg to damage_triggerhurt_5 From what I can tell, this works now.
×
×
  • Create New...