Jump to content
The Dark Mod Forums

Dragofer

Development Role
  • Posts

    2634
  • Joined

  • Last visited

  • Days Won

    157

Posts posted by Dragofer

  1. 5 hours ago, bwyan said:

    @Dragofer

    In dev16215-9224, the mirror texture is working as intended and the shading issue is present on the serving platters:

    ch1_eaton_2021-11-28_11_44_19.jpg.c1157abc0e19a3e9111209cf4ef12e8e.jpg

    In dev16225-9284, the mirror texture is no longer working and (curiously) the shading issue is still present:

    ch1_eaton_2021-11-28_11_48_00.jpg.6d3630952dca7722669b22fde7333969.jpg

    I hope this is helpful to you. Let me know if I can provide any other information that might be useful.

    Thanks for investigating, that makes it more plausible that rev 9232 is the cause.

    What would also be interesting is at what position in the map this room is: this can be done by entering getViewPos into the console. This should output a 6-figure vector (position + view angles) which somebody else can use with setViewPos to jump to that position in your map.

    You can save your console log as a .txt file after the getViewPos command by typing condump mirrors.txt. Then you'll find mirrors.txt in your darkmod folder, and its last lines should have that vector.

    Once you have that vector and a download link to 0.9, I think it's time to call in the dev cavalry (stgatilov/duzenko/cabalistic).

    • Like 1
  2. 33 minutes ago, bwyan said:

    @Dragofer I don't see rev 9232 on this list. Do I need to get a hold of that version in some other way besides using the installer?
    image.png.49cd17d46681afef392629db78bd4ae5.png

    Just FYI, I tested using dev16390-9648.

    Dev builds are snapshots of development taken at intervals, rather than with every single revision. In this case I'd suggest trying the dev builds before and after code rev 9232, so dev16215-9224 and dev16225-9284

    • Like 1
  3. 10 minutes ago, bwyan said:

    all mirrors appear completely black

    I have a suspicion that mirrors could've fallen victim to the same thing that also knocked out my parallel camera display screens (rev 9232, mentioned in tracker 5676). Maybe we can't have multiple subviews in parallel at the moment?

    @bwyanIt would be interesting to see what happens to the mirrors if you try out a dev build before rev 9232 (and maybe also just after?).

    • Like 1
  4. @Goldwell@thebigh @jonri@DeTeEffare further confirmed/possible contest participants I'm aware of - what's your stance on a deadline extension past the original Christmas deadline?

    Personally I think the most sense would be if the deadline were aimed at the 2.10 release date since part of the contest idea is to reward use of 2.10 features. But this is 1 1/2 months later (middle of Feb) than the original deadline, so it might be unfair if some of the entrants designed their mission on a small scale to be sure to meet the original deadline.

    • Like 3
  5. I'd say the Tech Support forums are the correct place for rendering issues like this. The DarkRadiant forums are for development and feedback on DR, while the Newbie DarkRadiant Questions thread in the Editing Guild is for general mapping questions.

    Regarding the silver platter, if I'm not mistaken it contains a reflective stage in its material, which might be conflicting with your mirror. It's not a very noticeable reflection imo, so could derive a new material without that stage and apply it via a skin as a workaround (if nothing else works).

  6. If you've already tried used_by scripts I don't see anything obvious down that route.

    The way I'd approach it then is:

    1) Make a looping script that checks every 0.5s what category of inv_item the player currently has selected. If it's lockpicks...

    2) Check what entity the player currently has highlighted. If its classname key is that of a door and it's locked...

    3) Loop through all AIs in the map, checking if they can see the player. Can look at the A to Z Scripting guide for a method to do this.

     

    Apart from that, you could derive a new scriptobject from the lockpick scriptobject which has a modified "activate" function that sets a global float variable for when the lockpicks were last used using sys.getTime(), and apply this scriptobject to your lockpicks via the spawnarg. Then you could have a global looping script check if the player very recently used his lockpicks, and if so check whether any AIs can see him.

  7. Would we want security camera alerts to count towards the stealth score? Triggering an alarm is imo a lot more unstealthy than making an AI wonder if he just saw something, though if there's no AI around to hear it then it doesn't really matter.

    If it should count, the next question is how much and in what category. Current alert levels for AIs are, and they add the corresponding amounts to the score:

    0: relaxed idle / weak suspicion

    1: tense idle / suspicion

    2: stops walking

    3: searching for an intruder

    4: agitated searching

    5: detected enemy

     

    Security cameras have 3 alert levels:

    sweeping (green): saw nothing recently

    searching (yellow): saw something, watching to confirm

    alarm (red): confirmed intruder

     

    The yellow state is easily reached, just stepping into the view cone is enough to trigger it. I'd say this could be worth 1 point.

    The red state is reached if the camera has had a visual on the player for several seconds, enough to fully detect him. That would make this worth 5 points. A possible question is whether a security camera detection should be counted the same as an AI detection, though.

  8. Welcome to the forums! It's always a nice surprise to see a new mapper emerge from the shadows :)

    Regarding voice acting, definitely look at the TDM wiki entry and the TTLG voice actors list.

    Regarding your map, I can see quite a few nice ideas there, but my feedback going by those screenshots is that those areas are quite wide open and it's therefore difficult to light them up adequately. How about looking at ways to divide them up, i.e. with pillars and maybe some dividing wall pieces inbetween? That way your lights illuminate a bigger portion of the walkable space, you have more points to attach lights where necessary and the player has more cover he can work with. One mission that does this very well is Full Moon Fever.

    • Like 1
  9. You're welcome!

    1 hour ago, Bienie said:

    When the player has completed all the mandatory objectives and goes to finish the mission the objective to "return to where you started" ticks off as completed, but the mission does not end.

    I'd make the same assumption as you that there's a problem with the "mandatory" setting on one of the objectives. But if that final objective already works fine, then you can just make a manual mission success logic that only checks whether that final objective is done.

    image.thumb.png.e30fc3b9740be601fa80de9f79440cda.png

    • Thanks 1
  10. 1 hour ago, Bienie said:

    It's as if finding a body does not raise the alert level at all, even though they always go in to search mode.

    According to the script, if I add a debug line to print the AI's current alert level to the console, a body raises the alert level to 4. If I lower the max alert level to 3 on normal/hard and let a script KO a team 4 AI in front of a team 1 AI in the restricted zone, then the objective fails as expected.

    Well, max alert level 3 might be a bit tough on normal/hard difficulty. Maybe bodies can be handled independently of alert level by the script.

    • Thanks 1
  11. 16 hours ago, Bienie said:

    Removing component #1 from the objective makes it not appear in game.

    That very much sounds like a DR bug. If it happens on the latest version of DR - 2.13 or the 2.14 beta - I'd suggest opening a ticket on bugs.thedarkmod.com with a download link to your current version of the FM, or a test map with your main objectives entity.

    16 hours ago, Bienie said:

    Having it in, with the script, doesn't fail the mission when the body is discovered.

    I've just made a test map to test the script and found that the AI_Use spawnarg for some reason doesn't work here (maybe because of case inconsistencies?). "team" "1" on the other hand does work.

    Looking at what you're aiming to set up with those objectives (no kill, no KO, no alert), I've added support for all of that to the script so that your objectives need nothing else than the "Custom script" component with no flags, circumventing the abovementioned probable DR bug. At my end the setup now works as it should - in the attached test map, the sandy left half is non-restricted and the wooden right half is restricted.

    Untitled.thumb.jpg.efbd45912c376442de241f166b024dac.jpg

    Also threw in a check for whether the AI's health has decreased - though there's always the caveat that an AI might for some reason lose health, i.e. because it stepped on a loose physics-enabled spoon, so there's 10 points of tolerance in this. A sword/arrow/fire arrow splash do 30+ damage, so might want to raise tolerance further. If you have elevators in your mansion, which are notorious AI killers, you'd probably want to get rid of this check.

    There's some inconsistency between your components: killing/KO of mansion residents is never allowed, but raising alerts (i.e. by being fully detected) is only a problem if it happens while they're inside the mansion. The attached new version of the script replicates this, but it can be adjusted if it's unintentional.

    restricted.scriptrestricted.map

    Spoiler
    //Dragofer's script to check if alerted AI is inside the manor
    void restricted_loop(float max_alert, float obj_id)
    {
    	ai guard;
    	entity loc;
    
    	while(1)		//loop forever, since 1 is always true and never changes
    	{
    		do
    		{
    			guard = sys.getNextEntity("team", "1", guard);
    			loc = guard.getLocation();
    
    			if( ( ( guard.AI_DEAD && guard.isPlayerResponsibleForDeath() ) || guard.AI_KNOCKEDOUT || guard.getHealth() < guard.getFloatKey("health") - 10 )
    			||    ( loc.getFloatKey("restricted") && guard.AI_AlertIndex > max_alert ) )
    			{
    				$player1.setObjectiveState(obj_id, OBJ_FAILED);
    				return;			//stop this script, obj has been  failed
    			}
    
    		} while ( guard != $null_entity );	//keep searching until no more valid entities are found
    
    		sys.wait(0.5);				//wait 0.5s before repeating
    	}
    }
    
    void main()
    {
    	sys.waitFrame();				//give time for all entities on the map to spawn
    
    	if( sys.getDifficultyLevel() < 2 )		// difficulty 0 == normal, 1 == hard
    	{
    		thread restricted_loop(4, 2);		//parameters: max allowed alert, objective id
    	}
    
    	else
    	{
    		thread restricted_loop(2, 3);
    	}
    }

     

     

    • Thanks 1
  12. 1 hour ago, Bienie said:

    It seems TDM doesn't like identical objectives so they were both deleted instead.  Putting back the "do not alert above level X" into the objective brought them back into the game and now the hidden missions are being revealed correctly.

    The fact that removing the "do not alert above x" component caused the objectives to get deleted suggests there's something going wrong there. My assumption is both of those objectives had no components at all and were therefore skipped.

    Got to make sure your "no alert" objectives have the "Custom script" component type, which shows up as "Controlled by external script" in the component list.

    1 hour ago, Bienie said:

    But even with that updated script, the objective doesn't fail when they see the body.

    Note that you're asking for an alert level of 5 for the objective to fail on normal or hard difficulty. This means that the AI is actively chasing an enemy - finding a dead body won't be enough to reach that level.

  13. 1 hour ago, Bienie said:

    The script does not seem to do anything when it comes to alerting AI in the restricted zone.

    Try replacing the loop script with the latest version, I edited in a few more changes. One of them was a correction for the spawnarg value of "AI_USE": the correct value is "AIUSE_PERSON", not "AI_PERSON" (wrote that script yesterday when I already had shut down my PC).

    Regarding objectives, this script does nothing else than set the state of either objective 2 or 3 to failed, it doesn't modify visibility. And that line didn't even take effect in your map because of the abovementioned typo.

  14. By the way, this is a new version of the script:

    • added some proper indenting with the tab key so it's easier to see what goes together.
    • added input parameters to restricted_loop() so that you can call it from main() with different parameters (max allowed alert and objective id) depending on difficulty instead of cloning the whole script.
    • added "return;" so that the script stops processing once the objective has been failed
    //Dragofer's script to check if alerted AI is inside the manor
    void restricted_loop(float max_alert, float obj_id)
    {
    	while(1)	//loop forever, since 1 is always true and never changes
    	{
    		ai guard;
    		entity loc;
    
    		do
    		{
    			guard = sys.getNextEntity("AI_USE", "AIUSE_PERSON", guard);
    			loc = guard.getLocation();
    
    			if( ( guard.AI_AlertIndex > max_alert ) && loc.getFloatKey("restricted") )
    			{
    				$player1.setObjectiveState(obj_id, OBJ_FAILED);
    				return;		//stop this script, obj has been  failed
    			}
    
    		} while ( guard != $null_entity );	//keep searching until no more valid entities are found
    
    		sys.wait(1);	//wait 1s before repeating
    	}
    }

     

    void main()
    {
    	sys.waitFrame();	//give time for all entities on the map to spawn
    
    	if( sys.getDifficultyLevel() < 2 )	// difficulty 0 == normal, 1 == hard
    	{
    		thread restricted_loop(4, 2);	//parameters: max allowed alert, objective id
    	}
    
    	else
    	{
    		thread restricted_loop(2, 3);
    	}
    }

    Edit: corrected spawnarg value from "AI_PERSON" to "AIUSE_PERSON"

    • Thanks 1
  15. 15 hours ago, Bienie said:

    I didn't understand what you meant by "my objective using the AI_USE spawnarg for identifying human AIs", so I'm not sure if I needed to do something there.

    But as it stands now the map fails to load because "AI_ALERTINDEX is not a member of ai", I looked in the tdm_ai.script file and it is listed there under the AI object section. What am I doing wrong?

    It was 2 separate sentences:

    - my assumption was your no-alerts objective is #8, you changed that to #3

    - my method to identify that an entity is a human AI was to check if it had a spawnarg "AI_USE" with the value "AIUSE_PERSON".

    The alertindex error is my fault, it's case sensitive and should've been AI_AlertIndex instead of all caps.

  16. @BienieIt seems it boils down to that you want any AI in that restricted location getting alerted to fail the mission. As your experiments showed it's problematic to implement this with conventional means, so I'd suggest making a script that loops through all AIs every 1s, checking what location they're in and checking their alert status. 

    To help the script identify the restricted locations, I'd suggest setting a custom spawnarg "restricted" "1" on those info_locations.

    The script should go roughly like this, assuming your no alerts objective is #8 and uses the AI_USE spawnarg for identifying human AIs (a bit clunky to write scripts on this device):

    void restricted_loop()
    {
    	ai guard;
    	entity loc;
    
    	while(1)
    	{
    		do
    		{
    
    			guard = sys.getNextEntity("AI_USE", "AIUSE_PERSON", guard);
    			loc = guard.getLocation();
    
    			if( ( guard.AI_ALERTINDEX > 0 ) && ( loc.getFloatKey("restricted") ) )
    			{
    				$player1.setObjectiveState(8, OBJ_FAILED);
    			}
    
    		} while ( guard != $null_entity );
    
    		sys.wait(1);
    	}
    }

    You can read more about the scripting methods used in this script here and here.

    • Like 1
  17. The aim should really be to minimise how much work you need to do, so it's more efficient to modify the volume in the sound shader (found in .sndshd files) rather than setting spawnargs on every entity that plays that sound. Even better would be, in my opinion, if the sound file's native volume is already at the level you'd typically use it at in a mission so that you don't need to change the volume in the soundshader.

    The idea of increasing sound quality by exporting sound files at louder-than-intended volume and using soundshaders to tone it back down sounds interesting, but in practice it just has never felt necessary for me, i.e. I almost never needed my sounds to be louder than is typical for the sound.

    info_location entities use "volume" rather than "s_volume" spawnargs by the way. "s_volume" works on all entities that directly emit sounds, not just speakers.

  18. @Bienie I think it's very unlikely that the team would change properties of core assets that are already in use in missions. To me that Wiki entry reads more like it discusses good practices, so when adding a new sound you should make sure the sound file is already at the correct volume so you don't need to rely on manually changing it via spawnargs or the soundshader. I wouldn't see any problems with adjusting the volume via spawnargs to your liking.

    • Like 1
  19. 20 minutes ago, thebigh said:

    Do you know if there's a complete list of new stuff added for each version?

    A while back I made a rough summary of what's been added in recent versions:

    • 2.10: security camera overhaul, xrays expanded to AIs, official support for secrets, new furniture, subtitles
    • 2.09: animated prefab of the steam engine, new assets (furniture, fireflies, ambient AIs, blue fire elementals, Eve statue, naval clock)
    • 2.08: xrays, new monsters (beastmen, running zombies, rudimentary werebeast, flamebearing skeletons), new assets (body bags, scientific instruments/papers, covered furniture, various Dragofer's stuff including decorative ship models)
    • 2.07: more Springheel modules, a few new assets

     

    • Like 2
  20. It's very much looking like I won't be able to make a contest FM with what's going on in RL - but I'll be happy to help out any participants with scripted setups (just describe what you want to do and it can probably be done) and advise on implementing new 2.10 features:

    - advanced security cameras

    - "x-ray" screens that can change the appearance (skin, model, render order) of things seen through them (not documented yet)

    - official support for tracking secrets

    Note that the contest deadline currently ends about 1-2 months before the expected 2.10 release date, so apart from x-ray screens (which have just been updated in 2.10 to support AIs) dev builds would be required until then.

    • Like 2
×
×
  • Create New...