joebarnin

Nice! Now I'm depressed - I've got a museum in my upcoming mission and it doesn't look as good as this!

[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.

All done - check the bug report.

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.

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.

Done: https://bugs.thedarkmod.com/view.php?id=5236

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.

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.

Nice! How do you actually enable this on a specific light?

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.

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?

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?

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

"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"

I just tried it, and that works fine.

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?

Congratulations Amadeus!

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.

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.

Sign me up!

Actually, I think this was player error. This happened in the mess, near where the crew member is dead in the bed. I just tried to recreate the problem, swimming near/into the bed. At some point I thought I was stuck, but by trying different directions I was able to proceed. I think the first time it happened, I just panicked because I was running out of air, so I assume I couldn't move at all. So I don't think this really is a problem.

When you set the Game/Project setup, DR loads files from the mission. My guess is something about that is causing the crash. The DR log file might have some clues? I found mine in: C:\Users\<user name>\AppData\Roaming\DarkRadiant\DarkRadiant.log (where <user name> the name you're logged into Windows as). Yeah, try this maybe: make a new, blank WIP (maybe start with the Startpack). Set the Game/Project setup to this WIP, see if that works. Then try to use the readable editor. If everything works with the "blank" mission, drop in your existing WIP files into the new project, and see if things still work. That might help narrow things down.

When you select File > Game/Project Setup... you should get a dialog like this: DarkMod Path is where DM is installed. "Mission" should be the mission folder you are modifying. You should be able to pick it from the drop down list - it's a list of all of the folders with the /fms folder (within /darkmod). Is this what you see?

Finished the mission. Short and sweet! As Jack says, a unique concept. Nice to see a non-standard mission design. I thought that the I really really really Looking forward to further stories in the arc!