Jump to content
The Dark Mod Forums

joebarnin

Member
 View Profile  See their activity

  • Posts

    1086

  • Joined

  • Last visited

  • Days Won

    42

 Content Type 

Posts posted by joebarnin

  1. Beta Testing 2.08

    in The Dark Mod

    Posted

    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:

    dr.thumb.jpg.fb8c3f57f167346513e13871f74ebdce.jpg

    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:

    nowandthen_2020-05-28_13_27_03.thumb.jpg.825aebdf2337280358ac5a79456fb8cb.jpg

    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:

    nowandthen_2020-05-28_13_03_29.thumb.jpg.06b8289d8c508275c59a5650a6d5c1b3.jpg

    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:

    On 3/8/2020 at 1:59 AM, stgatilov said:


    4) Fixed bug in stencil shadows computation, which was introduced in 2.07 (#5106).
       It affects all parallel and projected lights when mapper runs dmap on a CPU with AVX.
       It is strongly recommended to re-dmap all FMs dmapped with 2.07 if they contain such lights.

    Is this a new bug?

    • Like 1

  5. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted · Edited by joebarnin

    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 1

  8. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted · Edited by joebarnin

    I noticed that some missions with long names display correctly and some don't:

    cleaninguptheneighbourhood_2020-05-10_13_20_30.thumb.jpg.ed75c1d0e3c339be90c32bb7ce959483.jpgreluctantbenefactionv1_2020-05-10_13_20_48.thumb.jpg.3a3e653a093b8d9ab098dfb48baf9247.jpg

    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

    • Like 1

  11. Script strings limited to 127 characters

    in TDM Tech Support

    Posted

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

    Quote

    what about hypothetical "appendSpawnArg" function?
    You start with a short string with a call to setSpawnArg, then call appendSpawnArg a few times dynamically to build your long text?
    Would it work for you or you need something more flexible?

    An alternative: use spawn arg accessors in setSpawnArg. I.e.
    setSpawnArg("page1_body", "Some text to start with.");
    setSpawnArg("page1_body", "${page1_body} More text to follow.");

    Either of those would be acceptable, from my point of view.

  12. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted

    4 hours ago, duzenko said:

    Can you try to create a readable from script using the xdata text please?

    Also, you test map is not an accurate case. Can I ask you to actually spawn the readable by user action? E.g. lever trigger, etc

    Ideally I'd like to have two levers - one creates a readable from xdata and another a string hardcoded inside the script

    All done - check the bug report.

    • Like 1

  13. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted

    2 hours ago, Destined said:

    I am not sure, if this is of help, but obsttorte has had released a method to create a diary/journal that is updated on certain events. You can find it here:

     

    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. 

  16. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted

    13 hours ago, Abusimplea said:

    Does the page1_body spawnarg support sub-indexing (page1_body1, page1_body2, ...)?

    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.

  17. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted

    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.

  19. Light count issue

    in TDM Editors Guild

    Posted

    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.

  20. Light count issue

    in TDM Editors Guild

    Posted

    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?

  21. Light count issue

    in TDM Editors Guild

    Posted

    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):

    turn_2020-04-07_09_18_36.thumb.jpg.7b681863f45ac8e1813ab4d2cacff014.jpg

    And yet, r_showlightcount indicates two lights in the main room:

    turn_2020-04-07_09_18_45.thumb.jpg.a9386a32734bc036dc8b10da9a6672c8.jpg

    If the lower visportal is closed, shouldn't the light count be one? Or am I misunderstanding?

  22. Light count issue

    in TDM Editors Guild

    Posted

    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:

    1. Main room with a light.
    2. Hallway connected to main room
    3. Stairway down connected to the hallway
    4. 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

  25. Newbie DarkRadiant Questions

    in TDM Editors Guild

    Posted

    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?

×
×
  • Create New...