NAB622

Shaders are applied just like any other texture. Check the entity window for func_button, because I believe you'll have to tick a checkbox to enable this feature. Then just choose a pre-existing shader or make one of your own.

You're definitely entering the territory of a code mod, there. If this can be done without it, I want to know how, because that would be one impressive technique. Sorry, I won't be much help on this subject.

I do not believe this is possible. The only way I can think of doing it would be to use a script to copy the player's origin to the swoop bike, then copy the origin of the swoop bike to itself in the same instant to force it to move. Even if it works, it is most likely just going to telefrag the player. Not to mention, swoops have a bug in MP where if one player is on a swoop, other player's cameras can spin like crazy, making the game unplayable. I recommend avoiding them, at least for base game.

As far as I know, scripts are in-game only and have nothing to do with menus, but I don't mod single player so I could be wrong. For a mine under a brush, anything you need triggered can be done with a trigger_once or trigger_multiple. For a delay, you can use a target_delay. As far as the mine itself, I'm sure you'd want to use a func_breakable for the floor, and there are several routes to go for an explosion. As for the switch changing textures, there are a few ways to do that, depending on how the button works. From memory, I beileve a func_button entity will allow you to use an animMap shader, and it will switch from the first texture to the second when it is used. I think. Been a long time since I poked at that. Another option is shader remapping, but that can get pretty messy and I'm not sure it works in single player.

Actually...this raises a good point. Does the entity modding you were doing include the lights as part of the entity list, or are they removed by default? Lights with a targetname or a style should always stay, but I could see an entity modding tool/method/guide removing all lights by default.

I don't know if this is fixable or not. I'm pretty sure what is happening is the portion of the lightmap connected to those lights is becoming separated from the light entities when you are editing the entity list. I'm not sure how I would confirm this theory or address the problem, though. You have a great voice, by the way!

I have two guesses..... 1. There's a limit to how many models can be on-screen at once (Highly doubt) 2. There's a bug in the code for the Gran that doesn't preload the thermal detonator model. #2 should be easy to check by spawning a thermal detonator somewhere in the level before dealing with the Grans.

I think there's a lot of misunderstandings leading to the result you are getting. What exactly are you trying to get the door to do on the cargo container? If you want it to follow the cargo container around the map, it can not be functional unless the cargo container is stationary. And even in this case, the door and the cargo container must be operated using a script, which will complicate things in a different way. As far as the path_corners, I do not know why you are seeing those odd results in Radiant, and I do not have access to Radiant right now. My best guess is that one of the entities got dragged off into the void somewhere by accident. However, I'm pretty sure they're all supposed to be classname path_corner (Not path_corner1, path_corner2, etc), and each one is supposed to be targeted at the next one. If you want an example of a working func_train, open the sample map mp/ffa5. There's a func_train elevator in the tall building. This is all irrelevant if you use a script, though; the script would have to replace the movement of the func_train, as well as determining the position and movement of the door. All of that being said - in my opinion, the best way forward would be to go without a door on the cargo container; if you want a classic star-wars style take on it, use a nonsolid force field in place of the door. If you absolutely must have a door, just know the limitations, and that you will have to script everything.

Sorry I took so long to respond. From what I can see, the current behavior of the map should be that the func_train entity will move around the map without the two door entities. The door entities will stay exactly where they were placed in Radiant and function as a usable door, floating in mid-air. There is no angle specified on the doors, so I do not know if they will move anywhere, but they will be usable. Is this what you are experiencing in-game?

I don't know off-hand if Jkhub supports attachments. If not, put the .map in a .zip file to shrink it, upload it to any sharing service (Megaupload, mediafire, etc), then post the link. Hopefully it won't get blocked by spam blockers.

The two issues I do see right now are that there are no scripts attached to the door, and the door has the player_use flag without a wait key, which will cause it to misbehave when used. However, neither of these should cause the door to disappear. Right now all I can do is blindly guess, which isn't going to be helpful. Can you post the .map file?

Looking at the photos, I'm not sure what's going on. I'll need some more details to be able to tell. Can you start with the entity window data for the door and the scriptrunner, and maybe a screenshot of the entire cargo container in Radiant? As far as a target_scriptrunner, it is not a brush entity, so you can place it anywhere in the map and it will function just fine. There is also a way around using it, which you can probably do here, but one thing at a time.

That sounds like what I was looking for, yeah. Which CVar is it? I'll add it to ParaTracker's bit value calculator for future reference.

Wow...I actually can't find any of the old resources regarding server.cfg any more. Does anyone happen to know one? That really needs fixed, it's guaranteed to kill the game off. I can make a web page to help create a server.cfg, but I need a sample to work from and I don't have my old server.cfg any more. That said - I don't see any options regarding ysalamiri in server.cfg, but I can't find any samples to check. Are you running the dedicated server from the same game files you are playing from?

Check server.cfg, sounds like ysalamiri are disabled.

If this were a script, that's a valid point, but this is just a trigger_multiple firing a target_print. Nothing he is describing should be happening at all.

Oh, wow. Everything you are doing is correct, so this has to be something with the game. Maybe you should try a reinstall, or a test install in a new location. Something's really royally messed up.

The video is marked private, can you set it for public/unlisted?

If you hit the entity limit, the game will immediately crash, so that is definitely not the problem here. Although, you are certainly close to that limit (1024), so be careful how much more you add. The best place to start is in the entity window. Can you show the parameters for one of the triggers and one of the spawners? Maybe they're triggering a script or something, or there's a targetname conflict. Also, if you haven't already, start your map in-game and type /developer 1 in the console, it might give some helpful debug messages.

Is that model using a shader, or a texture? And what is the path?

You are looking for target_counter. When triggered a specified number of times, it will fire it's target.

Scripts are made with BehavED. It should be included with the modding tools. I don't think it runs on my current computer (Linux), but I'll be happy to give you any guidance you need, as scripts can be a bit daunting at first. There is also a LOT of bad information out there - most tutorials take a pointlessly complicated route. Feel free to ask lots of questions. You can also find me on the JKHub Discord if you would like.

It is not possible for a mover to function in more than one way, and there is no way to attach movers to each other. Believe me, I wish it was possible, I would have abused that to no end in all of my projects. Even if you use a script to move everything in unison, as soon as the script moves the door, it will no longer function as a door, negating the purpose. Now......if you are okay with the door only operating when the container is stationary, you COULD script the door's movement separate from the container. If that's okay with you, then it's your best bet, but it's a bit complicated, as you will have to manually script every part of the door's behavior, and ensure it doesn't conflict with the movement of the container. The only other options involve faking the movement, similar to T1_rail, or using some other tomfoolery like a skyportal, which will definitely not help you here.

I might be misunderstanding what you are doing, but.... Are you trying to make a moving container (The func_train) with a functioning door on it? The door is not possible in JA as part of a larger object, even with scripts.

What is the exact error you are getting? Surely it's saying more than just NULL?