Boothand

This would be the best illustration I can give for now: http://onlinesequencer.net/ Throw some notes in there, and then click on the play button in the lower left. I don't think I will need relays nor delays. I've thought of it a bit, and will keep it in mind though. Currently I'm setting it up like this - one script being used when you shoot and set up your sequence, and another script for playing the sequence when it's done: The first script checks this: If entity gets shot/used AND parm1 = 0 set parm1 to 1 play sound (get parm11) (so in this entity, I would set parm11 to the path of the whole-note wave file) If entity gets shot AND parm1 = 1 set parm1 to 2 play sound (get parm12) etc until If entity gets shot AND parm1 = 4 set parm1 to 0 [play no sound] This should correspond with the "endframe" key I've set up which changes the texture every time you shoot it. The next script will play it when you press a trigger, and does this: Affect ROW1 (all the blocks in the first vertical row would have the same script_targetname and thus be executed together. I've had an experience where the game picks only one of the entities regardless of identical targetnames though.) MoonDog, help! If parm1 = 0 do nothing (how do I tell it to do nothing actually? Flush...?) If parm1 = 1 play sound (get parm11) If parm1 = 2 play sound (get parm12) etc with 3 and 4 as well... then wait (get amount of time to wait from some other entity in the map that the player can affect, so that they can change the tempo of songs) Challenge (?): Then I would have to let the script run on every entity without *using* them, because using them has the same effect as when you shoot them and set up the sequencer in the first script. @@MoonDog, could you confirm if I'm onto it here, or if there's something, for example the last part I mentioned, which renders this totally undoable?

Update on progress: I've managed to switch texture on the blocks every time they are shot. Done by using the "endframe" key. So this way I don't need to deal with hidden entities.

Yeah, sorry for being a bit vague there. The word value corresponds to a mathematical value, representing the length or duration of a note. Whole notes (the greatest value) last for 4 "beats" or "counts". Then half, quarter notes, eight-notes are just halves of the durations before. 1, 0,5, 0.25, 0,125 could be a way to represent it in for example seconds. Hope that clears up the word "value" in this context. So if you imagine that a script starts on the first row of vertical blocks, the entire chunk from the bottom-most left block to the upper-most left block, (1 of 16 horizontal rows) and plays the sound corresponding to the value those notes are set to (via parms and a script, I suppose). Maybe 3 blocks in that first row would be set to a note value, and the rest would just be blank and play no sound. Say the notes G, B and D were set to quarter notes. The script would then play those at the same time, then after a wait time, it would move on to the second row of vertical blocks and do the same thing for whatever there might be. So the reason for changing the note values is really just to make the tones last longer or shorter. It won't change the time before the script plays the next row of blocks. Granted, most apps/mods etc don't take into account how long the notes should last. For example Minecraft note blocks, or playable piano-mods in games like... Garry's Mod. The end result of this would be that the players shoot blocks to make tunes, then execute the sequence by pressing a button where it then plays it from left to right, and possibly as a bonus can choose whether it should loop or not.

Parms can be set on anything. But part of the issue is that every time the note value changes, so does the entity. Maybe it's possible I could discard the idea of having a new entity for each note block, and rather have only the texture be swapped and parms set up to play new wav files. It would simplify things...

That would the progression in the song, or sequence or what to call that. It would basically work like any music program where you input MIDI. You have a grid, and the pitch is determined vertically, the notelength and timing is determined horizontally. DAW example: http://www.jamorigin.com/jo/images/daw-setup/midi-out-fl-studio.png For now, it would be a very short sequence but I suspect that might be the best case scenario. So if this was one note: http://www.twitch.tv/boothand/b/503588956 consisting of 8 possible repetitions, and 6 (+1) possible lengths, blocks over and under it would be other pitches. For now there's just one row.

How about triggers that trigger multiple entities with different targetnames? I can't make them have the same targetname, otherwise the note value function wouldn't work.

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.