NAB622

There are no compile options, it is simply a matter of using nonsolid shaders. My understanding of it is that during compile, q3map2 will pick a random face from each brush and use that face's nonsolid property. So if you want to ensure the brush is nonsolid every time, all 6 faces of the brush must use a nonsolid shader. Nodraw fits the bill for the non-visible sides. Make sure your force field has a shader with surfaceparm nonsolid in it.

Sound files must be mono, and I think they have to be sampled at 44.1 KHz. Surfaceparms are all applied in shaders, outside of Radiant. Also, if you are trying to make a nonsolid wall, make sure all non-visible sides of it use textures/system/nodraw. This will ensure it is always nonsolid when your map is compiled, and it will prevent the nonsolid sides from culling adjacent planes, making visible holes in the map.

On Windows Vista and above, you have to right-click Radiant and choose "Run as administrator" or it will be unable to save map files. I haven't tried it on Windows 10, since I no longer use Windows. Also, your entity list looks fine, nothing to worry about. You'll likely only use a handful of the misc_ entities anyway.

Radiant 1.4 might be trying to load files from another version of Radiant. Is it installed in a separate location from every other version? Also, IIRC 1.4 needs to be run as administrator.

What string file, and what coding? I'm not sure what you're talking about.

Nonsolid anything is accomplished with a shader. Use a shader with surfaceparm nonsolid for the force field itself, and on all other surfaces of the brush use either textures/system/nodraw or textures/system/caulk_nonsolid. What do you mean by reading a string file?

Wait.....For some reason I was thinking you used misc_bsp. If all you did was add a target_level_change, where did you add it on the entity list? I think depending on where you put it, it might change which entity is linked to the lightmap, and that would definitely break all switched lights.

Wow, that is really weird. Sorry I can't offer any other suggestions.

Radiant 1.5 is highly controversial. Many people swear by it. And then it does stupid stuff like this. There's even a bug in it that causes a phantom sv_setBrushModel: null error. I would never recommend it to anyone. I don't like NetRadiant either, but at least it has a better chance of these things being patched, since it's in active development. (NetRadiant is based off of Radiant 1.5)

Two things come to mind. First, is Radiant set up to edit the correct game? It's really a shot in the dark, but maybe there's a different game with an entity setup like that. Second, and I can't believe I'm actually saying this...I do not recommend anyone use Radiant 1.5. I don't know if that is causing your issue, but for now you might try NetRadiant or Radiant 1.4 and see if it persists. I can not recommend Radiant 1.6 because it has even more bugs than 1.5 does. NetRadiant or 1.4 are the only reasonable options.

First and foremost, is the server running JA+? Also, what do you mean by /amvstr hook command? What is the exact command you are giving the server? Lastly, what did you add to server.cfg? Are you able to remove the passwords from it and post it?

Unfortunately, I don't know the answer to that. I've never seen that behavior before. What version of Radiant are you using?

Correct, Radiant should not be doing that. When you are connecting entities, it should only be changing the target and targetname values.

Any sort of conditional movement between varying distances/locations must be done with a script. Any movement between just two points is a func_door. I'm not entirely sure what you're asking, but textures/system/trigger is invisible in-game. It is visible within Radiant only. As far as the door opening by itself when the player gets close, all doors do this by default unless they have a targetname (Triggered by a button or a trigger) or have the player_use box checked. I'm not sure how you keep doing it, but you have a func_door1 and two func_usable1 entities. These are not valid classnames. Do not change the classname value of anything in Radiant. They should be func_door and func_usable. By changing the classname, they will no longer work in-game, and their brushes may be culled by the compiler.

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?