Jump to content
The Dark Mod Forums

Geep

Member
  • Content Count

    87
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Geep

  1. I'm also not sure whether this interferes with acquisition to weapon/ammo inventory, but yes, in my case, unimportant: weapons are disabled and the weapon/ammo inventory items can't be seen
  2. @Destined A simplified version of your first method worked for me. To the archer I added these spawnargs: "name_attach3" "quiver_arrow" "set frob_action_script on quiver_arrow" "FrobbedQuiverArrow" And added the FrobbedQuiverArrow function to the <FM>.script
  3. OK, I'm stopped at the first step. In DR there's no pouch to select... but actually I'm interested in the arrows in the quiver, not the pouch. There is no quiver or arrow to select, but there are spawnargs, e.g., def_attach_3 atdm:prop_quiver_arrow. I can of course select the archer, but then how does S/R know if it's the frobbing of the purse or the arrow that's appropriate?
  4. I have an archer with a lootbag. I'd like to set up a frob_action_script that fires when any arrow is stolen from his quiver. But not interfere with normal pickpocketing of the lootbag. Possible? (Or using other solutions, e.g, S/R ?)
  5. The update to "Away 1 - Air Pocket" is now available as Beta 2/Release Candidate 1. Now with fewer bugs, more stealth playtime. Links are here.
  6. When I started the Air Pocket FM, I also looked at the wiki and forum posts about posing ragdolls. I got the impression that it took a lot of careful effort to do a pose and then you could easily accidentally overwrite it. I decided instead to concentrate on floating a ragdoll on water (finicky enough), and not sweat the pose. That pose was originally the usual-as-created-in-DR one, and then for some reason - as I was playing around - became an import-style T-pose, arguably an improvement for my purposes. (Similarly, my sitting captive was originally going to be implemented as a ragdoll, but given the pose issues, I went with a sleeping, sitting, zero-acuity AI instead.) Update of the wiki about this would be good.
  7. BTW, there is - in parallel - a recently-revived discussion about this topic, but focused more narrowly on currently-available moorish AI characters: http://forums.thedarkmod.com/index.php?/topic/15738-when-is-someone-gonna-make-an-egyptian-based-mission/page/3/
  8. Just a heads-up to anyone who might be interested in beta testing of a watery mission, "Away 1: Air Pocket". This, my first full-fledged FM, re-deploys Dragofer's ship models, familiar from "Down by the Riverside". By next weekend, I'll create a new Air Pocket thread in the Beta Forum, with the link to the download.
  9. Sounds like the approach someone with the right mad skillz would use.
  10. Regarding SEED problem... same data, different interpretation: Further playing around leads me to think that the system, when creating the 2D distribution of generated objects with "floor 1", does so within a horizontal plain passing through the (unmarked) centroid of the SEED volume, instead of at the top. It then drops objects down from that plane. So any landscape above that plane will not get objects... those objects instead fall to any lower surface or are culled. By this interpretation, the problem is not that a SEED volume is too tall, but rather its centroid is too low compared to the landscape.
  11. Just tried signing up for an account at the bugtracker, and got a "504 gateway timeout" error when I hit "Sign Up". So email verification didn't happen. Can't be good.
  12. From now on, I'll be keeping my SEED volumes under 512 units tall (just a hunch), and hoping that avoids this problem. Based on what you said, maybe it only affects undulating situations, that is, where SEED's "floor 1" is in effect.
  13. 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
  14. 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).
  15. 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.
  16. 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?
  17. 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
  18. 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?
  19. 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.)
  20. 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?
  21. 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
  22. 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.
  23. 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.
  24. 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"
×
×
  • Create New...