Boothand

I realize this is a bit far out, but I really need some suggestions at this point. I'm trying to make a music sequencer. Basic set-up: Blocks (func_usables) stacked vertically to determine pitch (higher up = higher tones, etc).A row of blocks stacked horizontally for each pitch. Starting out with 12 (vertical) x 16 (horizontal) blocks visible at any time (= 192. Is that a problem? 12 tones vertically is very limited. 24 would be the next step)When you shoot them you change the note value (disappear and get replaced by the next block waiting to spawn).Each block has properties corresponding to the note value (6 note values + 1 blank possible for each note).A button that executes the sequence. Every block is played, then it will wait the same amount of time before moving on to the next block. Each block can have a note value or a blank value. I've spent many hours now trying to figure out the best way to script this. Everytime I think I have the best solution, I eventually realize it still requires repulsively many unique scripts (or any other equal unrealistic amount of work). Basically, the part where it has to determine which block is currently visible is boggling my mind. I can't think of any intelligent way to write such a script. Is there a way to check if an entity (like func_usable) is toggled on or off - visible or invisible? Well, even if there is, it would still be a scripting nightmare, I think. I have to potentially take 192 x 7 possibilities into account. 384 x 7 if I'll have my way. Unless I'm getting myself wrong here... Anyway! Over to the real question here: Instead, I would much much rather have something like a moving trigger that uses the entities it touches. Or something in that alley. Some kind of way to just run a set of entities that are visible. Is that possible? Is there any way around that?

Yeah, that doesn't work either. It works as long as the engine path points to JA. The "Game" can be set to JO and it will work. But again, not good for some entities I suppose.

I'm afraid you'd have to explain that again What do you mean?

Yeah, you can set it on the worldspawn as well (which is what I intend to do). Not sure what effect it has on large maps, but for now, it doesn't compile in JK2 mode in any case.

Yeah, I have decompiled it to see how it was done, and that's where I initially got the _celshader from. I feel I maybe shouldn't hand out .map files like that, but the celshaded entity in question has: _celshader cel/ink The worldspawn entity has: gridsize 272 272 320 _blocksize 8192 I've tried using those as well, as if it would somehow impact, but obviously they shouldn't really make a difference. The only thing I can imagine is that he used a different compiler (or certain -keywords to omit the issue) As far as I know, all versions of GtkRadiant (and JK2Radiant) uses the same q3map2 though? EDIT: Note: Compiling for JKA and running it in JK2 works with the celshader. However, there should be a more proper way to fix it, since entities are not the same, and I suppose I've got to use the JK2 compiling process for other entities.

This was tested by cel shading a single square block in an empty room. While grand flaw, which is a JK2 map, is massive.

It only has one healthpoint, so when you shoot it, it loses all its healthpoints. If you do -1 instead, it should be usable forever.

What health value did you give the door?

You could maybe go with a func_usable instead with the always_on spawnflag. Give it health "-1", usescript "folder/script" and a script_targetname. Func_static doesn't seem to work with health when I tested it.

Check out this and this! (JK2)

I've found a celshader. It works perfectly with JKA. When compiling for JK2, it gives the error MAX_MAP_DRAW_SURFS (131072) exceeded. I've tried commenting out some lines in the shader, but can't find what's wrong. The annoying part about it is that Grand Flaw uses this exact method and celshader, and copying the exact way it's done there (including things like blocksize and gridsize) still gives the error. A friend of mine has the same problem. Key: _celshader Value: celshadertest/ink Shader: // ink shader for maps // to use, add "cel" to shaderlist.txt // add a "_celshader" key to worldspawn entity with a value of "cel/ink" textures/celshadertest/ink { qer_editorimage textures/celshadertest/black.tga q3map_notjunc q3map_nonplanar q3map_bounce 0.0 q3map_shadeangle 120 q3map_texturesize 1 1 q3map_invert q3map_offset -2.0 surfaceparm nolightmap surfaceparm trans surfaceparm nonsolid surfaceparm nomarks sort 16 { map textures/celshadertest/black.tga rgbGen identity } } textures/celshadertest/no_ink { // qer_editorimage gfx/colors/black.tga // q3map_notjunc q3map_nonplanar // q3map_bounce 0.0 // q3map_shadeangle 120 // q3map_texturesize 1 1 // q3map_invert // q3map_offset -2.0 surfaceparm nodraw surfaceparm nolightmap surfaceparm nonsolid surfaceparm trans surfaceparm nomarks // sort 16 // { // map gfx/colors/black.tga // rgbGen identity // } } Any ideas?

My day was already great, and now it became so much better! Ideal situation. Oh, and I hope my profile picture doesn't cause any confusion. Nono!

Is there any official latest build for rend2, such as with OpenJK? (Didn't find any downloads of it!)

Thank you sir! *Goes off to obtain rend2*

Hooooly mantracker. I demand a wireframe shot of the cave geometry...? Never saw this thread before now. Now I don't need to look for stuff to watch while eating dinner anymore. Very inspiring work, with emphasis on very

I just thought of a feature that could be nice. Similarly to the "Best answer" function, there could be a way for the author to mark one of his posts as something like "most recent progress". Don't know how to name it. Then in the first post of the thread, you'd be able to see both the first post, and the most recent update to the WIP (the post that was marked). Mostly because these threads often end up several pages, and as a way to spark interest for people reading the first post of the topic.

Actually I was partially right/wrong. What was in 3DS Max was a different texture (made for building the pieces of the branches) but which turned out better visually. Using shader methods taken from SP, I turn out with some issues. Each individual branch looks good, but they don't blend correctly with their fellow branches and other shaders, like the water in the background. Didn't wanna start a new thread for this, but I can do it if you (or anyone reading) don't know what it could be. https://dl.dropboxusercontent.com/u/58757568/buggyBranches.jpg models/map_objects/bootland/trees/pinestem4 { cull disable surfaceparm noimpact surfaceparm nomarks surfaceparm nonsolid { map models/map_objects/bootland/trees/pinestem4.tga blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA } { map $lightmap rgbGen identity blendFunc GL_DST_COLOR GL_ZERO } }

@@Psyk0Sith, I think maybe a bit of the issue is that it's not translated well into the game engine. I started working on a new texture for the branches, but when I opened 3DS Max, I realized that what I already had actually wasn't so bad. Here is the exact same tree that I took screenshots if in-game, but in 3DS Max: I think the shader is trying to go all-or-nothing on visibility. I seem to remember I can't have a $lightmap stage if I want gradual transparency. What do you think about the tree as it looks in Max? And if it looks good, what approach would you take shaderwise?

You're right that it could probably be good enough for certain maps or certain standards. My real goal is to improve my skills though, and prepare myself for making content for games. I would really like to have the consistency to be able to re-do something I've made, expand my logical thinking, and generally just the process of taking feedback and trying to improve what you're making. That's an important skill to learn even if it might be starting to look nice. Hmm in what way do these shaders work weirdly? This works fine though, it's just a simple shader using the alpha channel for transparency. I'd have to do some more changes to the shader probably when this tree is lightmapped, because it will cast shadows on the other branches and might have some unnatural dark spots etc. I guess I'm quite fascinated with trying to re-create real world stuff in games But I guess I find gameplay mechanics even more interesting on that area though. Stylized graphics is often a much more well-working approach on engines like this.

I'd love to give some advice. Maybe I could even write a tutorial on the matter. Covering up the seams themselves is usually the easiest job. The real challenge is to make it look good from a distance while not destroying it up-close. So it has a lot to do with variation in brightness and color. I'll definitely write a tutorial if there's interest (and if so - what kind of texture could it be demonstrated with?).

Thanks for the links! I think I'll find them very handy, except I won't use a script for it. I still have too much to learn I followed this tutorial, if you skip through it a few places you'll see where I was coming from: I'll try to see if I can make a more true to life edition though!

Here's another one of my attempts at creating stuff from scratch, with 3DS Max and (barely) Photoshop. I still think the tree looks a bit confused, and it's been some months since I last worked on it, but it honestly looked a bit better than what I expected in the beginning. 426 triangles currently. Trees aren't lightmapped yet. Would like some feedback on what could be better.

Originally posted something else in this topic, but have edited to fit my new problem: Can I set a *speed* for the elevator, instead of a time to complete its task? Using the same amount of time to reach the top or bottom from anywhere in the lift ride, gets a bit inconsistent. //Generated by BehavEd rem ( "Player triggers lift from inside" ); if ( $get( FLOAT, "SET_PARM1")$, $=$, $0$ ) { set ( /*@SET_TYPES*/ "SET_PARM1", "1" ); task ( "moveup" ) { affect ( "towerlift", /*@AFFECT_TYPE*/ FLUSH ) { move ( $tag( "towerlift_t2", ORIGIN)$, < 0.000 0.000 0.000 >, 5000.000 ); affect ( "towerlift_trigger", /*@AFFECT_TYPE*/ FLUSH ) { move ( $tag( "towerlift_t2_trigger", ORIGIN)$, < 0.000 0.000 0.000 >, 5000.000 ); } } } do ( "moveup" ); } else ( ) { set ( /*@SET_TYPES*/ "SET_PARM1", "0" ); task ( "movedown" ) { affect ( "towerlift", /*@AFFECT_TYPE*/ FLUSH ) { move ( $tag( "towerlift_t1", ORIGIN)$, < 0.000 0.000 0.000 >, 5000.000 ); affect ( "towerlift_trigger", /*@AFFECT_TYPE*/ FLUSH ) { move ( $tag( "towerlift_t1_trigger", ORIGIN)$, < 0.000 0.000 0.000 >, 5000.000 ); } } } do ( "movedown" ); }

There is something called q3map_surfaceModel in shadering, which draws models onto a surface after this recipe: q3map_surfaceModel modelpath density odds minscale maxscale minangle maxangle oriented. I tried to involve LODs with these md3 models: q3map_surfaceModel models/map_objects/bootland/trees/grasschunk1.md3 64 0.6 0.5 0.7 0 270 1q3map_surfaceModel models/map_objects/bootland/trees/sapling2.md3 1500 0.12 0.8 1.2 0 270 0 Xycaleth says that it needs to be a misc_model_static, otherwise it's baked in. Any idea if these surfacemodels get baked into the bsp, and if so a way around it? I would really like to use LODs with them, but it didn't work when I tried earlier like this (*_1. *_2 etc). I was told md3s don't support LOD.

I seem to recall a staff member, I think @@Circa, simply added the "Mark solved" feature to one of the sub-forums on my request once. Shouldn't it be in any forum?