 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Having bbox, represented by lines, is one of wished features, it helps, while placing, for sure; though, i'v been told, that entities with models appear ingame exactly, as seen in editor.
There is visual representation of entity origin atm; it is possible to use it for placing, but need to offset halve bbox size in mind -) md3 models are included (and more things); try q1pack dir, q1pack.txt Filterbar: it is reconfigured in supplied q1.game, would like to know, if fine or not. The q1pack included is basically for ease of use. The filterbar enables filtering (m1 click) and texturing (m2 click) for clip, skip etc.
Also added a scripts folder to go in id1 which allows transparent textures/filtering in editor. You can add any texture to the shader for trans - useful for *water n stuff. As for models, they show in game exactly as placed in editor; bar the ammo boxes which are all 32x32 big box over the 24x24 small box. The box="" sizes I didn't touch =p Would be cool to see a bounding box along with the models for sure, https://goo.gl/UyXRUJ
* extradebug_quicker BUILD mode (defines _DEBUG_QUICKER = no slowing down debug renderables) * draw bbox for having model + selected entities * disabled depth write for qer_trans surfs and highlight (=any amount of layers is visible) * 20x faster light radii rendering * light radii are coloured and additive * improved q1 pack (common textures, fix entities sizes) * anisotropic textures filtering option (def = yes) * GL_TRIANGLE_STRIP light radii spheres (2.5x faster) * new very fast entity names rendering system * render entity names in cam within < 768u dist or if selected * fix: noninitialized lightradii, if light value is not set (example: lightjunior) * light power is adjustable by mouse drag * oranje names for group entities, having childrens selected (also no distance cull in cam for those) * QuakeLive game pack Would it be possible to have two independent "Show" options for the entity names in order to enable/disable their display for each window (one for 2D and one for Camera)? Or maybe a way to customize the rendering distance (either in menu or in
Im in doubts about entity names options, too much ones are possible -)
Atm thinking about two ones: 'show for unselected' and 'show for selected' This + may be display dist feels not too much to confuse user What is your problem, something like 'cam, spammed by names'? Btw, there was alternative suggestion: command to toggle *hide world + show entity names* I have question about your crash on switch to diff app, while in freelook: does it always stay in freelook after switching out and back? (i e when no crash too?) It's just a little strange seeing all the names through the walls even if the actual entities are blocked by world geometry. If there was an entry in local.pref where one could set the distance at which names are rendered, I would certainly lower it.
Crash: I haven't encountered it again, yet (although haven't done much mapping, either). I tried a few things just now and, at least now, it didn't seem to stay in freelook. In most cases, the camera window was still moved behind the other two windows even when it was on top before switching apps. Tried switching apps with alt+tab, win+tab and win key. Though still not sure what exactly triggered the crash in the first place. Made two things about names:
* preferences->display->entities->Names Display Distance (in cam) def = 768u * always show selected/childSelected entity names (unselected is optional) About cam window, is funny, but going behind is normal gtk behavior I made helloworld test app and it does the same (and big gtk apps do) Basically it displays active window 1st, then the rest of windows, so active appears behind xD Prolly can grind out some hack around that to present last active wnd, but the rest of wnds gonna be still tossed mhm, just noticed, that 'activate main wnd, (focus out,in)*2' restores wnds order correctly About modal windows, going behind: it is possible to set them 'always on top' (this works systemwide) Sup with nonmodal tools windows then though (want them to be on top of canvas, right?) Just to say you are doing God's work here - I love the feel of NetRadiant, and it's just getting better with your improvements :)
A little thing I wondered if you could consider: Would it be possible to have options in the editor to set the paths to qbsp, vis and light? Currently this has to be done by editing an xml file tucked away in an obscure folder somewhere...I think? Atm there is no conception like 'path-to-Nth-build-tool', instead generic variables are used.
So may be ability to edit generic variables? Or may be built in 'BuildToolsPath' variable, defaulted to RadiantPath and with ability to select path via dialog. But using that in build menu would break backwards compatibility. Still is not clear why these extra preferences are needed, atm it's as simple as 'drop compiler binaries to radiant folder, use' and even portable. About floating windows layout: after fairly massive research i see two ways to fix that: One is to make canvas wnds children of main wnd (i e built in = delimited by main wnd borders); examples: doom3edit, jack This would be quite straight way to fix wnds order problem Second is: dynamically set tools wnds transient to canvas ones in focus in event of 2nd ones; it seems, that gimp does that for detached canvas wnds This is more tricky and risky option + there are plugins windows out of simple reachability Tossing wnds would still occur on app focus out, in... that is how gtk transient function works; if i grab Windows Manager window and set transient via Windows function, it works just fine (no tossing); though that is really hacky (and Windows only) Ability to edit generic variables sounds useful but obviously not worth doing if it's gonna break backwards compatibility.
It just took me a fair bit of fiddling around before I realised how to change the paths, but probably more my dumbness than anything. Rather than dropping the build tools in the radiant folder, I prefer to keep them in a centralised place so multiple editors can reference them, and when the build tools need updating I only need to update them in that one place. I don't quite understand the window fixes, but from the sound of it, the first one seems better. Although, like I said, I haven't encountered the crash so far. Maybe it's already fixed? Only things about the windows I noticed (that are different compared to Gtkradiant 1.5) is that some windows sometimes require me to click on their title bar to focus instead of just anywhere inside them. And I occasionally close the entity window by accident, and upon toggling it again, it's centered instead of the position it was before. But this is a not really an issue.
Feature request (unless already present in some form): it would be nice if one could use the mousewheel to zoom in and out onto an object in orbit mode (freelook+tab), because with the default distance, the object in the center can easily be obscured by other stuff. Not to be bothering about the entity model + bounding box display again... but would it be possible to include an option (e.g. checkbox in preferences) to enable the rendering of the bbox around the models all the time instead of only when they are selected? By the way, is it just for me or do the buttons read "Cance" instead of "Cancel" for everyone else, too? -window fixes: it's not about crash, but occluding some wnds like scale dialog or csg tool by canvas wnds (in floating wnds layout)
-some windows sometimes require to click on their title bar: only time, when this happens, i'm aware of, is trying to bring on top already focused wnd (after app focus out, in: this doesnt happen in 1.5, since no wnds tossing in old GTK version, used there); Calling present() function on all clicks/scrolls isn't healthy (adds lag), so is called only on focus change -entity window is centered instead of the position it was before: what are steps to reproduce? after some change in GTK there actually was problem with correct wnds positions restoring, but entity wnd has workaround already (floating canvas wnds still need that) -orbit mode: it's ''fit selection bbox to camera view'' function actually; not sure what to do, since no things like distance there (though i agree, usability of current function is limited) -bbox around the models: will add, can imagine its usability (but spoiling the view on the other hand) -"Cance": Is it true for any dialog? "Cancel" here usually, may be button size < text with your settings? -player.mdl: it's the way, I thought the entity window thing was sometimes triggered by closing it with ESC when actually intending to deselect an entity, but I can't seem to reproduce it now...
"Cance" was indeed caused by the custom text size setting in Windows. I had it at 125%, because otherwise the text would be a little too small for comfortable use. Something about the transition to Windows 10 that caused this hiccough. I've now set it to default and then back to 125% and it say "cancel" like it should. However, now certain other things look a bit weird, e.g. the menu bar buttons are slightly larger and the lines in the 2D window are fairly thick and black. Some weirdness in other programs, too. FFS, Windows! Player.mdl display works, too. I did add it in the It loads all found
So it's easy to drop in mod entities. To make backup change/add some other file extesion So I keep fiddling around with this script for hours, wondering why it wouldn't work, just to discover Custom Radiant simply refuses save entities that don't match the
It appears to only affect point entities without models that have a negative angle set, and only changes the value when moving them. So for instance, angle -2 (=down in Quake) becomes -2.000006. Obviously, this must not happen, because it makes the affected entities stop working correctly.
It's always done odd things like that, though I've never noticed with the up/down angles. I set an angle to 270 and it saves it a -90. I set an angle to 180 and it saves it as 179.99995 or something.
Hi can someone give me a quick rundown on how to make entity models show up in the editor (e.g. monsters)
I'm using the { model(":progs/mon_hknight.mdl"); } After the hellknight definition. Also, I have set the custom mod correctly to AD through the project settings. save everything I do regardless of how erroneous it may seem!
I thought, this was discussed, but again: some games (for example q3) don't load maps with empty group entities. The most classic rad 1.5/net user's forum post is "Hello, i be building my map for a month, and now suddenly can't run it in game, halp :@" The most classic solution is "open map in radiant 1.4, which removes such entities, and resave" or "rebuild from scratch/last backup" Ridiculous, eh? Yes, 1.5 discards brushes, contained in entities, defined, as point (with red warning in console) Yes, there are ways to get empty group entites during normal map editing process; catching every possible way is like fighting the wind, also solution is always unique. I added discarding empty group entities on map saving (with red warning in console); this fixes one of the biggest flaw in 1.5 branch This is most important for non-advanced users; ofc advanced ones are aware of such behavior (literally every user hit one at some point) and can remove problem entities in 3 keypresses. I, being advanced user, like you, would rather setup small suggested batch and keep creating with full comfort; or just use entities with brushes for tests and remove brushes for release version. Only real solution is actual support of different entities with equal names; will look into that, though i expect too heavy research there. angle -2 (=down in Quake) becomes -2.000006. Obviously, this must not happen For the sake of interest, what point entities use -1 -2 angles for hardcoded directions? In radiant brush entities angle is a string, and point entities one is actual number, transformable by editor. Point entities also have 'angles' vector3 key for arbitrary 3d directions, thus there are no problems, except aestetics, for games, designed that way. Transforms are performed in unified way like SceneGraph.forEachInstance( getTransformNode().transform() ), i e single function for all transforms, so you have angle transformed and committed, even if you just translate object; One idea is to try to catch that case to omit commiting. Meth around rotating is quite interesting: rotation angles->radians->quaternion->matrix current state angles->radians->quaternion->matrix matrix*matrix get_rotation_euler_xyz_degrees(result)->angles Once computers computing precision is not limitless, even zero rotation can commit values. Second idea is to use the way, entities with model use for rotation, when possible (with predefined quaternions); so -2.000000 would stay -2.000000, 180.000000 180.000000 etc I set an angle to 270 and it saves it a -90 arctangent returns values in range ( -180, 180 ) :) { model(":progs/mon_hknight.mdl"); } This looks, like autoconverted from fgd w/o correct model key handling Correct syntax in def is: model="progs/mon_hknight.mdl" find/replace :) Shrinker here,
I disagree with your defense about the limited precision in computing. It should not be used to defend deteriorating numbers, but rather be taken into account to make sure that doesn't happen in the first place whenever possible. Numerical stability is very important because this is about user input, and the little errors can add up over time and cause frustration. Also, what is often not considered is that the conversion of floating-point byte patterns to strings and vice-versa can also lead to a loss of stability already because of only limited digits being shown depending on the format configuration. Your effort to have the editor "understand" all geometric keys is very commendable and allows you to do neat things an editor without that understanding can't do, like manipulating rotation values, velocity vectors and the like accordingly or making sure all of this also works when shearing or scaling the selection too. Putting it all through a unified computation pipeline is also nice in order to make sure you can deliver a high processing quality in everything. But: When doing translations, and you can certainly discern those based on where your transformation comes from, and carry that through with a flag, rotational values shouldn't be touched. When doing 90 degree rotations, which again could be carried through with a flag (the original Radiant's Tab key caused this transformation), the transformation matrix should be tuned to have perfect 0s and 1s in it* so that in the end, for coordinates and directional vectors, you have perfectly swapped coordinates instead of slightly deteriorating coordinates. (*): something along the lines of that is also found in C++ optimizer settings for a reason - special treatment for 0s and 1s in computation to be more in line with the user's expectations and to ensure numerical stability better Normalizing your angles between (-180, 180] is a design decision, and that's okay - you could also have decided to make them always negative or always positive depending on taste or what your users are familiar with. -- but as just mentioned, that should only apply when you actually have to manipulate the angles. Keep up the good work! Hey, Shrinker.
I'm not the author of all those cool transformation codes, but SPoG - primary 1.5 radiant branch developer (and 3ds max fan, i believe); I'm just telling, why that half transparent black box works, like it does, and name visible solutions (ones you named in general). Though all these workarounds don't look as neat and straight, as original code does; perhaps other way could be converting all computations to doubles; also things to mention, current way produces no problems for games like q3 or doom3, you simply edit visually and don't care about not super accurate values. One thing, code is not fully mathematically correct there: works ok only when rotating on axis, entity is rotated initially (or initial rotation = 0). Perhaps you have idea why that could happen in described meth, one looks legit for me :) For the sake of interest, what point entities use -1 -2 angles for hardcoded directions?
Shooter traps, for example. Like with group entities, the game code automatically translates the values into angles the engine can work with. I don't know about the code and how it has changed over time/versions, but this did not occur with Radiant 1.5, and I'd be very surprised if it did with the old Netradiant. "-2.000000" seems to do the job as a workaround.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |