joebarnin

[Forgive me if this is the wrong place for this discussion.] I've been beta testing two new FMs: JackFarmer's Hidden Hands: The Last Citadel, and The Painter's Wife. They are both large missions. In each mission, testers have run into a problem related to event limits. (Note: all of my testing is has been done on the most recent 2.08 beta). 1) In HH:TLC, at some point in the mission TDM crashes. There is no "The DarkMod.exe has stopped working" dialog - the process just disappears. One other beta tester reported a CTD as well. In addition, JackFarmer indicated that he had seen this error occasionally during his testing. I set logging levels and found this in qconsole.txt: "Recursive fatal error!". I tried to debug this issue further by building a debug version of the executable and setting break points in Visual Studio. Eventually I was able to get the error message to log: idEvent::Alloc : No more free events (I posted the details in this topic: https://forums.thedarkmod.com/index.php?/topic/20404-beta-testing-hidden-hands-the-lost-citadel/&do=findComment&comment=447958). From what I can tell, reading the code, this happens because we have exceeded MAX_EVENTS, which is currently 10240: #define MAX_EVENTS (10<<10) 2) In TPW, I got this error: [In case the graphic isn't readable, the dialog says this "Game Error. Event Overflow. Possible infinite loop in script."] The FM developers have also seen this issue during development and testing of the mission. The C++ code indicates that this error occurs because the number of events exceed MAX_EVENTSPERFRAME, which is also 10240. It certainly could be that there are bugs in these missions, that they are either inefficient or have a loop somewhere that is causing these problems. But I'd like to entertain the possibility that these large missions are simply pushing the boundaries of the event limits. I'm wondering if the event limit should be increased (that is, increase the value of constants MAX_EVENTS and MAX_EVENTSPERFRAME). I understand that there may be consequences of doing this - at a minimum, presumably, the DM exe might consume more memory. I just did a test: I had a save file from HH:TLC that always crashed on 2.08 - after loading the save, if I just waited for a couple of minutes, the CTD happens every time. I downloaded the source code matching the current 2.08 beta 5 (SVN 8735). I built the release version and tried again - again, the same CTD happened within a few minutes. I then modified the code to double MAX_EVENTS and MAX_EVENTSPERFRAME, to 20480. Those are the only two changes I made. I rebuilt the Release version of the executable, ran it, and loaded that same save. This time, TDM did not crash. I acknowledge that this is a rather brute force fix. I'm not suggesting that 20480 is the best size to use. But, to me, it looks like there are a couple of large missions that are pushing up against the event limit. Perhaps it is time to consider bumping up this limit, as part of 2.08? I'll sit back now and let the real TDM developers tell me why I'm wrong

Sorry, I was wrong about remove(); I don't think it works for inventory items? But I have had success with $player1.replaceInvItem($bienie_custom_item_part1, $null_entity); In my Heart of St. Mattis mission, you collect 3 key fragments and then they magically get combined into a special key. My script used replaceInvItem to remove the fragments from inventory. I know this didn't work for you. One thing I noticed, the inventory items I'm getting rid of are non-droppable. Spawnarg "inv_droppable" = 0. Maybe that's a requirement? Anyway, try setting that on your bienie_custom_item_partN objects, see if that helps.

Try $bienie_custom_item_part1.remove(); That removes the object completely (including from inventory). I've used this technique for getting rid of inventory items.

I don't have 2.06 installed - how does one install an older version? Here is a test map: test.zip

I'm running into an issue with projected lights. The behavior is different from 2.07 to 2.08, and to my (non-expert) eye it seems to be a regression. I have a light that projects on a wall (for lighting paintings in a museum). I created a simple test case. As you can see in DR, the light does not reach the floor: In the XY side view (bottom right) you can see that the light boundary doesn't reach the floor. In DM 2.07, it looks like this: The light cuts off on the wall, before it reaches the floor. But the exact same map in DM 2.08, the light reaches the floor: The only mention of projected lights that I can find is this. I can't tell if this is related to what I'm seeing: Is this a new bug?

I'm missing it too, and I'm on 2.07 hot fix 1.

I will test on 2.08

Sign me up. I'm very close to going into beta on my own mission, but I can devote some time to testing others.

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.

Thanks

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

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

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

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?