Jump to content

NAB622

Members
  • Posts

    550
  • Joined

  • Last visited

Everything posted by NAB622

  1. I believe the models are inside assets0.pk3. If not there, then assets1.pk3.
  2. Autosprite2 is mostly used for energy beams and effects-style stuff. In the single player campaign, I believe the chains on Korriban use it. I've used it in several of my own creations, too. Taspir Power Complex v3 uses it on the CTF map. There are small vertical energy beams surrounding the flags for each team. Don't know if I ever released the source files for that, though...
  3. That's really strange. I get the feeling something else is at play here. The only way I can try to help further is to see the .map file and the shader file. Sorry I haven't been much help on this one.
  4. Okay, yeah, you'll definitely want to remake that brush. Don't do any vertex edits, make sure there's no chance of the game getting confused. Now..... In my opinion, autosprite2 isn't even a great idea here. The candle is large enough that you should seriously consider creating it out of geometry, with either a 12 sided brush or a patch mesh. Use autosprite2 for the flame at the top. In both cases, if you are using brushes be sure to also mark them as detail (Ctrl + M), that should discourage the geometry splits on each face.
  5. After thinking about it for a bit, what does the wireframe on that brush look like? Maybe it has a bunch of invalid faces. That could certainly cause issues.
  6. We learn by doing, and that goes for me too!
  7. Actually, that's okay to do for most edits. Certain things like lightmaps have to be compiled, so recompile your map and reload the level in-game, and you should see the changes. That's probably why it suddenly started working for you.
  8. Ah, sorry, I misunderstood your issue then. Can you post a screenshot?
  9. Autosprite2 works across the longest axis of a surface . Try making your surface rectangular instead of square.
  10. Here's what I would do..... I would make the candle flames a separate texture on a pure black background, add them as a separate stage to your shader, and use blendFunc GL_ONE GL_ONE on them so they blend properly with the environment. For the candlesticks, remove the blendFunc, and use an alphaFunc to mask them. I haven't written shaders in forever, so I can't write an example, but if memory serves, the landing pad texture at the center of mp/ffa5 is a great example of alphaFunc in action if you need it.
  11. Can you post the image as well? If it's just a flame, forget using alpha and just use blendFunc GL_ONE GL_ONE.
  12. /developer 1 is a CVar that needs manually typed into the in-game console, not added to the script. It will show the execution of the script as it goes, making troubleshooting much easier. It likely won't help me very much, but it could help someone more experienced with single player scripts to determine the problem. If you're using something as a template, I would suggest reverting to that method, since ultimately I'm just shooting from the hip. The suggestion for /developer 1 and the print blocks remains a good idea, though.
  13. I don't work with single player, so this might be wrong, but I believe you can remove the "Affect" block, and check the "runonactivator" flag on the target_scriptrunner. I can verify that it does work that way in multiplayer. To further troubleshoot, I would add a few print blocks to the script, set /developer 1 in-game, and see if the prints show up in the console. That should help you determine exactly where the failure is.
  14. Assuming SoundGroup is not a thing.....a simple script and a series of target_speaker entities is 100% the cleanest way to go. If you want to set up an entity system to play random sounds without a script, use some kind of a trigger (I'll use trigger_once here), target_delay, target_random and target_relay. trigger_once | | v target_delay <--------| | | |-------> target_relay | | v target_random | ------------------------------- | | | v v v target_speaker target_speaker target_speaker Target_delay has a random key, use that to create your randomization. Edit: A side effect of this setup is that the trigger_once will also trigger the target_random, since they'll end up with the same targetname. All it will do is trigger a sound immediately before the delay takes place, so it's not a problem, just something to be aware of.
  15. Target_speaker is buggy as hell. Several of the parameters don't work. I don't think the wait key does anything on them, either. You might be better off using target_delay or a script to fire it every few seconds or whatever. In fact, if you're looking for random sounds, that wouldn't be a bad idea, in my opinion. I've never heard of SoundGroup before....is that even a thing in Jedi Outcast/Academy?? It looks like your Radiant is set up for Voyager: Elite Force, judging by the Borg reference. Try changing it to Jedi Academy and see what happens.
  16. Are you modifying the base game's assets1-4 files? Definitely don't do that. It's just asking for trouble.
  17. For numerous reasons, don't edit a PK3 directly. Use a project folder to contain your mod, and create a new PK3 when you want to test it. Or if you want, you can start the game with sv_pure 0 and it will also load assets directly from the base folder as well, which is great for testing mods. I've never heard of files going missing from a PK3, but due to the nature of how ZIP files work, it is a bad idea to ever edit one. I've seen them bloat for no reason, and I've seen them take forever to do a simple edit. Never seen files go missing, but it wouldn't surprise me.
  18. My recommendation: make the shaft any shape you like, but make the door square. The physics engine in JA will bug out like crazy if you try to rotate a cylindrical door around the player. Believe me, I've tried. It's not worth the effort. If you want to time the movement of the door with the elevator, you may want to look into scripting the movement. Edit: As far as cutting the shaft, you're probably looking for the clipper tool. If the button is missing or you can't find it, press X.
  19. Eh, consider me a "Wannabe" as far as Radiant is concerned. I have my own set of annoyances with it, and yes, it's very slow to edit many things. But since you've used a different editor, I was curious what parts of Radiant specifically bothered you, compared to the other editor.
  20. Noted.
  21. You've made me curious, how is GTK hard? I'm not saying it isn't, I'm just genuinely curious what parts bother you.
  22. Well, I thought this was common knowledge, but I guess it isn't. The title of this tutorial says it all - you can make ASE models using nothing but GTKRadiant and a simple trick. Before we get into details, I'll start out by giving you the advantages of using ASE models over MD3s: • ASE models do not need UV mapped. They get textured like everything else in Radiant. • Because they reference the original textures, this can reduce load times. Think about it - if your map already uses the textures you apply to your model, it has no new textures to load! • ASE models do not have the "always drawn" glitch that MD3 models do. This saves a few FPS. • ASE models zip up very nicely, since it's just a text file. • You can use curve patches in your ASE models. • Making an ASE in Radiant is just as accurate as making an MD3 in a professional program. I know what you're thinking - Radiant's grid is not small enough. Just trust me on this, I'll explain it later on. It's actually more accurate to make a model in Radiant, because you are forced to snap everything to the grid, meaning no offset origins. Now, to be fair, there are a few downsides: • Since there is no UV mapping, you can't get quite as much texture variety. • You can't use these models for anything else in JA - just map objects. • Misc_model is the ONLY entity that can use ASE models. Everything else requires an MD3 model. This includes the model2 key on func_ entities. This will be short and sweet, so let's cut to the chase. Start GTKRadiant. Once it is open, you need to ingrain this message into your head: Build everything at least four times as large as you want it to be! This is important! The entire process hinges on this. Not only will it be easier to edit, but this is what enables you to make higher detail models. In Radiant, you will see the origin (0, 0, 0) point of the grid. This is where the base of the misc_model will be. Build your model anywhere on the grid. You'll have to move it at the end, though. For this tutorial, I'm going to pull up an old, somewhat lame model I made of a lantern. Click here to download the lantern's source files. I would suggest following along with them the first time around, and once you get the hang of this, you can do it on your own. Don't forget to add lantern.shader to shaderlist.txt if you use this example! Not the best model, but it worked for what I needed. Anyway, here's a look at the grid view. Check out the scaling: As you can see, this thing is MONSTROUS. That's because I made it 10 times bigger than I wanted it to be. Notice that the textures are stretched large on it as well. There is a reason for this. <a name="important" style="color: rgb(238, 255, 255); font-family: 'Times New Roman'; text-align: -webkit-center; background-color: rgb(0, 0, 90); font-size: medium; ">IMPORTANT: Your model must have AT LEAST one structural brush somewhere on it. This is easy to cheat on - just add a structural brush of caulking in a random location. It won't affect your model in any way, and it's invisible, so it doesn't matter where. In the lantern example, I made everything detail except the stem of the lantern. I don't know why I bothered, but I did. If you fail to do this, no ase file will be created and no warnings will be given. Additionally: You need to get the origin at the correct spot. This is critical! You can't put the origin in the middle of the model, or it won't work properly. Whatever part of this model will be attached to something is where the origin in Radiant must be. To put it simply: If your model is going to hang from the ceiling, you need to make the top of your model touch the map's origin in Radiant (The lantern is a good example of this). If it's going to sit on the ground, you need to make it touch the bottom. If it's going to hang on a wall, you need the origin to be against the side of your model that will be against the wall. You'll see why this is important. Now, let's convert this into an ASE model. I use Yzmo's .map to .ase Converter Utility to create ASEs, but you can also do it with q3map2GUI, q3map2build, or even just with cmd.exe and q3map2.exe if you like. I'm going to use the .map to .ase converter, because it's easiest to explain and use. Once you have it downloaded and installed, read on. Once the program is running, click the settings button and give the program the paths to q3map2.exe file and your GameData/base/maps folder. Uncheck the Make Window Semi Transparent box if you like, then click ok. You should see this: Now for the juicy part. Make sure the .map you want to convert is in your GameData/maps folder. Now, just type the name of your .map file (minus the .map extension) into the first box. You can leave the second one blank if you like. Press enter and watch it go. Open up your GameData/Maps folder. You should see two new files: lantern.srf and lantern.ase. Delete the .srf file and copy the .ase file to whatever folder you want. I'll copy it to GameData/models/mymap as an example. If you do not see any files, make sure you read the warnings above and try again. We're almost done. Now we just need to add the model to our map. Load up whatever map you want to add this model to. Find where you want to place the model, right-click on the grid and create a misc_model. Note: misc_model_static does not work with ASE models! When opening the model, You'll have to change the format to .ASE to see it: Once you get the model loaded, you should see it's massive bulk eat up a ton of space in your map. We're going to fix that next. With the model still selected, press N to bring up the entity window. Depending on what scale you built your model to, you'll have to scale it differently. If you made your model four times the size you wanted, you'll need to enter: Key: modelscale Value: .25 If you built it to a scale of ten, like I did, you'll need to enter: Key: modelscale Value: .1 If you built it to a scale of two, you would enter: Key: modelscale Value: .5 Here's what the entity should look like if you built it on a scale of 10: For extra realism, you can also check the "lighted" checkbox. If you do not have a "lighted" checkbox, you need Darth G's updated entity definitions. Here's what it looks like with the correct modelscale value: Much nicer, isn't it? Few things in closing. Instead of using the modelscale key, you can use modelscale_vec and give it three different values (.4 .8 2) and scale it on each axis individually. Also, instead of using the angle key to rotate your model, you can use the angles key to rotate it on every axis individually as well (20 45 90). Thanks for reading this tutorial, and I hope it helps you in one way or another!
  23. If I recall correctly, bots will use anything they come into contact with automatically. If there is a flag to use for that, I am not aware of it and I did not save the source page, so your best bet would be to check with one of the coders and see if they know.
  24. So what are botroutes? To put it simply, botroutes are a path of waypoints that bots will follow. (Pretty babyish way to put it...) These waypoints are numbered so they each have a unique ID. Bots can follow these waypoints going forward through the numbers or backward, unless you specify otherwise (special case covered at the bottom of the page). If you make the paths correctly, this will tell the bots how find their way around the map. Botrouting is done trough the Jedi Academy/Jedi Outcast game console. Start the game, then open the console by pressing Shift + ~. Start your map by typing: /devmap [your map name here] I'm sure you knew that command already, but it's necessary for this. There are a number of commands you will use to make and save your botroutes. The most commonly used ones, and really the only ones you should ever need, are listed below: /developer 1 /bot_wp_edit 1 /bot_wp_add /bot_wp_rem /bot_wp_save Once your map has loaded, open your game's console again and enter the following three commands: /developer 1 /bot_wp_edit 1 /devmap [your map name here] DO NOT FORGET to restart your map! You need to do so to enter bot route editing mode! The picture below shows the game console window open with the commands that I entered circled in red. Then, I restarted the map by doing the /devmap [map name here] command again. Once your map has reloaded, you are ready to begin making your botroutes! This is quite easy, as I said above. When you add a point, it will be added where your player is standing. When you delete them, it moves in reverse order, deleting the most recent one you made and going back to the first one. With that knowledge in mind, stand somewhere in your map and then type in bot_wp_add. You should see some zeros begin floating up from the ground, like so:. You have just created your first waypoint! Whenever a bot is near this point, it will stay near it and look for another close waypoint, or an object that it wants to pick up. But one waypoint won't do you a whole lot of good! What if the bot spawns in another room and can't see your waypoint? The only way to solve this is to finish creating a path that covers all the major areas of your map. If you have unconnectable rooms or areas, you CAN disconnect your bot route and make a second one inside that building or room...but it doesn't work as well as having one continuous route that goes through the whole map. So, continue your bot routes! Take it in any direction you like. But remember this: Keep your waypoints fairly close together. If the bot can't see the next waypoint, it will randomly run around looking for it. That is most definitely NOT what you want to have happen. I don't know what the upper limit is on waypoints. I have had more than 1400 in a map at once with no trouble but I DID crash the game by going silly and making half a million of them. So don't be too generous with them, either. Anyways, keep adding waypoints all around the map. If you get tired of typing the commands out all the time or using the up and down arrows to scroll through your most recent console commands, then you can bind them to keys on your keyboard like so: /bind f4 bot_wp_add /bind f6 bot_wp_rem By using this system, you can stand where you want to add a waypoint to your botroute file, and then push f4 to add it. If you want to remove the last waypoint you placed, press f6 to delete it. Pretty easy, huh? Please note that I DO NOT recommend doing what I did in the picture below! It is for ILLUSTRATION PURPOSES ONLY! Basically, what I did there is run in a circle and push the button I bound to bot_wp_add repeatedly. This made an incredibly USELESS system of waypoints that will send bots running in circles like people gone mentally mad. While it may be amusing to watch, it's not very fun to fight. But let's just say I wanted to keep this. If I want to save these useless bot routes, then I would open up the console again (Shift + ~) and then type the following command: /bot_wp_save If you have a lot of separate areas with the botroutes not connected to each other, your game will lock up for a few moments. DON'T PANIC! Eventually, it will tell you that it reconnected some points or that it can't connect them, as shown below: If the game crashes when you save your botroutes, don't worry; it happens sometimes. Now, let's retrieve your botroute file. If you have Jedi Academy/Outcast in windowed mode, minimize it, just in case they didn't save right. Then open up your Academy/Outcast game's 'gamedata/base' folder. Inside this folder you should see a new folder called 'botroutes'. Inside this folder should be your botroute file. It should have the same name as your map with a file extension of .wnt on it. Note: If you have Japlus, Lugormod, Makermod or anything else installed, your botroute file will be inside of a folder with your mod name inside of your gamedata folder. So if I had Japlus installed, it would be in my gamedata/japlus/botroutes folder. That's it. All you need to do now is grab that .wnt file and put it into your map's pk3, inside of a botroutes folder. Another note: If you have a mod installed and had to take the botroutes from that mod's folder, ignore it! Just put it inside of a 'botroutes' folder inside of the pk3. Tips for efficient botrouting: • If you want the bots to walk around more like a real client, use your mouse and walk around your map where you want the bots to go, pushing the button you bound to 'add waypoint' every couple of seconds. There are a few special things you can do with botroutes, too. My source on the following is: http://jediknight3.f...aypointTutorial /bot_wp_addflagged You can use this with arguments to give bots more interesting behaviors. A more exhaustive list is given from the source I used (link is above). Basically, you type /bot_wp_addflagged in your console, then put a space and add the letter abbreviation for whatever behavior(s) you want the bot to do at this waypoint. You can mix and match them any way you like. j - This makes a bot jump while it tries to get to the waypoint with this flag on it. d - This makes a bot crouch and walk to this waypoint. x - This forces a bot to move FORWARD in the waypoint index to find the next point. y - This forces a bot to move BACKWARD in the waypoint index to the previous waypoint. So if I wanted to add a waypoint that made a bot jump to reach it, I would type the following in my console: /bot_wp_addflagged j And if I wanted to force a bot to move forward in the waypoint index and crouch as it moved, I would enter this: /bot_wp_addflagged dx That's it! You should be able to start your map and play on it with bots that find their own way around! However, don't forget the MOST important part of making any mods - TEST YOUR WORK! Always, ALWAYS, test your work before releasing it on the internet. You don't want to make yourself look bad. :]
  25. NAB622

    BSP Menu

    This is what the BSP menu will look like when we're done: This will be quick and dirty, so let's just cut to the chase. When GTKRadiant runs a compile, it will start a separate program called "Q3map2.exe" and tell it what to do. Q3map2 is your standard Quake 3 compiler, and it suits its purpose well. When you compile a map, the compiler has to do three separate stages: The BSP stage, where it places all the brushes and entities (this is the only necessary stage) The visibility stage (VIS for short) The lightmap stage. If you have BSP monitoring turned on, GTKRadiant will watch the compile as it goes and notify you of any errors that are found. If it is turned off, then Radiant will just blindly tell the compiler to run. You should ALWAYS have BSP Monitoring on, UNLESS IT CAN'T FINISH COMPILES. Otherwise, you won't get notified of critical errors. Anyways, if you go to File > Project settings, you'll see this window. Right now, you don't really need to worry about anything but the bottom half of the window. (You know, the part that has the complicated things in it.) First off, and this is very important, MAKE SURE YOU ARE SET FOR MULTIPLAYER MAPPING MODE, not single player mapping mode. You're going to delete all the compiles that are displayed, BUT, you first need to get something! Open up one of the compiles that are displayed in the window already. You should see something that looks like this: This is the first thing you need to know: Copy and paste that filepath into the "q3map2 folder's filepath" text box below. Q3map2 folder's filepath (including the .exe's name): (feature only availble at this link) Next, open up Notepad. You need to find a second filepath in the same command. This will be the path to your GameData folder. Here it is: Copy and paste that into the text box below: Gamedata folder filepath: (feature only availble at this link) YOUR FILEPATHS WILL BE DIFFERENT THAN MINE. Don't use the ones in the images above, because I can just about guarantee you that you're not using them. Also note that you are NOT linking to a .exe file in the second path - you're just giving the compiler a filepath to use. You do need the name of the .exe file in the first one. Once you have both put both filepaths into the text boxes above, click the create button to create your compile codes. For those who are curious, no, I can't use your filepaths to hack you. That information is completely irrelevant to getting inside your compupter. Kind of a stupid question, but I've been asked similar things before... Once you have created your compile codes, select the compile options in Radiant's Project Settings window one at a time, and click the remove button to delete them, shown below: (Note: If you ever want to map for single player mode, You need to leave the single player compiles! They all have "(single)" at the beginning of their name. All other compiles can go, but if you really want to, you can keep them.) Now, click the "Add..." button. A new window will pop up, which looks like this: Once you have given your filepaths up above and hit the "create" button, all the compiles will be listed below. The names are listed in green, and the actual compile commands will be listed in the text boxes underneath them. In case it's not obvious, you will be putting all 9 compiles into the "Add Command" window, one-by-one, putting the compile name in the "menu text" field and the text that was generated will go into the "command" field, like so: Your turn. This doesn't take long, really. :] Congratulations, you made it! You can mix and match the order of these compiles any way you like. However, you have one last thing to do. Restart Radiant to get the list to appear in the proper order. You are done! Give yourself a knuckle sandwich on the back, you deserve it. : > To use these compiles, you can either choose one of the "final" options, which will automatically do whatever it says after that in the name, or you can pick and choose what you want to do. If you want to do a lightmap or a vis compile, you MUST do a bsp stage first. If you update your .map file, you will have to redo your bsp compile. Fast VIS is a fast type of VIS compile, full VIS can take hours (even days!) to complete but gives much better results (if you did your structural brushes well). The lightmap stage is just a normal lightmap stage, but the lightmap low memory stage is for computers with very little RAM available. It will take longer, but it will get the job done.
×
×
  • Create New...