 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Source
radiant.exe Summary Stopped working Date 10/15/2016 11:44 AM Status Report sent Description Faulting Application Path: D:\Netradiant-custom\radiant.exe Problem signature Problem Event Name: APPCRASH Application Name: radiant.exe Application Version: 0.0.0.0 Application Timestamp: 57d5aedb Fault Module Name: libgtk-win32-2.0-0.dll Fault Module Version: 2.24.29.0 Fault Module Timestamp: 5691a1e1 Exception Code: c0000005 Exception Offset: 001e50c2 OS Version: 10.0.14393.2.0.0.256.48 Locale ID: 1033 Additional Information 1: 2beb Additional Information 2: 2beba6fb4680d73a8c78ca7c24ccdb46 Additional Information 3: 34b8 Additional Information 4: 34b85e01dbe9529312a819250a584bb2 Extra information about the problem Bucket ID: 66f1dc540daf84cedf9a668c638cfbfd (108433453934) >>mouselook is still active for a brief moment before the error
Is not healthy, must autoquit freelook on unfocusing Idk what to start with... best errors are reproducible ones, so you can trigger them, while running in debugger, and see, what exactly happens Exception Code: c0000005 is very common case, access violation May be it's not random (can be actually) and is related to some circumstances? For instance, i'v recently spotted crash on releasing m2 in texbro w/o pressing one b4 Target/targetnames: it is option in 1.4/1.6: prefs-editing-fix target/targetname collisions; def = yes Is not optional in 1.5/net (always yes) It only fixes collisions Ingar's quote: I did not write GtkRadiant or NetRadiant. While I do commit patches, I mostly download the source code, build executables and add documentation and game packs. My goal is to provide a package that is easy to install for anyone who might need it. >>There's an error when using doubleclick on a texture in the texture window Is fixed in wip version >>When zooming in and out repeatedly with alt+mouse2, the focal point changes. That is bc 'zoom in to mouse pointer' option is on + zoom out does it from center, not pointer Might do zooming out from pointer too, though i see the only reason to do so (named by you); would be more consistent in general; On the other hand such kind of zooming out doesn't feel natural + it is hard to understand, how to get wanted specific effect, while using one (or it's just me-) >>Dragging the horizontal borders in the entities window, the ones between the entity list/description/keys, is wonky. They appear to be somewhat linked and can't be moved independent of one another in order to enlarge a section without affecting the other. Well, those aren't some abstract splits; Those are container widgets, splitting area in two So, wnd is split in two areas by central one + both resulting areas are split too It's made linked on purpose, so that all areas were scaling consistently along with containing window (for free) It is possible to make artificial handler for scaling + make splits unlinked, but that would require quite some investigation + might be risky For instance, 4 views layout was broken due to using such handler You can adjust splits just fine now, once start doing that from central one I like, how it behaves now btw, sorta rubber thing -) >>File menus (open, save, That appears to be general gtk architecture flaw; Basically it has setting to keep some wnd on top of the other wnd So all floating wnds are set to be on top of main wnd (and it works almost fine in non floating layouts :p) I havent been able to google any solution for this... would need something like 'set transient for group of wnds' setting (there is no one, afaik) Perhaps, can invent some dirty hacks to achieve this; though floating layout isn't the most developed one; luckily it works at least, h3h3 I'v tried really big gtk apps: gimp and inkscape; both have named issue (even though gtk stands for Gimp ToolKit-) >>it would be nice if the clipping could also be executed with mouse3 M3 would be quite out-of-structure and very specific one tbh (and breaking cam control) Ic that double click can be used there (since no action, when you click existing point) Atm you can use right ctrl and enter for efficiency :) >>I noticed that the outer grid coordinates in the 2D window are gone. View->show->coordinates Defaulted 'off', bc aren't too useful for most of games (paint sizing info does the job just fine) >>Would it be possible to allow the editor to accept multiple entity types with the same classname in the def file? That is quite a LOT of things to rewrite :X (not sure, if i can handle that even) In 1.5 branch you can obtain group entities w/o contained primitives No many ways to do that left in my branch (atm can do via removing whole brush with clipper and then can control via origin key) + there is recent fix to not to save such ones, bc it is a buggy behavior in general: q3, for instance, refuses to load bsps, containing group ents w/o submodel. What is this behavior needed for? (something like triggers, defined via min/max?) What editors support that? - We'll see if I can properly reproduce the error at some point. The only circumstance I'm currently aware of is switching haphazardly between applications.
- Yes, not Ingar; Divverent is the one I meant. I was under the impression it was disabled completely there, not just for cloning. At any rate, it's an improvement over 1.5. - Multiple types: in Quake (1) certain entities can exist as both point and group entities, for example triggers that have a big touchable volume or triggers that touch only at a single point. Sometimes it's preferable to have them point entities for scripted sequences or to optimize a map towards engine limits. Another example is map hacks where it's also possible to use info_notnull to create custom items/monsters (point) or brush-based things like trigger volumes/doors (group). Is it intentional behavior that in camera mouselook mode shift+mouse2 selects brushes or entities? I lost quite a few intricate selections by accident because of that... - an improvement over 1.5.
Indeed, just rechecked 1.5's behavior; was sure, that it had ability to preserve names. Is quite inconvenient to have no one -) - Multiple types: atm entity system in radiant is name based, i.e. specific classname must have unique name. Ic some thirdparty solution using different classnames for special entities then batch compilation like: sed -e 's/oldstuff/newstuff/g' inputFileName > outputFileName compile outputFileName - shift+mouse2 = tunnel objects selector in all modes Were you trying to quit freelook with shift+m2? :-) Just selecting multiple brushes, then trying to move the view in order to select some more, but too slow at releasing shift before pressing m2...
The more power you have, the more control you need -)
Though condition for shift+m2 click/drag selectors is releasing m2, while shift is down. (+exactly zero move for click and quite big one for drag) https://goo.gl/UyXRUJ
binds... * ctrl + shift + v: MoveToCamera (translate selection to camera origin) * m2 in entities creation menu: change classname; ctrl + m2: change classname, don't close menu * ctrl + m1 in entities creation menu: create entity, don't close menu (+offset every next entity by 8u or gridsize, if > 8) * m1x2 on clipper point = do clip menus... * Shortcuts item moved from Help to Edit * misc->colors->opengl font selector misc... * do not delete selected on entities creation, just deselect * ExpandSelectionToEntities: do not select invisible nodes * fix: snap translation amount on paste/move to camera commands instead of stuff's origin (to keep one with size (2*N + 1)*gridSize on grid) * MapName build system variable (can use to make build menu entry to run map in a game) * build->customize: list available build variables * texture browser: gtk search in directories and tags trees * fix: build menu->customize Cancel button cancels (was reloading menu from disk) * build menu->customize Reset button (= reload menu from disk = editor start state) * fix: laggy selectors, manipulators in mlook mode * scale free->snapped mode: constrain to two axes, most perpendicular to view direction (i.e. works for two axes in 3d too) * scale free->snapped mode: use min move delta for scale (was max = hard to scale down); fix ZY projection case * fix: pointfile was considered as shown, when trying to load missing one * entity inspector->EntityProperties treeview: Tab keypress = focus Key field * 2x2 layout: allow gtk to handle separators positions; fixes: unmaximize wnd, maximize = horizontal separators > center fixes: unmaximize wnd = not updated views glwidget positions on some systems * fix: paint selector, selecting occluded faces * camera->field of view option * wider Texture Gamma preference range * wad games->texbro treeview: do not group names, using underscore; fixes crash on loading parent; fixes mess if path contains underscore * fix: do not quit freelook on autosaving * entity creation menu has ability to be 'tearoff' * wad games: fix TextureBrowser_ShowDirectory crash on loading common dir (can cfg to load * wad games: fix crash on selecting a shader (not a plain texture) in tex bro * wad games: more reliable filterbar texturing defaults * shader for 'caulk new brushes' and 'clipper uses caulk' options is optional via 'shader_caulk' option in * fix: q1 mdl reader out of bounds reading crash * fix: q1 mdl loading of MDL_FRAME_GROUP case * fix: rightclick main wnd border, release in texbro glwidget == crash (unfreezepointer) * texbro: search in currently shown textures * ask for saving nonsaved map on project settings change * func_detail to nongame group ents counter * deiconify main wnd, unmaximize maximized view on app closing to save correct layout data * close preferences dialog on ESC * Enter = Ok in global and path settings dialogs * print renderer stats in XY views too * global 'show renderer stats' option, def = off * ~10x faster opengl text rendering * calculate farplane from g_MaxWorldCoord, g_MinWorldCoord (was const 32768) * 1.0f nearplane * numerous code fixes * texbro search: SearchFromStart option (match start of texture name) * texbro search: entry is activated/deactivated by mouse pointing * texbro search: clear button * renewed q1 gamepack ( by w_w ) Some questionable idea is to remember last action of clipper (clip or split) and use it while triggering action via m1x2 (can confuse...) Q1 default build menu is open for suggestions: want same simple structure (3 singles, rough test, final) want bounce for final, may be something else Question: are filterbar texturing bindings fine in q1 mode? (i'm not experienced in q1 common textures usage) The Q1 gamepack is somewhat problematic, though (and I accidentally overwrote my own :P). In my view, the way Radiant handles models is impractical for editing, because it displays either the model (if set in the entities def file) or the bounding box. Having only the model can make proper placement awkward. It would be better if the outline of the box was shown around the model as well. As it stands, I deleted all "model" paths again.
Additionally, in Q1 the ammo models are BSP files, so they don't show up in the editor at all. The md3 files referenced in the new gamepack are not included apparently, and furthermore the bounding boxes set in the def file are wrong (all Q1 items are 32*32*56 regardless of their physical size). This can cause items to fall out of the level if placed partially inside geometry by accident. Q1 build menu: I don't use that personally. If anything, it maybe should have "qbsp only", "quick compile" (qbsp, light, vis -fast) and "final compike" (qbsp, light -extra, vis -level 4) default options, but even these can vary depending on which compilers are used. For instance, current tools all support light -extra4 for smoother lightmaps, but older tools do not. Filterbar: They don't seem to do much at all. The only special textures used in Q1 are: "trigger", "clip" and "skip" (no variations like weapclip etc). Some new compilers also have rudimentary support for "hint". Liquids are determined by an asterik in texture name, e.g. *water. A few new source ports allow alpha textures, but I think the naming standards differ - like textures beginning with a }, I think. Someone else please clarify. There are no internal detail brushes or brush flags in general - the only way to achieve this in Q1 is to turn geometry into "func_detail" entities which newer compilers then convert back to structural brushes without generating vis portals for them. 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,
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |