Geep

Reporting "Barren SEED Bug" if SEED volume is 'too tall' I've been trying for some time to get SEED to work for me. It never seemed to generate any replicants. Finally found the problem... my SEED volume was 'too tall', or actually too deep into the water. Attached is a simple map file (once you remove the ".txt") that demonstrates the problem. There's a room with 2 identical SEED volumes, except for their overall heights (seen as depths below the floor). Each is asked to generate a dozen grass plants. The "fertile" one does, the higher/deeper "barren" one does not. This demo uses a within-SEED template for its target, but I had the same problem with an external target. In many cases the target entity itself would vanish. Sometimes but not always there would be a console warning at game start: "SEED: Feeling lonely with zero entities to care for". I'll leave it to others to refine what 'too tall' precisely means (i.e., absolute or relative or dependent on settings), and what the underlying cause might be. Thanks to dragofer for suggesting diagnostic procedures that helped find the workaround. barrenseedbug.map.txt

Ah, I mis-remembered. Yup, DR does show it correctly. Under 'Commoners, Armed/Foreigner' there are two bodies available, but only one visage (with or without helmet). Also a moor sorcerer body under 'Mages'. This is limited, because in most cases you have an obvious mismatch of skin tone between face and hands (plus exposed skin). I only found 3 sufficiently gloved/covered ai bodies that might work (but didn't try them to see if physiques match well enough with head-offset tweaks): Commoners, unarmed/ai_townsfolk_engineer Commoners, armed/ai_guard_elite Builders/ai_builder_forger I suppose you could also put a human head (moor or otherwise) on a reverent body [heh] The problem of an obvious mismatch of skin tone between head and body is a wider problem. For instance, the limited selection of female characters are further constrained from head-swaps due to commoner=tanned, noble=pale differentiation (with prostitutes in-between).

RE the moor AI characters being underutilized, I recall when I was doing a casual look-see of AI character in DR, the moor had "Shader Not Found", which discouraged further consideration... probably contributes to under-utilization.

I was just reviewing warnings in my build to find ones I could fix. The following are instead due to duplicate definitions in the stock 2.07 distribution and might be fixable in a future distro: [In tdm_textures_base01/:] WARNING:file materials/tdm_epi_shader_2.mtr, line 462: material 'wizard_cloth_001' previously defined at materials/tdm_epi_shader_2.mtr:366 WARNING:file materials/tdm_water.mtr, line 1189: material 'textures/particles/ripple_1' previously defined at materials/tdm_particles_ripple.mtr:1 [In tdm_models_decls01/:] WARNING:file skins/tdm_epi_skins.skin, line 86: skin 'steam_engine_003_off' previously defined at skins/steam_engine_003.skin:1 WARNING:file skins/tdm_epi_skins.skin, line 97: skin 'steam_engine_003_on' previously defined at skins/steam_engine_003.skin:18 Forgive me if these have already been reported and/or fixed. Where exactly is the TDM bugtracker, anyway?

Looked at CoO: Behind Closed Doors. For the loader screen background, 2048x2048 jpg was used; presumably 16:9 horizontally compressed to 1:1 (not 4:3). The title and associated text was burnt in there, but there was still text specified in the .gui file, namely that associated with the Mission Loading bar. The specs still used "0,0,640,480" throughout. I was surprised that .gui file continued to reference a ".tga" file as background, even tho it was now a .jpg (but otherwise the same path and filename) .... whatever works. My screenshots were at 1960x1080, so I chose one at full height and compressed the width to 1080 (i.e., 1:1) as well. Looked much better than before, tho still banding (some from the original screen image) and color shifts in gradients. I can live with that. For lazyness, I overlaid the title and associated text using the .gui method, rather than burn-in. If run on a machine with 4:3 ratio, the strings will not be in optimal locations, but on the other hand, the font characters will be normal size, not squeezed. All good

Thanks. I'll play around with this. If I use a larger loader image, but still want to use the guis/map/<fm>.gui text overlay, should I leave all the windowDef rect settings contained therein at "0,0,640,480"? Or give up on the overlay and just burn text in with (for me) Photoshop? In your "Also" comment, you mention "splash screens". Are we still talking about the loader image, or instead the traditionally 256x256 install_splash.tga?

This might not be the place to ask this, but... In http://wiki.thedarkmod.com/index.php?title=Mission_Title_Screen_while_Loading It is requested that the mission title screen be created in 1024x768 tga format, then stretched to 1024x1024 tga to "support older graphics cards" This wiki page was created by Fidcal circa 2007. At the edge of 2020, is it still necessary to do this stretching for support old graphics cards? (And in my mind, there's the larger question about whether, for new FMs, something nicer than the ratty-looking 1024x768 tga format could be handled.)

BTW, in the "All But Loot" filter code above, the 2nd criterion match should have a trailing underscore, i.e., match="^atdm:loot_.*|^atdm:moveable_loot_.*" as the comments indicate. But this doesn't affect the results in practice. As to the failing "All But Loot Goods", removing the unwanted trailing space in the key value did not fix anything. Also tried a match of "^3". No luck. Could it be that the problem is that the "3" value is represented by a float, not a string, and that matching can't handle that?

You are correct, except that there are actually around 100 loot entity classes. But on further consideration, given their naming convention, I can use regex. So the following is now working for me as a custom filter, to hide everything except loot: <?xml version="1.0"?> <filters> <filter name="All But Loot"> <filterCriterion type="entityclass" match=".*" action="hide"/> <filterCriterion type="entityclass" match="^atdm:loot_.*|^atdm:moveable_loot.*" action="show"/> </filter> ... </filters> The first criterion hides everything. The second criterion overrules the first one by showing “atdm:moveable_loot_...” and “atdm:loot_…” entities. This solves my immediate needs. But noticing that there was in "DR/Filters/Edit Filters..." an undocumented (in the wiki page) filter type EntityKeyValue, I tried to use it to restrict visibility to Type 3 Loot (Goods), using this filter: ... <filter name="All But Loot Goods"> <filterCriterion type="entityclass" match=".*" action="hide"/> <filterCriterion key="inv_loot_type " type="entitykeyvalue" match="3" action="show"/> </filter> ... This failed, that is, did not show anything. I see other forum posts in the past that claimed to use this filter type EntityKeyValue OK, so I don't know. If I had permission to edit the wiki (perhaps some day), and assuming EntityKeyValue is working and the problem is just me, here’s what I would add as a bullet point to "What filter types do exist?": entitykeyvalue: With this type, you can specify an “entitykey” (i.e., spawnarg name) and “match” (spawnarg value). Other possible wiki page improvements follow. Following the mention of "filters.xml": Following the mention of Regex, include a reference to the particular flavor/syntax being used. Perhaps https://www.w3schools.com/python/python_regex.asp

I did review that earlier, but the filter granularity as reported didn't seem to me to extend down to the spawnarg level, which is what I would need to filter for loot. DR custom Python scripting looked like it could do it, but then you'd have to work with an intricate DOM-like model... maybe an elephant gun to kill a flea. Just hoping someone had already killed that flea.

Does anyone have a DR Python script that selects all loot items? Or a particular type (particularly interested in type 3, LOOT GOODS)? Either type of script would be more useful to me than the tdm_show_loot command.

Among my problems with disableWeapon() is that it disables ALL weapons, not just the current one, by essentially freezing the weapons part of the user interface. This may work for grayman's use case (the player put in jail) but not mine... I want to be more selective. (Not shown: my filtering of weapon type so that DisarmWeaponThread gets called only for blackjack and shortsword). [SOLVED] I finally have a solution for my needs. Instead of using "disableWeapon()" in the above function, I use: selectWeapon("unarmed"); Note carefully the argument here. It is not either of these: selectWeapon("atdm:weapon_unarmed"); selectWeapon("player1_weapon"); // Name returned by weapon.GetName() when player unarmed. FYI, grayman gives the otherwise-undocumented list of selectWeapons strings here as: "unarmed" "blackjack" "shortsword" "broadhead" "waterarrow" "firearrow" "ropearrow" "gasarrow" "noisemaker" "mossarrow" "vinearrow"

HMart - I followed your helpful outline, though my thread function was somewhat simplified: void player::DiscardWeaponThread(entity weapon) { sys.trigger($atdm_gui_message_no_art_my_weapon_message); sys.wait(4); disableWeapon(); sys.waitFor(weapon); sys.wait(3); // possibly redundant discardthreadNumber = 0; // Tell caller we're done } My version of DiscardWeaponThread() has these differences: I added the ...Thread suffix - that's just me. It's a void function, since the "thread" keyword on the call takes care of returning the thread ID. Wrapping the body in "eachFrame" didn't seem to buy anything other than making my head hurt. By not having an endless loop, I can end the thread just by ending the function, so don't need a sys.terminate Instead of your gui method, I used an atdm_gui_message... element in the map to put a message up for 4 seconds. This works fine. weapon.weaponHolstered() is a void function, so was not meaningful to test by an "if". And its presence or absence didn't seem to make a difference. I don't know if waitFor(weapon) works (I added "sys." before it), so I did sys.wait(3) too to be safe. This is an OK if imperfect solution. A problem with using disableWeapon is that, while it puts the weapon down, it leaves it selected in the GUI, and you can't unselect with TAB. Nor can the user raise it (and see my message) again. I tried putting an enableWeapon() at the end of the thread, but that undesirably raises the weapon again. I also tried, in place of the disableWeapon() call, these functions - LowerWeapon(); // w or w/o "self." selectWeapon("atdm:weapon_unarmed"); Neither exhibited the necessary lowering response (although getting rid of disableWeapon did mean you could lower the weapon with the normal keystroke, and when you re-raised it with the normal keystroke, the gui message would re-appear). Finally, I considered trying .Lower(), that is available for certain weapons, e.g.: #include "script/tdm_weapon_blackjack.script" ... // replace "disableWeapon()" with code that checks if weapon is blackjack (not shown) and if so: weapon_blackjack jack = weapon; // cast so "Lower" is available. BAD SYNTAX jack.Lower(); But I don't know how to do the required cast/conversion in this scripting language.

nbohr1more posted elsewhere: "...you can override scripts ... and an number of things that are global by packing them in the corresponding sub-folders in your mission package." So I guess I could copy the entire tdm_player.script file and alter that. (Not as surgical as just over-riding particular functions, tho. Future checked-in updates to other functions in the file would be overriden by the old stuff in my copy too). It's a direction!

Thanks, HMart. I understand what you propose. What you are suggesting is an extension of the code in tdm_base01\script\tdm_player.script A concern: as a noob fan mission dev, not an engine dev, I'm reluctant to alter that code directly. Because, for example, even if I could package & distribute the change properly, wouldn't it be lost on the next TDM update from 2.07 to 2.08 ? I wonder if it's possible to override a base-script function body with a custom function of the same name (either in the <fm>.script file or a separate script in the "script" folder, referenced by tdm_custom_scripts.script) ? It would have to part of the player object, that is, with a fully qualified signature like void player::RaiseWeapon() If so, then I wouldn't have to alter the base script, and I'd be a much happier camper trying out your method.

BTW, I realize that what grayman sought was the disabling of a weapon NOT initiated by the player (i.e., an exterior script), so my use case is somewhat different. I did post a request about this topic to the Newbie thread a while ago, with code of what I had tried unsuccessfully. Crickets.

In a July 26, 2017 post, @grayman indicated achieving this effect: "getCurrentWeapon() reports the current weapon once it's fully raised, so what I see is the weapon raising, then being lowered after it's done raising. " That's exactly the effect I need, assuming that - the player initiates the raising the lowering is automatic (and ideally there's an opportunity in the script to show a gui message in-between) But I don't understand from the surrounding discussion with @Obsttorte exactly what that script fragment looks like and how it's invoked. Similarly with the alternative (and for me somewhat less desirable in terms of behavior) method using $player1.disableWeapon(); since in my case I would need the weapon-raise event to trigger a script function. Any help, e.g., sample script fragment, would be great. Or point me to a pertinent FM

I'm having some difficulty with the following: I'd like the player to select an available inventory weapon (e.g., sword), and, once it's loaded, realize that's something's wrong with it (I'm imagining conveying this through a popup message here.. no problem with that). Then the weapon would be automatically put back away. The forum+wiki has some hints about various ways to do something similar to that last step, but I couldn't quite grasp their details and how to deploy them. The best I could do was build a frob script [attached; placed in the maps folder] for the weapon, a sword in this case. It fires OK, but my "endless" loop to detect current-weapon only runs a few times then stops. (And it would be better not to have an endless polling loop at all, instead have some response to the weapon-raised event.) Thanks. sword_stop.script

@Destined @Springheel OK, I've figured out the problem, which only occurs when invoking the updated stock-distributed trigger_look.script found in tdm_base01. If you are using one of the earlier custom versions from the forum, the problem will not appear. Specifically, the update replaced 2 calls to a locally-defined function "length" with calls to system function "vecLength", but neglected to prefix it with "sys." This caused a divide-by-zero error and effective ignoring of the "tolerance" spawnarg. Please someone correct this in 2.08. [Corrected, tested replacement file attached] Also, please someone add to the wiki entry that a stock script is available, so you don't *have* to use a custom script (except in the short term to get around this bug). BTW, the wiki did describe how to set up the custom script... I just misinterpreted the relevance of that discussion. Thanks, Destined, for setting me straight. trigger_look.script

OK, poked around further and found that trigger_look is included in the standard distribution as tdm_base01\script\trigger_look.script. So that's the copy that's being called, and presumably giving the divide by zero error.

Should have added, the instructions for this were found at http://wiki.thedarkmod.com/index.php?title=Triggering_events_when_looking_at_something plus comments in the forum referenced above. The forum contains 2 versions of the trigger_look.script file. I used the more recent.

I'm having some difficulty getting the trigger_look script to work as advertised. I posted the original problem a while ago to http://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/page/17/ but crickets there. To restate more precisely and fully: --- I'm trying to use the trigger_look script for the first time. I want my player to look at a rope (the seen-object) and stuff happens, limited to popping up a GUI message initially. So, as the instructions for this specified: - I put a copy of "trigger_look.script" into my <fm>.maps folder - I added #include "script/trigger_look.script" to the head of my <fm>.script file - To my rope object I added spawnarg "scriptobject" with value "trigger_look", as well as a "trigger" to a pop up gui message. The popup is working OK... the problem is under what conditions the popup occurs. When my player looks at the seen-object, the trigger works fine based on the default distance and "once"=1. What does not work is the view direction (just using default, or even with a specified "tolerance" value), which is ignored (e.g., as if "tolerance" was "2" aka 360 total degrees). I can back my player up to the seen-object, and still it triggers when within distance. I've also noticed a console warning about divide by zero in line 66 of the script. Presumably this is the call to the length function float length(vector v) { return sys.sqrt(v_x*v_x+v_y*v_y+v_z*v_z); } Perhaps sys.sqrt is broken? This is under TDM 2.07/Windows 10. --- I tried further diagnosis of this today, but I'm getting nowhere. Not even sure my copy of trigger_look.script within my "maps" folder is being called, as opposed to some other mystery location. The instructions say to use #include "script/trigger_look.script" which I did but the "script" part of the path must be some abstract location... and if I remove "script/", runtime TDM complains about not finding the script. If I add sys.print(...) in various locations within my copy of the trigger_look.script, nothing extra appears on the console, even it I create a separate threaded child function. That's why I'm thinking some other copy of "trigger_look.script" is being utilized. Or sys.print only works when called by $player1, not from scripts associated with other objects? Thanks for any help

Greets - I'm trying to use the trigger_look script for the first time. When my player looks at the seen-object (a rope), the trigger works fine based on the default distance and "once"=1. What does not work is the view direction (just using default), which is ignored (e.g., as if "tolerance" was 2). I can back my player up to the seen-object, and still it triggers when within distance. I've also noticed a console warning about divide by zero in line 66 of the script. Presumably this is the call to the length function float length(vector v) { return sys.sqrt(v_x*v_x+v_y*v_y+v_z*v_z); } Perhaps sys.sqrt is broken? This is under TDM 2.07/Windows 10. Any help would be great, but no hurry... I'm going to be away from my dev machine for a few weeks, so can't diagnose further in the short term. By the way, attached are some ideas to improve your corresponding wiki page, that I wrote up as I was researching this. Ignore or use as you see fit. Thanks Forum post ideas.txt

Recently, I wanted to express the TDM Objective: “don’t pick up a particular loot item”. I guessed there’s a way to do it in the Objectives Editor using an “Acquire entity” component, but I couldn’t figure out how to make that work. I ultimately succeeded with a different, script-based approach. But for future reference, how should I have done it with “Acquire entity”? Details What I tried: I added a new objective, with “Ongoing” checked, then added a component of type “Acquire entity” aka “Player possesses item”. As part of that, I selected the Item field prompt “Name of single entity” and in the field put the entity instance name. But that name did not seem to “stick” across invocations of Edit Objective. I set the flags “Satisfied at start” and “Boolean NOT” (i.e., item not acquired). It wasn’t clear what to do what to set “Amount” to… zero? 1? What worked instead (abstracted here): A simple objective with default settings was used, with objective component type of “custom” / “Controlled by external script”. The loot item was given a frob_action_script spawnarg to call a script function, that in turn calls sys.trigger($atdm_target_setobjective_state_prohibited_loot_failed); // mission fail This atdm_target_setobjective_state explicitly set the minimal objective to state 3 (fail). (BTW, this overall approach made it easy to add bonus script-invoked sound-and-visual FXs as precursor to the “mission fail”. So all good.)

Or maybe "done & hide" from a script: sys.trigger($atdm_target_setobjective_visibility_hide_my_objectives); $atdm_target_setobjective_state_hidden_done.activate($player1); // mark my hidden objectives as done