Dragofer
-
Posts
2634 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
5 hours ago, thebigh said:
Can the tiny spiders be made to patrol, or do they just wander around aimlessly no matter what?
The animal_patrol spawnarg governs that.
-
1 hour ago, STiFU said:
I am a bit appalled about this supposed "will". What is the reference you base this on? Grayman explicitly told us not to release his works. His exact words were: "If I die, the story of William Steele ends with me. No handing off my FMs to others".
The Black Mage and Seeking Lady Leicester FMs are not part of the William Steele series and were expressly offered for adoption by grayman, as opposed to the remaining chapters of the William Steele Series.
-
2
-
1
-
-
On 7/27/2022 at 11:26 PM, Frost_Salamander said:
I have some AI in my FM that are sleeping. Some in a chair, some on a bed. Sometimes they die if you blackjack them. There are logs in the console saying they are taking 'landing damage'. In one case it was 252 damage at once. Other times it was several small amounts like 5, 7, etc.
Does anyone known what causes this and how best to avoid it? I've heard things like use moveable chairs and making sure the AI isn't touching them, but I don't want the AI to be sitting on air if you move the chair, or see them floating above the chair/bed just to avoid this.
That's anyone's guess, I think. Maybe grayman knew the cause, but didn't know the fix or get around to it.
That said, I don't think anyone's reported knockout fatalities in my FMs - maybe worth comparing your method?
2 hours ago, geegee said:Does anyone know what this console error warning is about?
WARNING:Source with 2 surfaces. snapshot func_static, scaling: no, needFinish: no
Does this indicate a degenerate solid (made into func_static)? Is there any way to trace the culprit?
That's my more important question.
_____________
WARNING:Couldn't load image: dds/textures/particles/arcturus_fire
[map entity: atdm_campfire_typical_1]
[decl: light_fireflames_typical in def/tdm_lights.def]
[model: typical_campfire01.prt]
[decl: typical_campfire01 in particles/tdm_fire.prt]
[decl: arcturus_fire in materials/tdm_particles.mtr]
[image: dds/textures/particles/arcturus_fire]I checked, the dds image is there. Perhaps the wrong format?
That error attaches to atdm:campfire_typical
It doesn't attach to atdm:campfire_smallwhich to my eyes appears identical to atdm:campfire_typical
So I suppose atdm:campfire_typical should be the same, but with an enhanced fire that doesn't render because not found.
Anyway I use the error-free atdm:campfire_small to get rid of the warning.
I haven't heard of that warning. Snapshot sounds like it would have to do with cubemaps... By the way, I learned recently that if you use "testmap" it's actually a combination of "dmap" and "devmap". Devmap is the same as map except that you will get console warnings that are usually hidden. Maybe that's what you're using?
The arcturus_fire material was one of those fixed as part of a wider effort to systematically find and eliminate console warnings generated from core assets. In any case, asset bugs are best reported on bugs.thedarkmod.com to avoid them getting buried in forum threads.
-
Alright, the problem in your case seems to be that the addon files have to be on the level of the base installation (in order to apply to all FMs), so they can't overwrite files that already exist in FM .pk4's. Yes, that's a limitation.
What you can probably do, however, if you're modifying scriptobjects (tdm_movers.script contains only scriptobjects), is to derive a new scriptobject from the existing scriptobject and define its functions again. See here for more. You'll also have to update the base classes of affected entities to make use of your modified scriptobject.
-
1 hour ago, snatcher said:
Do you then confirm when a mission author includes in the .pk4 a base script it cannot be overridden outside of the fm folder?
It works the same as any other file: if a file has the same name and folder location, then:
- FM files overwrite base installation files
- Files outside .pk4's overwrite files that are inside .pk4's
If you want to override the base version of tdm_mover.script, include your own copy of tdm_mover.script in your FM or addon package.
-
10 minutes ago, snatcher said:
Example with a base script:
- TDM/tdm_base01.pk4 ~ script/tdm_movers.script
- TDM/fms/anymission.pk4 ~ script/tdm_movers.script
- TDM/fms/anymission.pk4 ~ script/tdm_custom_scripts.script ~ #include "script/tdm_movers.script" (let's pretend this happens)
- TDM/fms/anymission/script/tdm_movers.script
- TDM/fms/anymission/script/tdm_custom_scripts.script ~ #include "script/tdm_movers.script" (let's pretend this happens)
- TDM/script/tdm_movers.script
- TDM/script/tdm_user_addons.script ~ #include "script/tdm_movers.script" (let's pretend this happens)
TDM/fms/anymission/script/tdm_mover.script replaces the 2 copies of tdm_mover.script in the .pk4 and the base installation.
tdm_custom_scripts.script and tdm_user_addon.script can be deleted because tdm_mover.script is already #included by tdm_main.script.
-
1
-
It's not a question of overwriting. When the map loads, the #include lines are replaced with the contents of the specified .script files so that you get one giant merged script file in tdm_main.script. tdm_main.script includes tdm_custom_scripts.script, then tdm_user_addons.script, so the contained scripts will be added in that order.
If you #include the same .script file multiple times from different files, like in your example, you risk getting multiple copies of the same script which causes map loading to fail - see one-definition rule. Inclusion guards (#ifndef, #endif etc.) stop more than one copy of the same script from being added.
If you want your version of the script to take priority, you should give it the same file name and folder location as the base script, without using tdm_user_addons.script. It works the same as, for example, letting a custom model take priority over a base model.
-
2
-
-
@Araneidae I've posted on your bugtracker #5888
-
Yeah I noticed it too. This would be a case for @duzenko
-
1 hour ago, Obsttorte said:
The script function getNextKey allows you to go through all spawnargs with a specific prefix (like def_attach for attached entities).
Problem in this case is that def_attach only returns the classname (entity type) of the attached entity, while name_attach is not the actual name of the attached entity, but an internal name to allow other spawnargs to modify this attachment.
-
An alternative option to make attachments non-solid is to set spawnargs in the format "set x on y" "z". In this case it would be something like "set solid on armor" "0".
y is the name_attach (not the $name). You can see what the attachment name is by checking the AI's spawnarg list for "name_attach" spawnargs, matching the "def_attach" spawnargs.
For example, "def_attach2" "atdm:breastplate01", "name_attach2" "armor" -> y is "armor".
-
Now we just need to remove the console clutter from core asset bugs and pointless mass-warnings and the console will be perfect.
-
6 minutes ago, cvlw said:
I am not referencing as any ragdoll that I know of, just the name of the ai entity.
It seems there may be something to KOed ai having a different entity name. I did $ai.setContents(0) on a living ai and he went invisible but still interacted with stuff.
How might I find the name of an ai AFTER they are KOed/killed?
Thanks again
Clint
The name definitely doesn't change after a KO/kill. Maybe setContents just doesn't work as expected for AIs.
-
This pinned thread's purpose is to collect links to all the discussion threads for new features to be added in 2.11.
[2.11] GUI warnings and changes
[2.11] Large static meshes no longer considered dangerous for performance
[2.11] Frobstages: automatic generation and customization
[2.11] New Blackjack System (available via dev build)
[2.11] Stencil shadows optimizations
As well as older feature collection threads:
-
3
-
-
You can try setContents(0), but this will also make them invisible to AIs, unfrobable and maybe cause them to fall through stuff. The most practical would be to ensure there's enough space.
-
1 hour ago, snatcher said:
@Dragofer the trace works, thank you very much
vector player_pos = $player1.getEyePos(); vector flame_pos = small_flame.getWorldOrigin(); if(sys.trace(player_pos, flame_pos, '-0 -0 -0', '0 0 0', CONTENTS_SOLID, self) == 1) { // go! }A question for everybody: what are '-0 -0 -0' and '0 0 0' for? A tolerance? Not sure I should use them.
It's the positions of the top left and bottom right corner of the box that the trace moves from the player's eyes to the flame. If the box hits anything else on the way the trace returns less than 1.
If you don't want to use a box you may as well use tracePoint instead and delete those two vectors.
-
16 minutes ago, snatcher said:
Which base objects do the below flames get attached to?
- light_candleflame_moving
- light_oilflame_moving
I don't know what these are for
You'll find them in "def_attach" spawnargs of candle holder entities. I doubt any holders use the moving versions, though.
Can unpack all your TDM .pk4's and use Notepad++ to search in .def files for such spawnargs.
-
Most walls in TDM are 8-16 units, so reducing distance won't be adequate. You can let the script do a trace to detect whether there is something solid inbetween you and the candle. My camgoyle turret's scriptobject, as found in my scripting thread (see signature), makes use of traces.
-
1
-
-
3 hours ago, Obsttorte said:
If the player frobs the flame, it gets extinguished.
I don't think particles can be frobable since frobbing seems to rely on clip contents. Also, I donxt think the flame materials have frob highlight stages yet.
Well, maybe you can at least use SetContents after map start to make the particle solid to frobbing throughout its entire bounds (warning: rabbit hole).
Probably more realistic to frob the candle vs. the holder.
-
Obsttorte wrote a trigger_look script which should be available as an entity in the base assets. Otherwise you could try looking it up on the forums.
-
I think @AluminumHaste could share some tips with us all.
-
Had best bring a knife to carve a path through that fog.
-
3
-
-
On 7/15/2022 at 8:26 AM, wesp5 said:
Speaking of which, would it be possible to display the long descriptions from the shop menu when we highlight a player tool on the big inventory screen? This way players could always take a look to remember what tool does what.
Yeah, try looking at how popup tooltips were done for main menu settings. Shop item descriptions are found after #str_02256 in strings/english.lang
canBeBlownOut seems to exist to stop flames from being extinguished by fire arrow blasts.
-
Yeah, I mentioned door handling position entities for this a little earlier on.
Fan Mission: Old Habits by Obsttorte (2012/10/19)
in Fan Missions
Posted
The mission has been given a small maintenance update to ensure it'll remain compatible with a tweak to custom assets handling - there should be no changes visible ingame. Some clutter like old snapshots of the map file has also been removed so that it's become a smaller download than before. Update provided by Obsttorte.