Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by joebarnin

  1. Sign me up. I'm very close to going into beta on my own mission, but I can devote some time to testing others.
  2. Jedi, I follow these instructions: https://wiki.thedarkmod.com/index.php?title=Readables_Prefabs. Specifically, the "Inserting Readables Prefabs" section. The key is you have to extract prefabs.xd from one of the pk4s in the DM distribution (tdm_prefabs01.pk4 I think). Then you open that prefabs.xd file in a text editor and copy/paste from it (per the wiki instructions). One last thing you have to do is rename the 'xdata_contents' spawn arg on your readable to match the name you gave the xdata name header in your XD file. Save your xd file, and at that point you should be able to use the Readables Editor. Edit: Here are the complete steps, mostly from the wiki, with a couple of extra ones at the end: First make your own plain text xd file, eg, mymap.xd. (Do this BEFORE launching Doom/TDM else it won't load it - you'll have to exit and open TDM again.) (you just need to do this once). In your map editor, in orthoview, point to where you want the readable, RMB, insert prefab, select a readables prefab. There are images at Fonts Screenshots so you can see what the fonts look like. With the readable selected, in Entity Inspector note the xdata name from xdata_contents. (tip: highlight then Ctrl+C to copy it) In the TDM distribution, within tdm_prefabs01.pk4, find the file prefabs.xd Open prefabs.xd in a text editor and find that xdata name you copied (tip: F3 to search (usually) paste in the name) Select & copy the complete xdata section including the name and the last end curly bracket. (tip: look for a few blank lines then the next xdata header name.) Paste it into your own xd file, eg, mymap.xd. Still in your own xd file, change the xdata name header, eg, from book_gothic_bamberg to eg, nightwatch_logbook. Save and close your xd file. In DR, in the Entity Inspector, change the xdata_contents Property to the new name (e.g., nightwatch_logbook) At this point you should be able to use the Readable Editor. It will update your XD file automatically.
  3. I notice that the Issue has been Fixed. Can I ask which fix was implemented? Also, one of the comments by duzenko in the bugtracker mentions this thread: https://forums.thedarkmod.com/index.php?/topic/20365-script-string-length-128-workaround/&tab=comments#comment-446786. I don't have access to this thread for some reason. Is it important that I read this thread? If so, I'll need access. Thanks
  4. I noticed that some missions with long names display correctly and some don't: I think it's a problem with mainmenu_newgame.gui, specifically this: windowDef InstalledModTitle { rect 0, 45, 280, 50 text "gui::currentModName" forecolor 0.4,0,0,1 textscale 0.35 textalign 1 font "fonts/carleton" } The rectangle that the mod name fits into is the entire width of the overall rectange (0-280). Depending on how the string wraps, this may or may not result in content beyond the edge of the rectangle. I think something like "rect 15, 45, 250, 50" works better. I copied the base mainmenu_newgame.gui into my FM's \guis folder and made that change to the rect, and the mission name displays better, no matter how long it is or how it wraps. You could try this for your mission. Although that file has this warning in it: * Mission Authors: DO NOT EDIT, INCLUDE OR OVERRIDE THIS FILE IN YOUR MISSION PK4. Not sure how dangerous it is to override this file. Edit: I'll submit a bug report
  5. Actually, my museum doesn't look that different from grayman's (same wall modules and painting lights). It's just that his museum just seems much grander. I think it's the ceilings and openness. Maybe I'm just tired of looking at mine
  6. Nice! Now I'm depressed - I've got a museum in my upcoming mission and it doesn't look as good as this!
  7. [Let me know if this isn't the right place for this post] This is a thread to discuss this issue: I created a bug here: https://bugs.thedarkmod.com/view.php?id=5236 As for duzenko's comment in the bug tracker: Either of those would be acceptable, from my point of view.
  8. This is very clever. I just gave it a try, but unfortunately it runs into the same problem. As soon as the content of the diary reaches 128 characters, it gets truncated.
  9. Sorry about that. I updated the bug report with a test case - a complete mission zip with folders. The script file has the same name as the map, so the main() method within it will run automatically when you run the map.
  10. Done: https://bugs.thedarkmod.com/view.php?id=5236
  11. Nope, I tried that, it doesn't work. I was able to implement something similar to that, by modifying the readable GUI (e.g., sheet_paper_calig_mac_humaine.gui) so that it supported _body1, _body2, etc. That enables me to put multiple strings in the body from a script, as long as each is less than 128 characters. This technique comes with significant limitations: each _body# is effectively a paragraph, and you have to manually position it using newline characters. Highly kluge-a-rific, but it may have to do for now. I'll submit something in the bugtracker too.
  12. I've been doing some script coding, and it looks like there is a maximum length for string variables in scripts: 127 characters. Any strings longer than that get truncated. Is this a known limitation? Let me explain what I'm trying to do. I want to dynamically create a readable, based on the status of the mission. Here's an example of the script code: ai guard = $atdm_ai_guard_elite_1; string msg; if (guard.AI_DEAD) { msg = "He's dead, Jim."; } else { msg = "He's fine, Jim."; } sys.setSpawnArg("gui_page1", "guis/readables/sheets/sheet_paper_calig_mac_humaine.gui"); sys.setSpawnArg("page1_body", msg); sys.setSpawnArg("num_pages", "1"); entity testnote = sys.spawn("atdm:readable_mobile_paper01"); $player1.addInvItem(testnote); This works great - the player gets a note in the inventory with the appropriate content. But, if I try to make the 'msg' text longer, beyond 127 characters, it gets truncated. I was excited about being able to dynamically create readables until I ran into this issue. Does anyone have an idea how to make this work? Yes, in this simple case I could just create two xdata_contents and dynamically point at one or the other. But what I really want to do is more complicated logic, involving several variables. I would have to create 10 or 20 different xdatas to handle all of the permutations. I'd rather not do that.
  13. HMart - thanks for all of the info. I'm sure my lighting "hygiene" is not as good as it should be. I'll use the advice I've gotten to clean things up. I still think there is something puzzling happening, but using the techniques you and other have mentioned I should be able to minimize the light count.
  14. I reduced the basement light radius so that it is entirely contained within the basement (at least, in the X and Y directions; in the Z direction it protrudes into the room above). If I go back upstairs, the floor shows two light sources. So the basement light is going "through" the floor, but only if the door is open? I don't get it. From a level design point-of-view, I can shrink the light radius so that it fits the room (XY) but I can't shrink the Z direction so that it doesn't go through the ceiling/floor. Also, isn't it strange that I see different behavior in these two cases: 1) visportal is closed (red) because it is out of view (beyond a closed visportal). In other words, I open the door, then go back into the main room and go around the corner so that the door visportal is out of view. In this case the lightcount is still 2. 2) visportal is closed (red) because its door is closed - lightcount is 1 Also, why does this behavior not happen if I use a generic "light" object?
  15. Thanks. But I'm still confused. Here is a screen shot of the scenario you described. I'm in the main room, looking toward the hallway and stairway. r_showportals indicates that the upper visportals are open (green) and the lower one is closed (red): And yet, r_showlightcount indicates two lights in the main room: If the lower visportal is closed, shouldn't the light count be one? Or am I misunderstanding?
  16. I have a performance issue with an FM that working on. The FPS is dropping pretty low in some areas. I narrowed it down to the fact that my light counts are high (r_showlightcount 1). I'm confused why certain lights are contributing to the light count. To help understand this issue, I just created a simple test case, which consists of: Main room with a light. Hallway connected to main room Stairway down connected to the hallway Basement room (with a light) connected to the stairway. The basement room is directly below the main room. There is a visportal and door between the hallway and the stairway. When this door is closed the light count in the main room is 1. When it is open, the light count is two. I hope this video makes it clear: This puzzles me - how can the basement light affect the light count in the main room? The light shouldn't be going through the floor/ceiling between the two rooms, right? Why does opening the door make a difference? The door is beyond the range of the light anyway. Additional data point: It doesn't matter what type of light I use in the basement, the behavior is the same. Any light based on atdm:light_base shows this issue. But, I replace the basement light with an object of class "light" (the thing you get if you do "Create light..." in DR), then the light count stays at one even if the door is open. In fact, I was able to create a light that looks and acts just like the atdm:cagelight. I went through the class hierarchy, starting with atdm:cagelight, then what it inherits (atdm:static_electric_light_unlit_base), then what that one inherits, and so on, and I grabbed all of the spawnargs from each. I ended up with this: { "classname" "light" "name" "light_2" "AIUse" "AIUSE_LIGHTSOURCE" "_color" "0.44 0.34 0.17" "editor_SetKeyValue s_shader" "light_flicker_104" "editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Outdoor/DoNotUse" "editor_light" "1" "editor_setKeyValue light_center" "0 0 -8" "editor_setKeyValue model" "models/mapobjects/lights/cagelight/cagelight.ase" "editor_usage" "A lit wall-mounted, grill light. Replacement for Doom3 cagelight. Can be toggled on/off when linked from a switch." "extinguished" "0" "lightType" "AIUSE_LIGHTTYPE_ELECTRIC" "light_center" "0 0 -8" "light_radius" "260 260 260" "model" "models/mapobjects/lights/cagelight/cagelight.ase" "nodiffuse" "0" "noshadows" "0" "noshadows_lit" "1" "nospecular" "0" "origin" "-848 -136 -736" "s_looping" "1" "s_shader" "light_flicker_104" "s_waitfortrigger" "0" "scriptobject" "tdm_light_holder" "shouldBeOn" "0" "skin" "lights/cagelight" "skin_lit" "lights/cagelight" "skin_unlit" "lights/cagelight_unlit" "sr_class_1" "S" "sr_radius_1" "500" "sr_state_1" "1" "sr_time_interval_1" "977" "sr_type_1" "STIM_VISUAL" "texture" "lights/tdm_lanternlight_4fold_small_snd" } Which is equivalent to atdm:cagelight in both looks and function. The difference is, this light doesn't add to the light count. I suppose I could use this to work around the issue, but man is that kluge-a-rific. Anyway, any ideas on what is happening here? The test map is attached. testl2.zip
  17. "com_showfps 0" in the console turns it off. If it's on each time you start DM, then you've got it set in your darkmod.cfg. Remove this line: seta com_showFPS "1"
  18. Just guessing here, but maybe there's a conflict because the hammers are stackable, but each uses a different model. Maybe the code can't handle that situation? Possible workaround: make them non-stackable. You'll get separate items in your inventory. Does that avoid the problem? You might have to use different inventory names (Ritual Hammer 1, Ritual Hammer 2, etc). Maybe not an optimal solution. Is the reason you created four models that the hammers all look different?
  19. How about instead of abruptly ending the mission, the gold bar goes into your inventory and weighs you down so much that you can’t swim up. Now, you’re running out of air and need to quickly drop the bar so that you can surface. You could even give a hint to the user via pop up text or voice (maybe easier levels only?) Edit: I have no idea if it is technically possible to keep the player from swimming up.
  20. I know this technique has been discussed before, but peter_spy's recent comment on another thread about non-diegetic lights finally clicked with me. To verify my understanding, here's an example. I'm working on a mission that has a shop whose entrance is located at street level, under an extended second floor. The door is in the dark, located where the red arrow points. There's a sign on the door that is completely invisible from this distance. Even when you get a lot closer to the door, you can't read the sign because it is in the dark - you have to deploy your lantern just to read it! So I put a tiny light right in front of the sign, and now it is visible. You notice it, and you can actually read it from this location using your spyglass. Depending on your screen brightness, it may not be very obvious from these screen grabs. But in game, it is very clear that there is something worth looking at in that dark corner. As peter_spy said, it draws your eye and focuses you in that direction. And even when you get close to the door, the 'lit' sign doesn't look fake, because it is barely illuminated. Anyway, that's my understanding of non-diegetic lighting; hopefully I got it right.
  • Create New...