Newbie DarkRadiant Questions

[Lux]

The underwater murk is an overlay. Tried this? http://forums.thedar...underwater-gui/

 

Wiki

Edited June 3, 2014 by Lux

[SteveL]

I have this piece of code for helmet overlay,

 

1=$player1.createOverlay( "guis/helmet.gui", 100 );

sys.wait(5);

$player1.destroyOverlay(1);

 

but it just cause "IdActor::SetAnimState: unknown anim group". What is wrong?

 

Also I want a overlay transition to be made by zooming out from translucent centre of visor (so I can see a visor edge and helmet interior), then it should zoom in again. What GUI parameter will do this trick?

 

Again untested, but theres a syntax error you can fix and it might turn out be the whole of the problem. You need a new variable to store the newly created gui number, instead of trying to specify it:

float hGui =$player1.createOverlay( "guis/helmet.gui", 100 );
sys.wait(5);
$player1.destroyOverlay(hGui);

 

I've never tried out guis, so no idea on the transition questions sorry.

 

 

Is there a way to make it so you can't see the bottom of a water pit thats about 140 doom units deep?

 

So far I have tried pretty much every water source but most are very transparent. I have tried placing all different types of fog lights under the water but to no avail and finally I have tried taking some already existing material files for water and removing/lowering the alpha level but it doesn't work and only causes the water to look very strange in game.

 

Fog should work if you make it very dark and lower the shaderParm3 spawnarg to around 100 to make it "thick" enough. You'll still be able to see the upper parts of the sides of your water body as you'll be looking through less fog but you won't be able to see the bottom. Some water surfaces textures look ok with opaque fog and some don't--they show banding. But if you get your fog right then you can try alternative surface textures and overlays. You'll need quite dark textures on the sides of your river else the upper bits where you can still see them might look too bright through the "fog".

 

EDIT: when I was doing this for a river, I found iron_rough to be a useful texture for the riverbed, and I a darkened a sandstone texture for the sides. The iron rough is dark enough but with enough detail to look natural.

[Goldwell]

Fog should work if you make it very dark and lower the shaderParm3 spawnarg to around 100 to make it "thick" enough. You'll still be able to see the upper parts of the sides of your water body as you'll be looking through less fog but you won't be able to see the bottom. Some water surfaces textures look ok with opaque fog and some don't--they show banding. But if you get your fog right then you can try alternative surface textures and overlays.

 

That looks great under the water but my problem is when you're standing on a platform above the water looking down it's still very transparent.

[SteveL]

Ah yes, I remember that problem too now you come to mention it. Darker textures still is all I can think of :-/ Perhaps others can offer better

[Goldwell]

It's a bit dramatic but this is what I mean by murky water

 

[Bikerdude]

It's a bit dramatic but this is what I mean by murky water

thats what we need, murky water thats clearer near the shallows.

[ERH+]

I decided to use lantern pattern for helmet but don't exactly know how to change it. Is there any FM using inventory item with button state value?

Also I want to use a stim disable command, but looks like it does nothing:

 

pattern:

* @state: 0 = disabled, 1 = enabled

*/

scriptEvent void StimEnable(float type, float state);

 

my version:

$player1.StimEnable( STIM_GAS, 0);

 

(also STIM_WATER don't' work.)

[Obsttorte]

Check out the flashbomb scriptobject.

 

Regarding the stim, I fairly doubt the player reacts to STIM_GAS. The stim is used to knockout ai, but the player can't be knocked out. Check the gas arrow files to see how it works.

[ERH+]

Modified lantern script:

void playertools_helmet::init() {
the_helmet = $null_entity;
}
void playertools_helmet::inventoryUse(entity userEntity, entity frobbedEntity, float buttonState)
{
if (the_helmet == $null_entity)
{
 // No helmet so far, spawn it
 the_helmet = sys.spawn(getKey("def_lantern_light"));
vector viewAngles = $player1.getViewAngles();
 vector origin = $player1.getEyePos();
	   setJointPos(float jointnum, float transform_type, vector pos);
/**
* Attach an entity to the AI.
* Entity spawnArgs checked for attachments are:
*  - "origin", "angles", and "joint".
* These must be set prior to calling attach.
*
* @attName: the desired name of the attachment, e.g., 'melee_weapon'
*/
 // Bind the helmet to the joint as defined in the entityDef file
 userEntity.attach(the_helmet, "light_source");

 // Set the icon to the "on" icon
 userEntity.changeInvIcon(getKey("inv_name"), getKey("inv_category"), getKey("inv_icon_on"));

}
else
{
 // helmet is already active, remove it
 the_helmet.remove();
 the_helmet = $null_entity;
 // Set the icon to the "off" icon
 userEntity.changeInvIcon(getKey("inv_name"), getKey("inv_category"), getKey("inv_icon_off"));

}
}

 

 

 

I have no idea what I'm doing... I want helmet model to be spawn in player eyes position, but don't know where to put origin and angle data.

"def_lantern_light"? why this value is in def file?

void playertools_helmet::init() {

the_helmet = $null_entity;} -what is this? What it do?

Edited June 4, 2014 by ERH+

[Obsttorte]

Wouldn't it be easier to use a gui overlay for your purpose? This would mean only two tris.

 

EDIT: You can't use the lantern script as base for your purpose. The light gets only spawned when turned on, and removed otherwise. The lantern light itself is not really used.

 

The init() method gets called after spawning. it sets the helmet to the null_entity, which it is basically no entity at all As said, don't use that.

 

EDIT2: You are binding the helmet to the lantern position, which is obviously not the head.

[ERH+]

The lantern purpose is to have a two state item: switched on (on head, with will disable drowning stim) and off. Could you write such script? Also, if drowning disable is unavailable, could you show me how loop with constant heal should look?

[Obsttorte]

Upload the helmet model and pm me the link, I'll take care of the rest. Just to make sure I understand everything.

• The helmet is an inventory item. If it gets used the player puts on/off the helmet
  
• When the helmet is on, the player can't drown.
  

If there are additional things I should be aware of , tell me.

[Digi]

Two quick questions:

- How do I get the FPS to display when I'm testing?

- Is there anything common that makes doors act funny? I ask because I have two that should just act as normal doors, but seem to get "stuck" opening and closing a LOT. I don't think it's a brush overlap with the surrounding walls...that would prevent it from opening altogether, yeah? There's a chance it's my mouse, which is equally as worrisome (it's a $70 gaming mouse, so I'm not keen to replace or fix it). It's not a big deal, but if anyone's encountered similar problems, I'd be interested to hear about it.

Edited June 5, 2014 by Digi

[ERH+]

http://wiki.thedarkmod.com/index.php?title=Console_Useful_Controls

 

Maybe you stand too close to door?

[AluminumHaste]

FPS: in the console type com_showfps 1

[SteveL]

Doors should only stop mid movement if they collide with an entity (and not always then. They can push moveables, for example). They don't collide with worldspawn brushes, they pass right through. The other way to stop a door is to frob it a second time while it's moving. The player will block a door if they're standing too close. Do your tricky doors have less space so that you stand closer when opening them?

If it's none of the above, it's hard to make a guess. Feel free to save just that bit of your map and pm it if you want and I'll try to diagnose.

[Moonbo]

If you want to be extra safe that they're not going to stop opening mid-swing you can set the "interruptable" spawnarg on the doors to 0. This will make it so that they will open all the way on a single frob and won't stop mid-way if you frob them again.

[Digi]

Thanks all around. I know there are resources in the wiki that will answer some of my questions, and I do search there before coming here. But sometimes it's just hard locating a specific piece of information. As always, though, the info is appreciated.

 

The doors are more confusing, because it's as if I'm frobbing them a 2nd or 3rd time, while only clicking once. I've doubled checked their surroundings and I'm not too close to them. This morning I opened DR/TDM again and noticed that I had no problems when I held the right mouse button instead of clicking it quickly and releasing it, which means it may be a mouse sensitivity issue. I'm not sure which I'd rather it be...a fluky DR problem or a hardware issue on an expensive mouse. For now, I'm going to assume it's a fluke on my end, and will take a harder look if others encounter it during beta.

Edited June 5, 2014 by Digi

[Goldwell]

Whenever the player is at a higher elevation than the majority of my visportals they all open up. Is there a reason for this?

 

 

Here's a screenshot of what I mean. In that picture the player is at a higher elevation than the rest of the map and all visportals open, when I move closer to the end of this alley (which is a stair case leading down) they all close. I can't seem to figure out why

 

 

 

 

 

Edited June 5, 2014 by Goldwell

[SteveL]

Are there any console warnings? Wondering if something could be making the player origin get outside the worldspawn like it occasionally does when you mantle up a worldspawn brush.

[RJFerret]

That is a behavior one sees if they noclip outside of a map.

 

Curious if you are in a proper visleaf. The point at which it changes, "closer to the end of this alley", is there another visportal in the map that shares that plane? I wouldn't be surprised if you showtris there's a geometric divide at that point.

 

My first guess would be an internal leak. Misbehaving visportal causing funky geometry during dmap would be my second. But they are just guesses, I'd have to poke around the map itself to sort it out. Perhaps quarantine that section to isolate the problem?

[Obsttorte]

Is there a noticeable drop in framerates when thos e vp's open? From the fps shown in the screenies it doesn't really seem so.

 

Are you using reflective textures in that area?

[demagogue]

I think that happens when you're looking through caulk or skybox or a broken portal or the aforementioned reflective surface or it thinks you're in a brush or the void for some reason (like the aforementioned noclipping). Something like that. I think those are all variations of the same kind of issue. Maybe if there's an internal leak to caulk or something, it might happen? (What's on the other side of that door?) But my thinking is usually it comes down to borked brushwork somewhere in the end in any event. So I start looking for that.

[Goldwell]

Is there a noticeable drop in framerates when thos e vp's open? From the fps shown in the screenies it doesn't really seem so.

 

Are you using reflective textures in that area?

 

No reflective textures and yes there is a massive fps drop. In that area there are transparent textures though if that makes the difference.

 

And where i'm standing is just on a flat surface, if I walk forward it goes back to normal its just walking between the end. Oh and as for the doors those don't go anywhere they're just placeholders on a solid brush at the moment

[SteveL]

Did you check for console warnings?