Newbie DarkRadiant Questions

[grayman]

I'm afraid I dont really understand how to make a func_static hidden? If I understood the scene correctly, the board and its "replacement" pieces are overlapping (and dont seem to zfight because they have the very same texture mapping?), so wouldnt pieces on the floor be visible the entire time? Or do the "replecement" pieces only appear in game when the boards' health become zero? Sorry, Im not really good at this!

 

If you look at the broken-board func_static, you'll see the spawnarg "hide" set to "1". That hides it at spawn time. When the unbroken board is struck and dies, it targets the broken board, which causes it to "unhide".

 

You can't see any z-fighting in game because the broken board is hidden and not being rendered.

 

If you add pieces on the floor to the hidden, broken f_s, those pieces will also be hidden until told to show themselves.

 

Is there a way to spawn seleceted piece models at the moment of the hit (that will fall naturally)? This is not crucial as Im more than happy with how its set up right now.

 

I'm sure there is, but I haven't put any time into making that sort of thing happen.

[Baddcog]

Yes, I think we have some pots that break or something... It would be a def file thing. But sorry, I'd have to dig awhile to tell you, I am pretty sure Tels was working on making the pots or other items break so he'd be the one to ask for a quick reply.

 

I think mod wise it was just chosen not to make everything breakable because of 'feature creep' or some such.

[RPGista]

Thanks a lot guys. I also created a new plank and applied the spawnargs listed on that breakables wiki article - health, and then broken, that works but I wasnt able to use the def_flinder set of variables, you can hear the plank breaking but it doesnt disappear, and no pieces were spawned (actually, is it used on the bottle entities, because though I've seen them breaking, I never saw any glass shards like in the example?).

 

This will work perfectly.

[SeriousToni]

You all are allowed to bash me because I have so many questions, but here we go:

 

I have made a switch that turns a light on and off. But now the model still shines in the dark as it was on (the light entity goes off like it should).

 

The model for the light is models/darkmod/lights/non-extinguishable/chandelier_gas4.lwo

It's shader used is: tdm_chandelier_gas4

 

I now wanted to make a new skin for this model which has the light texture changed to a dark one, but my problem is that I

 

don't know how to change a skin on switch use

can't find the shader in the pk4 files

 

Does someone of the developers have some file tree he can look at to tell me where to find the dds and the material file for the model? I searched the most promising pk4s but didn't find anything chandielier_gas4. I would then change the dds file and create a new skin.mtr for the model. Then I'll try to change it on trigger (switch use) though I don't think this is as easy as turning light on or off.

[Baddcog]

Serious, you can load up the model (not entity, just the model) in the model viewr (ie create models>lights...) When you're looking at it it will tell you which materials are on the object, some use more than one, a lot use basic materials -ie:gold.dds.

 

And I'm pretty sure you can click on it and 'take me to material' or something... Or maybe that's once you find the shader name, then you can look up that material and view the mtr file.

[SeriousToni]

Hey Baddcog,

yes I already loaded it into the viewer, that's why I could tell you which model and shader are actually used. I already exported all existing pk4 files and found the .dds files which I need to change. Then I made a new skin file and implemented it. It was straining because I had to export each single pk4 seperatly to be able to search it for the needed files.

 

Now I only need to know how I change a model skin on trigger use (light switch thqat changes also the light on/off)

[grayman]

Does someone of the developers have some file tree he can look at to tell me where to find the dds and the material file for the model? I searched the most promising pk4s but didn't find anything chandielier_gas4. I would then change the dds file and create a new skin.mtr for the model. Then I'll try to change it on trigger (switch use) though I don't think this is as easy as turning light on or off.

 

It's in tdm_models_lights.mtr.

 

I don't know which pk4 it came out of.

 

If you have disk space, I suggest expanding the pk4 files into a tree structure. That makes it easier to find things, especially if you have a 'grep' program that will let you batch-search a folder of text files.

[SeriousToni]

Heh, that worked out even before you posted grayman

 

The frob_action_script spawnarg specifies a script that is run when the user highlighted the item and presses the Frob key.

This is for instance used to open doors, trigger buttons and lights etc.

 

But for the skin change on button press I fear I must write a script, am I right?

Edited January 8, 2012 by SeriousToni

[grayman]

But for the skin change on button press I fear I must write a script, am I right?

 

Yes.

 

If you need help doing this, just holler.

[Springheel]

(actually, is it used on the bottle entities, because though I've seen them breaking, I never saw any glass shards like in the example?).

 

You can look in movable_kitchen.def...the bottle_base entity has some info about breaking and spawning pieces.

[DeTeEff]

Yes.

 

If you need help doing this, just holler.

 

I believe this worked before 1.06 was released...I used the entity light_colorme_model and added the spawnargs skin_lit and skin_unlit, then the appropriate skins that the editor shows when one clicks 'Choose skin'. Then the lever targets both the light_colorme_model (lamp itself) and the light entity and it would work but with the update my lights stop changing and they are stuck at a lit state when the lever is frobbed...one could use some kind of show/hide script but it feels redundant when the info in light_colorme_model states that it should change as it is targeted;

 

"A light that takes a colorme model (or skin) as the physical light. If targetted the light toggles on/off and the model shows lit/unlit. Move light_center to centre of physical light. No shadows by default. For shadows, set this to radius 1 1 1 and add a second normal light then toggle both."

[grayman]

I believe this worked before 1.06 was released...I used the entity light_colorme_model and added the spawnargs skin_lit and skin_unlit, then the appropriate skins that the editor shows when one clicks 'Choose skin'. Then the lever targets both the light_colorme_model (lamp itself) and the light entity and it would work but with the update my lights stop changing and they are stuck at a lit state when the lever is frobbed...one could use some kind of show/hide script but it feels redundant when the info in light_colorme_model states that it should change as it is targeted;

 

Is there a bugtracker issue on the breakage?

[RPGista]

I have been trying to make a moveable object to cause damage when it hits something, but this article seems a little confusing: http://wiki.thedarkmod.com/index.php?title=Making_Moveables_Damage_Things, and the Damage spawnarg is not clear about how to implement it. I basicly created a cannon ball, gave it the damage spawnarg and a 40 value number (just under a sword hit), but throwing it against AI does nothing at all...

[DeTeEff]

Is there a bugtracker issue on the breakage?

 

I don't know. I've never created any bugtrackers. Do I need to create an example map and submit?

[nbohr1more]

If you have clear replication steps then a map may not be necessary but it would be very helpful.

 

If it's already been submitted they can just mark your submission as a duplicate. I don't recall seeing that as a tracker issue myself. It wouldn't hurt to double-check.

Edited January 8, 2012 by nbohr1more

[DeTeEff]

Hmm, it may well be me that have screwed up...I built the whole thing from scratch and you're supposed to use the spawnarg 'skin' and not 'skin_lit/unlit' , and then use the 'colour me skin'...

 

Strange. It seems to require another setup but the important thing is that the concept of skinchanging on lights is working

[SeriousToni]

Strange. It seems to require another setup but the important thing is that the concept of skinchanging on lights is working

 

So what must I do exactly do change it via "colorme"? I have a stadard skin and the modified one with dark glasses. Do I just insert "colorme" as variable for "skin"?

[DeTeEff]

Not at home so I cannot double check in DR but it should be done something around these lines...

 

1 Add the spawnarg 'skin' on your lamp entity (the armature).

 

2 Then click the box below, you should be sent to a window with three different skins; 'blablabla unlit', 'blablabla lit' and 'blablabla colour me'. Pick the 'colour me'. (On some entities there is a 'blablabla not unlit'.)

 

3 With the entity selected, press L and then you can set the color for your light. This will affect how the physical light will be on the model, hence the term 'color me'.

 

The armature entity may have shadows on itself and this is not always wanted. If you just add noshadows 1 on the armature, this will affect the armature AND the light so the light will seep through walls.

So if you want to avoid that:

 

1 Create a second light, just the light entity and put it inside the armature where the light should come from.

 

2 Give it the same light colour as you gave the armature.

 

3 Select the armature and shrink the light down to radius 1 1 1.

 

4 When you set up your light switch be sure to target both the light and the armature.

 

 

___________________________________________________________

Total different question that is indeed NOT a newbie question (I discussed this with Greebo and Tels a year ago...)

 

In my current mission the player will be friendly with the AI as long as they don't do anything unacceptable, like picking a lock or stealing things. I would like some assistance on how to make the AI relations changed DURING lockpicking.

 

So, some kind of function that changes the AI-relation DURING lock picking. Like it should send out signals to AI that I'm now hostile but as soon as I stop picking, the relations should go back to normal.

 

Is this achievable?

 

(No, this is not another daylight mission I've learned from my experiments!)

Edited January 11, 2012 by Fieldmedic

[SeriousToni]

I created the skin by myself because this model had no skins (lit/unlit/clorme) so I'll try to make this colorme skin and get it to work hopefully with your hint.

 

 

In my current mission the player will be friendly with the AI as long as they don't do anything unacceptable, like picking a lock or stealing things. I would like some assistance on how to make the AI relations changed DURING lockpicking.

 

So, some kind of function that changes the AI-relation DURING lock picking. Like it should send out signals to AI that I'm now hostile but as soon as I stop picking, the relations should go back to normal.

 

Is this achievable?

 

(No, this is not another daylight mission I've learned from my experiments!)

 

Wouldn't it be easier to make them hostile AFTER the SUCCESSFUL lockpicking since it would be easier to do and had nearly the same effect (?)

[RPGista]

Actually i quite like the original idea, it makes a lot more sense to have people going hostile if you are caught right in the middle of doing something illegal like lockpicking (or if you are spotted inside a private/off limits area, something really nicely done in Reap as you Sow). If it is not that hard, i wouldnt mind using this on my own mission ( a neutral civillian that should go bananas if you try opening the door to his house right under his nose)

Edited January 11, 2012 by RPGista

[Sotha]

Does it have to be especially lockpicking, the illegal act?

 

Maybe there are forbidden doors. The player has been told that stay away from these doors. If the player loiters long enough very close to such a door, the AI will get hostile. That would be easier to do. Just put an area trigger next to the door. If the player stands in that trigger too long, the AI will be angry.

 

This would also allow quick entrance with a key, without raising suspicions.

[RPGista]

Thats also a great mechanics right there, I really like the idea of "sensitive" areas and the subtlety of allowing for different degrees of reaction, depending on your behaviour. But I dont see why both shouldnt work together, complement each other, that would make it even more logical and richer. I'm remembering Fidcal's description of an experiment he did with neutral guards, that sounded pretty interesting - please guys, whenever you pull off something like this, and whenever possible, could you make it a prefab situation for new mappers to utilize? Triggers alone are pretty challenging for people getting started, it would be great to have a set of prefabs for "missions with neutral npcs", or "missions with conversations", etc.

[DeTeEff]

Hmm, no, it must be changing during lockpicking. I don't want to reveal anything specific about the mission but one should be perfectly allowed to move by the door, but not be caught fiddling with it and definitely not roaming about inside of it.

 

Gladly, this mission will be divided into three huge 'sections' that I can work on before this particular thing, so I will have time to figure something out, or maybe ditch the angry-guard-picking thing alltogether

[demagogue]

Lockpicking is a specially coded thing so ... It's hard to think of a way to communicate it that isn't coming from the source code itself, since that's where all the action is, but AFAIK you don't really have access to that that you can get in-game, and changing it so you can get access can't really be packaged in an FM. You have scripts, spawnargs, & cvars to work with.

 

Hm ... But I know scripts can check inventory matters, like what item you have currently selected IIRC, so maybe if you have one of the lockpicks selected as your use item in your inventory, a script* can get that and cue the guard (if his visalert on the player is also true or he's in proximity or whatever) to bark things like "Put that lockpick away" and get him increasingly upset if you don't after a few moments (because the script is still making positive checks every round & ticking up the seconds. It would continue until you deselected for one round and there's a negative check, then it resets. Then you add time-checks for him to get increasingly belligerent in a shorter time than it takes to pick the lock, since the idea is you have to have them selected the whole time you're picking). That might get the mechanic you want; he'll just get upset even if you have lockpicks selected but aren't using them. But you could imagine a real guard might notice that and get upset too, so even that's not too bad. Read up on the inventory related stuff for scripts to find the function that checks current selection. There's even actually a thread for it somewhere in the Editor's forum; I recall Fidcal being interested in doing inventory stuff via scripts.

 

* You'll have to get the script up & running the whole while, just making the inventory check & repeating itself. You might make it a location-cued script that opens when you enter the location, and gets killed when you leave the location, or something like that.

[Fidcal]

This really needs a new feature - probably part of a complete new look at the 'frontgate guard' friendly change to enemy thing. I'm assuming all nearby AI are set friendly to team 0? I did some workarounds on that but not looked at it for months.

 

A workaround here might be a clip brush in the doorway that tests if the player is within range. This then triggers say, once a second and call a script. The script tests if a lockpick is currently selected using either

 

scriptEvent entity getCurInvItemEntity();

 

or...

 

scriptEvent string getCurInvItemName();

 

It then triggers a target or script. What it does after that depends on the map. It might for instance switch all guards who are friendly towards team 0 to become unfriendly (so they only attack if they see or hear the player.)

 

It also needs to test when the player moves out of range or puts away the lockpick so it restores the AI to friendly. (but not if they have aready been alerted by the player because presumably they should always now be enemies.)

 

Personally I would use the double reverse 'exit' objective method to test the player is in range. Might need another pair of objectives to manage alerts and team switching.

 

Another factor might be to set the door to shouldBeClosed and should_always_be_locked

 

As you can see, the above is not trivial. Depending on story and map you might want to just consider a quick fix of testing the door is closed and assume the guards can't tell the player is doing anything special when he's standing near it (eg, obscuring his lockpicking with his body.)