Dragofer
-
Posts
2634 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
Joebarnin implies that you need to define self as an "ai" before you can use AI_DEAD on it. Don't think you can use the name "self" again, so name it i.e. "guard" instead. So
ai guard = self;
if (!guard.AI_DEAD)
...
Or try void ai_frob(ai self) instead of void ai_frob(entity self)
-
1
-
-
15 minutes ago, MirceaKitsune said:
I was able to refer to the frobbed entity by giving my function an entity parameter: I think TDM knows how to send it by default or something. So using this definition I'm able to refer to the frobbed AI as "self":
void ai_frob (entity self)Yes that's what I suggested yesterday on the Discord, I was surprised when it didn't seem to be working earlier, i.e. always passing player1.
For alert state, I've done some scripting based on that in invernesse.script, part of Down by the Riverside. It's also possible that I've used AI_ booleans in The Painter's Wife. Can't access that atm.
-
2 hours ago, Destined said:
The object being frobbed can be read out with $player1.getFrobbed(). If you use this instead of an entity name, this can also be used in more general scripts.
Regarding the alerted/dead states, you could try to not use these flags directly, but use the varaibles that cause the states to change. Dragofer already mentioned the getAltertLevel function for alerted AI. In order to check, if an AI is dead, you could try the getHealth function. For a dead AI Health should be 0, so this could work.
Ah, getFrobbed looks useful. It looks like it checks what entity is currently frob-highlighted, so if this gets called the same frame that the entity is frobbed it should have the desired effect.
Checking health would be fine for substituting AI_DEAD, but he'd also need something to check if the AI is knocked out. Well, maybe it doesn't matter because I doubt bark functions will do anything if called on a ragdoll.
-
@demagogue
Ah right, I just assumed global scripts would at least pass the entity they were activated from, rather than just player1 all the time. That's completely useless and would mean having to write one unique script per entity.Fortunately scriptobjects are able to solve that, since you can make all entities use the same piece of script but the variables can all be unique to the entities. For instance they allow you to use self, instead of having to refer to specific entities by name. Only problem is each entity can have only one scriptobject, so it requires creative thinking if the entity already has one i.e. a lamp with the light_holder scriptobject.
@MirceaKitsune
AI flags (all-capitalised) are a special case and their syntax keeps eluding me. I know @joebarnin
has worked with them, so maybe he can point out an example line.If it's something that starts with get..., it's a function so you always need to append brackets at the end, even if you aren't calling the function with any parameters. So like $ai1.getAlertLevel();
Also, regarding $ai1, it was intended that you'd change the "ai1" name to whatever your AI is called. The $ causes the script to look for an entity ingame with that name.
-
14 minutes ago, Geep said:
RE your other questions, I find a text search through
https://wiki.thedarkmod.com/index.php?title=TDM_Script_Reference/2.06
to be frequently helpful in the absence of other info, albeit challenging due to no actual examples as it would appear in a script.
This makes me think it could be quite useful to have a page of example script lines with functions from that page. Together with useful tips, i.e. that startSound requires you to put the soundshader into a spawnarg beginning with snd_ on the entity. Maybe also some more generic examples, like how to pass parameters, set up a trigger_touch or make a script repeat x number of times.
Probably going to have to be a different page because the Script Reference looks like it gets automatically generated with each TDM version.
And yes, regarding head turning towards the player, that didn't go well in Painter's Wife. The (sitting) AI would always be off by 60-90°, even if I bound invisible entities to the player that the AI could look at.
-
23 hours ago, MirceaKitsune said:
One more little thing: I plan to use this in campaigns too. IIRC map scripts are defined as mapname.script. Is it possible to have a script universal to a campaign, so that I don't have to copy the script file for each individual map in the list?
Yes, this is what the script folder is for, which you can find in some FMs. You need to #include them by mentioning them in a line in the tdm_custom_scripts.script file in the same folder.
As for everything else you asked about, I believe everything can be found on the TDM Script Reference wiki page, definitely worth familiarising yourself with that page if you want to do scripting. Use ctrl + f to look for words like "look".
Useful tip: if you play a sound shader, it'll automatically return its duration. So you can use i.e.
float sound_duration = $ai1.startSound("snd_conversation1", SND_CHANNEL_ANY, false);
(In this case you need to create a spawnarg called snd_conversation1 with the soundshader on the AI).
This function isn't that good for talking because it doesnt handle lip animations and interruptions, and it doesn't look like there's a function specifically for talking, so it'd be better to just switch to the conversation system and simply look up the sound duration in DR's speaker creator (new feature in 2.9) and store it as a spawnarg on the AI.
-
There's the frob_actionscript spawnarg, which calls scripts in your .script files. As far as I'm aware you'd need one script per AI, or a scriptobject that you apply to all AIs concerned.
Alternatively you can use the S/R system to add a response to frobbing on the AIs which triggers the startconversation entity. Would also want to make this single-use, i.e. by deleting the conversation entity or deactivating the response and deactivating frobability.
For controlling frobability, I know there are spawnargs for making attached entities un/frobable upon death, but I dont think that exists for the actual AIs. Might be most versatile to just have a script on a 1s loop that checks allegiance + alert state + whether theyve already spoken + AI_DEAD & AI_KNOCKEDOUT booleans of all AIs concerned.
-
Another question that'd be interesting for me: are you able to leave the painter's room or is it invisibly blocked?
A script command via console has a good chance of working, but you'd need to be aware that any saves you make afterwards won't work, so it should be the last thing you do in the mission. This is no big matter, since it's only needed to tick off an objective and it unlocks a 2nd flavour conversation if you return to him later.
These are the 2 console commands, in order:
script painter2_finished_conversation_end1();
script painter2_choose_conversation_end1x();To play the 2nd ending conversation, leave the building, then return to stand in his field of view and use the below command. Since you had already dealt with Marlow for the 1st conversation, the 2nd one will be quite short:
script painter2_choose_conversation_end();
In case this stuff doesn't work, you can find transcripts of the conversations at the bottom of the mission's collab document. The conversations go differently depending on whether/how you've dealt with Marlow.
-
1
-
-
@wotancc
glad to hear you're enjoying it! Regarding your issue, what I could suggest is going out to the streets and back in. Also, he has to see you carrying her.If unsuccessful, I'd appreciate a save and a description of what you've done so far regarding the main objectives, mainly concerning Marlow.
-
1
-
-
@stgatilov the LOD system also supports changing models based upon distance, so it should be possible to switch between particles just by applying spawnargs. And DR lets you select entities with the same classname, so these spawnargs can be tweaked after the patches have been created. So mappers would be good to go with multiple smaller LOD-enabled patches and without scripts involved, just spawnargs.
The only remaining hurdle to your approach would be to have new particles that contain multiple snowflakes per sprite. I'm guessing that'd require a fair bit of manual labour, i.e. making textures with multiple snowflakes and increasing the size of the sprites. Might be more feasible for a busy mapper to just switch to less dense snow particles in the distance.
-
2
-
-
Very nice @stgatilov
Would this also support LOD in some way? One of the advantages of having multiple smaller rain emitters is that you could apply hide distance spawnargs to them.-
1
-
-
https://wiki.thedarkmod.com/index.php?title=Model_addons_repository
as well as further repositories for sounds and other things, by Petike.
-
1
-
1
-
-
You can overwrite the mission_complete soundshader and the background image of the statistics GUI - I've done the former for Down by the Riverside
mission_complete //overwrites stock { editor_displayFolder river/meta volume 5 sound/ambient/environmental/weather_wind01.ogg }This won't be suitable for campaigns, however, because as far as I'm aware there's no way to change such things on a mission-by-mission basis (especially without making "illegal" edits of internal GUI files), only all or nothing. Got a bugtracker opened for that.
-
1
-
-
4 hours ago, MirceaKitsune said:
with just a little detail I'd like to change: Is there any way to make the beam cut off when any player or AI or object is standing in front of it?
As per the TDM Script Reference wiki page, you can do a trace from the beam's origin to check whether there are solid bodies in that direction, then place the beam's end wherever that collision has taken place. Supplementary script functions even let you figure out which bone on an AI was hit, for example. The below function is the main one:
QuotescriptEvent float trace(vector start, vector end, vector mins, vector maxs, float contents_mask, entity passEntity);
- Returns the fraction of movement completed before the box from 'mins' to 'maxs' hits solid geometry when moving from 'start' to 'end'. The 'passEntity' is considered non-solid during the move.
For making an AI run to a button to start an alarm when alerted, as far as I can tell there's currently no inbuilt support for this behaviour in TDM. The path_flee would only kick in if the AI is badly wounded or unarmed. It'd be worth opening a bugtracker entry for this.
-
1
-
I think you also need to put $player1 in front, so that it knows to add the key to the player's inventory.
$player1.addInvItem($atdm_key_simple_iron_dark_1);
-
1) There are player to AI conv in NHAT and IIRC Accountant 1 (following the fence through the sewers), but I have no recollection of them properly looking at the player. In any case, those conversations I've looked at were always workarounds.
2) Maybe you can instead let an actor trigger the key, and give the key a trigger response that frobs itself. Anyway, the script is just a single line. Would be a good idea to set inv_droppable 0 on the key to prevent the situation where the key returns to the player after he dropped it in a sewer.
3) Hm, thats strange, maybe theres more detail to it. Theres a working conversation setup on the top floor of the mansion in Down by the Riverside.
-
1) you can only set AIs as actors in a conversation. I've tried getting an AI to look at the player too, IIRC by letting the conversation run a script that makes the AI look at the player or by letting the conversation make an AI use a path_lookat node. However, the (sitting) AI did a very bad job at looking in the player's direction, so I dropped it.
2) simply let the conversation call a script which runs addInvItem on the key.
3) the way I've done it was to put AIs on a path_waitfortrigger, then trigger the AI at the end of the conversation.
-
In my opinion limits on gameplay, such as on how a player may knockout AIs, inevitably prevent players from approaching and enjoying a mission in their preferred way. Some may want to play an Expert-difficulty mission in terms of clues, patrol routes, lighting and more, but don't want to get limited like this. It's imo a hefty price for trying to increase difficulty. Much better would be to create stealth scenarios that allow for multiple solutions and that become harder on higher difficulties.
Another aspect is that there should be a good story-driven reason for the limit to exist, or else it'll feel contrived. In a tense setting like the sheriff's base in T2 it can make sense, but much less if you're just broadly robbing the city at night.
-
The first update for The Painter's Wife, v1.1, is now out! Taking on board feedback posted by players as well as receiving several additional rounds of betatesting, tons of things have changed. This includes gameplay tweaks, new routes and locations, areas rebuilt for improved performance, scripting fixes, improvements to the map, a new security system for Marlow as well as myriad fixes for mapping issues like nonsolid objects. A full changelog has been added to the first post in this thread.
Special thanks go to Bikerdude for his perseverance in getting much of this done, and Mike_A, Cardia, Garrett(Monolyth-42), Kingsal and Amadeus for giving this mission further extensive testing.
As before, there's also a slimmed down version of v1.1 that can be manually downloaded from the original post in this thread. Use this if you’re unable to run thedarkmodx64.exe, TDM’s 64-bit client, for playing this mission.
-
4
-
-
Since TDM is derived from Doom 3, changing the gravity should be as simple as changing the "gravity" spawnarg on a worldspawn brush. Haven't tested how well this actually works nowadays, though.
-
@UnrealOne on behalf of everyone involved, I'm glad to hear this! I really think this is the absolute limit for a single mission, as it's just a few dozen more objects away from starting to randomly crash, and the whole map is already highly compressed in this regard.
Regarding your question, that's a typo in the objective description, the gate in question is actually in the southwest corner of the map at street level. It's one of the many things which have been fixed in v1.1 (which has been perpetually a few final tweaks away from release for a little while now).
-
1
-
-
19 minutes ago, peter_spy said:
That's not true, actually. By default, table, when used with time keyword, spans across one second; you can add as few or as many values there as you want. The table interpolates between them by default, but if you want a square wave sort of response, you have to use snap keyword inside the table. You can also increase or shorten that initial time span with simple math operators like * or /.
Ah, then it's not wholly as laborious as I remembered, though still there are plenty of numbers between 0 and 1 involved. Almost all of the existing tables are geared towards flickering candle light (more like pulsating tbh), so if some tables for electrical flickers were made that could be a useful addition i.e. for making lit windows for industrial buildings.
-
1
-
-
1 hour ago, peter_spy said:
Actually, for a lamp with a flame you'll need a particle emitter and all the stuff that goes along with it
The standard way to make a flame light is to assign the flame particle as the light's model. This takes up the light's model slot, so you have to connect it to the lamp via def_attach which means the light's colour won't affect the lamp's colour. It also means you can't easily edit the light's properties in DR, so def_attach is only really used for lights that need a particle.
1 hour ago, peter_spy said:You also assumed that he wants to sync the lamp flicker with a sound shader
His desired result contains a flickering sound shader, so that was my assumption yes, though I skimmed through the not too concise post.
1 hour ago, peter_spy said:For starters, you can just create a light table that will flicker in any way you want, and use it both in light and model shader.
Creating new versions of materials which use tables would let him avoid exporting his brush as a model, but last I checked there weren't any tables made for electrical lights. I got pretty good results in my map using the thunderstorm tables, but that was for very dysfunctional lamps. Creating a light table from scratch seems a bit much since you'd have to define intensity frame-by-frame, while you could just sync it to one of the flickering sound shaders. Can set volume to -60 if you don't want to hear the sound.
Tbh I think a lot of Mircea's problems could be solved by exporting that brush as a model first before dropping it into an existing flickering electrical lamp. Might need to set up lit and unlit skins too.
-
1
-
-
The process peter_spy describes is mainly suited for making a lamp with a flame, since it doesn't let the light affect the lamp model too much.
For a flickering electrical light, you'll need to start with a light entity and change its model spawnarg to your lamp or filament model, change its texture spawnarg to one that ends in _snd, assign a flickering soundshader, and inherit from one of the existing sound-emitting electrical lamps.
I doubt you can assign a brush as a model, so you'll have to export it as one first. The surface textures need to be a texture that uses colorme. You'll probably also need to define new skins to override the inherited ones.
Since you can only assign a light one model, it'd be much more convenient to combine the lamp and filament into one model.
FYI: Ambient stage no longer needed in materials
in TDM Editors Guild
Posted
Definitely, this would massively reduce clutter in materials.
Also great would be to move frob highlight stages out of materials, or as an intermediate solution turn them into a single line instead of 2 blocks. But I think this is a separate issue from ambient methods and could be addressed afterwards.