Fidcal
-
Posts
16801 -
Joined
-
Last visited
-
Days Won
21
Posts posted by Fidcal
-
-
Why is the drag/resize button labelled QE? Searched the net and can only find Quake Edit but can't see why the button would be called that. I need to refer to it in a tutorial.
-
This is really picky but in the 'Edit Response Effect' dialog, the drop down list is set to just fit down to the bottom of the screen. I keep dragging it up thinking it has gone off the bottom of the screen and I'm missing a few lines. If it were just 10 or 15 pixels shorter it would feel better.
-
Or (18)Timer ?
-
I agree everything!
-
Confirmed. No crash on exit in two or three tests and the stim names are fine.
The s & r is basically there now and looking very good. I'll do some more testing when I get the next beta with s & r working as real testing in-game will highlight any glitches. But the interface looks pretty complete. (still think new names should just be typed in then Add or Enter to add but I won't quibble!
) -
Dark Radiant v.0.8.2 of 20 Apr 07 18:31:09
Done some more checking on this missing custom stim name thing in the new version and it is saving the names but not displaying when first looking in s & r...
I create a new entity; add testStim (1000); save the map; close DR; Open DR with map; the entity's s & r shows in the stim list...
# s/r Type
1 S
... that is, the name testStim is not there in the entity's stim list. If I click it to highlight it then testStim appears in the type change selector in the right hand editing section but still not in the entity's stim list. If I click Add to add another stim it adds frob to the list at #2 and then the testStim name also appears at #1 position. So that just looks like a display bug only and the name is being saved but not displayed when first shown.
Now there's another oddity - every new brush I create has all custom stims added to it automatically! That is, its properties in the entity inspector window show...
classname worldspawn
origin -
editor_dr_stim_1000 testStim
-
greebo: Should I install this over my DarkRadiant_latest_SVN_GTK_210 install and delete my other install?
-
What I did was to click the link in the contents then copy the url from the address bar. I then pasted that into my post but when I previewed it the link went to the top of the tutorial. No matter, so long as it is do-able I'll know in the future.
-
jdude : The black box may well be the visportals. Read my updated tutorial on the wiki HERE but especially the section "Windows, Doors with windows, bars, etc." and the section just before it... "Doors standing in front of but not within a doorway". Even if that's not your problem it's worth knowing.
greebo : How come I couldn't link direct to those sections? The link just reverted to the main page.
-
Where is that box Bob? You mean a box you can enter any angle? Can't seem to find it.
So do mappers generally never snap to grid any brush that they have rotated?
-
Snapping an off-grid object to the grid is equal to changing it
That is why I was suggesting an additional non-grid snap - a snap to the nearest 90 degrees. But I see now that this would only work with rectangular blocks anyway if brushes are defined by their faces and not their shapes. So one face of a wedge might snap to 90 - but so would the opposite one! I give in on this.
-
I was having trouble loading a big map earlier and I thought it was because I only have 512Mb of RAM and had a few other programs running at the time including Doom 3! When Windows runs out of real physical memory it starts using a large disk file as virtual memory but this is really slow compared to RAM. Later I loaded the same map more quickly when I did not have other programs running. I'm thinking of getting more RAM. Could that be the same problem for you jdude?
The only other thing I can think of is build it in three or four parts as different maps and merge it later using prefabs but I don't know how robust or comprehensive those are.
-
greebo: This is really a follow on to a couple of posts in the itches thread that I started there in error about deleting custom stim names and you suggested a warning confirm before deletion...
Yes I was thinking myself it would not be practical to keep track of every entity that ever used the stim. So probably the warning confirm delete is the best option.
Other thoughts:
Make new names undeletable. The user can still edit that name to something else but cannot delete it. No harm done. It's no different to any other stim. They cannot be deleted even if not used.
A hybrid of the above. Once a stim is added to an entity a variable is set unique to each new stim name. If set, it protects the name and the name cannot be removed from the list. It is irreversible so no check is made of how many entities are using it. So even if it is removed from them all then the name is still protected. This does at least mean that new names that are not used, or even created in error and not used, can be removed. An attempted deletion of a protected name could be met with a message "name might be in use" or even "name might be in use, please confirm y/n" Actually that would sit well with your idea but is hardly worth it.
Another variation: The above protection variable is incremented every time the stim is applied to any entity and decremented every time it is removed from any entity. Only if it is zero can the stim name be removed. Mmm... what if the entity is deleted? Or cloned? Do clones retain stims? - Yes! so dump that idea.
On balance I think your idea is probably best!
Other oddities and problems:
New stim names are, or should be, exclusive to the map in which they are created. Otherwise every new name a user creates would be stored and still be there every time DR is opened (like the default inherited ones) and as new maps are created and new stim names, the list would grow longer and longer. Can't delete anything as they are used in another map. So clearly new names are exclusive to each map. BUT...
First, new stim names are not being saved at all! The numeric id is saved but no name.
Second, any new stim names in memory are not removed when a new map is created or another map is loaded. Worse - if a new stim name with the same ID number as the one just closed is in the map loaded then it gets the different name. Well, this is just one bug really.
Multiple new stim names with the same name can be created. Not a major problem; the number itself is the unique identifier. I created one called Fire.
When the user goes to create a new stim name it might be natural (I've done this a few times already!) to go to the Name input box, type a new name, then click the add stim type button. Result: a new stim name is created with the default name of CustomStimType and that also replaces the name that the user has just carefully typed into the box.
Since multiple copies of the same name can happen anyway (they can even all be called CustomStimType) then why not take the name from whatever is in the box or, only if it is empty, give it the default name CustomStimType? A new name might be entered by just typing it in and pressing the Enter key. This would then be a basic input such as when you type a file name in a save dialog and hit either the Enter key or click the OK button. The user types in a new stim name then either hits Enter OR hits the Add button. It is failsafe because if the user has typed in a name then he/she must surely expect it to be the new name. I think the input box should be cleared after every input.
I created a very long name. The selector list handled it well by making itself wider. Is there a maximum length? Is there not a case for capping it at a reasonable length? Perhaps 15 or 20 chars is enough for anyone? I hate restrictions but there has to be some limit and I've never created a name in Dromed longer than about 10 or 12 chars that I recall. In fact the longest I made was botLightStim which is 12 chars and the longest in the whole list of Dedex is SilenceEndStimX which is 15. So 15 or 20 or to be ample.
-
As I understand it, snap to grid resizes a brush to the nearest current grid size and moves it to the nearest grid line? In Dromed it also rotates the brush to the nearest angle divisible by 22.5. Maybe there is a case for a second 'snap to nearest angle divisible by 90 without moving or resizing' button that could be used at the mapper's discretion, eg, after a rotation. I don't know all the repercussions of this so I won't push it but it seems to me that one should be able to snap a rotation to at least 90 without it losing its shape. It is not the user's intention to change the shape so it is a fault. In Dromed the brush properties, coordinates, orientation, and dimensions are listed just like any object and the user could type in any acceptable value in any of them. That is another reason I was suggesting that brush properties be displayed in the entity inspector.
-
-
What do you mean by opt-out for the engine path?
Maybe it was something else and not the engine path but I can't see it any more to check because I opted out! What happened when I first installed that last download a small dialog or two popped up at the start and as I recall one of them had a couple of boxes to fill or change. It was there again the next time I opened DR. There was a 'don't show this again' check box so I checked it. When Dave said he kept being asked for the doom3 path I thought that was it.
-
Thought I'd try that rotate tool a bit more and think now I'm getting the hang of it. Very clever how it lets you rotate in three directions. Then I tried to rotate the brush back to how it started to test how precisely I could control it. When it was as near as I could get it I hit ctrl G to snap it to grid. Then I noticed - my brush which started out as a regular block had become a wedge! How is that possible? I did not touch the clipper tool; I just rotated the brush around. I saved it with a new name and reloaded the original map and the regular brush is still there.
-
Wow! You have got the stim selector adding in one! The dream selector! Yes! Don't think you need that Add button now. Maybe change the word type to Add: or Add type:
The crash after clicking Apply with empty fields in the effect dialog seems to be cured too so that's more good news.
The effect combo box now also is cured and can be left clicked on normally to select. This wants to be a few characters wider on mine though as it truncates... correction! I can stretch the dialog a little and the combo widens too so no problem.
I don't know what the repercussions are but I created a new stim called testStim and added it to a couple of entities. Later I accidentally hit the remove button. It still remains presumably fully operational as stim #1000 but blank name in the s & r. Don't see how you can protect names from this. If I create a new name NewTestStim then it is allocated 1000 and becomes the name of the one already used.
In Dark Radiant I used to be able to double click the camera window title bar and the entity selector to go full screen and found this useful as I keep them quite small normally and have a max orthoview I can. Has this option been removed intentionally? I can still drag resize but I got in the habit of the double click.
Sneaksie - I have the rotation button OK (though like you I have not yet understood it's three dimensional control. I found it easier to open a second ortho view then rotate in the top view while looking at the side view - but in reverse!
[EDIT]Actually just tried it again and think I begin to see how it works. It is especially clear with an object like a chair. Need to experiment some more though.
Isn't there an 'opt out' checkbox on that doom3 path thing at start?
-
OK, got it loaded so it was just that one file. Just had time for a quick look and I don't think I've got the dark mod resources so I need to look at that. I can't even select it. The close down error I mentioned before I got everytime has gone so that's one less thing to worry about. I have to go eat now I'll check back later...
-
I get unable to load upgradepaths.xml. This download is 9481KB but the previous GTK download I got was 15473KB so maybe more files missing?
-
Yes, that two column selector is much neater. Ah so it can be wider than the button so that solves that. I suppose the stim name limits the minimum button width. So what of the delete button? Leave that to the right click menu? You know, I think you've hit it. Without the delete button the add and the selector are bonded together as it were so there is no doubt they work together. Well, I don't know if you intended it but I'd leave out the delete button.
I had a glitch I thought was a feature before that has partly gone with this new version. If I clicked on the selector box I had to keep holding the mouse button down until I moved to a selection then release to select. I thought that was how it was meant to be. Now both these selectors work fine and I can left click select. But the Effect selector in the Edit Response Effect still has this glitch. If I left click it then release it closes. I have to keep holding it. BUT if I left click on the very last one or two pixels on the extreme right edge of the little downward arrow box on the right, in fact in the border just outside that arrow box, then it behaves like a 'normal' combo box and remains open even if I move the mouse away. I can then select and LEFT click a choice. Can you see anything different in the way you have set them up?
Downloaded the new effects and extracted them to the dark mod def folder. Still getting this memory reference error if I click Apply with empty effects fields. Maybe it will go away on its own in time! The last few lines of the Dark Radiant console window are...
...[shaders] materials/shaderDemo.mtr: Failed to parse "skin" (DefTokeniser: Assert ion failed: Required "{", found "heatHaze") This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.The last few lines of radiant.log are as follows. I selected File > New map to clear out my test map just in case then just created a vase to add a response to...
--- LoadMapFile --- g:/doom3/darkmod/maps/m/doorsTut.map 34 primitive 10 entities Open file g:/doom3/darkmod/ for read...failure Open file g:/doom3/darkmod/ for read...failure Open file g:/doom3/darkmod/ for read...failure Open file g:/doom3/darkmod/ for read...failure Open file g:/doom3/darkmod/ for read...failure Loaded Model: "models/darkmod/props/loot/vase_g.lwo" RenderablePicoSurface: using shader goblet1 [shaders] Unable to load shader texture: _white [shaders] Loaded texture: models/darkmod/props/textures/goblet1_d RenderablePicoSurface: using shader textures/common/collision [shaders] Loaded texture: textures/common/collision libs/modulesystem/singletonmodule.h:95 assertion failure: module still referenced at shutdown
-
Probably ignore this - it changes anyway depending on the last selection. What I meant was... well screenshot HEREI don't get the part with the gap - screenshot?
OK - looks MUCH better! Hope you can get that on the add selector too. I won't quibble the button widths etc. Better big than microscopic.It's a two-column list now.Tooltips? I'd noticed the question mark and thought you were going to add something later! Very useful. Mind you my mouse covers part! This is the Standard Windows (extra large) pointer I'm using if you want to try it. I'll try another. Now there's an alternative selector box, waits politely for selection; don't know if it can scroll a big list though. OK, I've changed my mouse to 'Windows Standard Large' which is a bit better. Even the standard mouse seems to obscure those tooltips somewhat but at least now I can move about sufficient to make out the tooltip.
Hang on - here's a bug... If you click the 'Apply' button in the 'Edit Response Effect' dialog when all fields are still empty then it crashes out DR with a bad memory reference. Wait... I got this even when I left an optional field. For example, I selected the effect 'Apply Stim' then _SELF in the target box then stim type 16. The tooltip for 'source' says 'optional, defaults to self' so I left it. Click Apply and bad memory reference closes down DR. I can give you more info but you should be able to duplicate it.
OK, on to your next post...
I see what you mean about the instant selection as unlike say, a normal menu selection, there is no confirming mouse click but just a release - well, the release is the confirm I guess. What about a combo box instead for the add selector?
BTW, by 'pointer' I didn't mean a C pointer but just a generic use of the word meaning a variable holding the value of the last used position in the array or whatever structure you're using to hold the list. Maybe you don't need one and it is sorted for you by a function that just links the selector to the end of the list.
Anyway if not, on to the positioning with separate buttons. I hadn't appreciated that the selector list can't be wider then the button! I was thinking a wide list could pop up from a narrow button like giant menus can drop down from tiny text. Maybe you can pinch space here and there. Slightly widen the overal minimum dialog size, slightly narrow the width of the editing section. Even then it might be a victim of large font dpi.
If not, leave it as one column. I think it better as one column with the add button the left than two column with the add button below. But both work, I just think the former is immediately obvious; the latter needs a head scratch the first time or two. BTW, is there a max stim name length? Target Reached seems to be about the biggest at the moment.
-
greebo - this in response to the previous post - I'll read your last one next...
Not sure what... Oh I see, a separate type button to select and then the add button adds that type. Does this mean the selector button itself cannot trigger a new entry but only change an existing one? Why can it not just be pointed at the blank next space? That could already be set up with default values so effectively is it not just changing the name from [blank] to something and moving a pointer up? But you're saying these things can't move a pointer up or anything else they are just linked to change an entry in a list and nothing more? Mmmm....
If so, I know this is a messy programming fix but if you use a timer to read the entry in the 'next position' and when it is no longer empty then trigger the changes needed, set default values, move the pointer up? You've probably already got timers set up and can piggy back this, eg, if stimlist[endpos+1] <> "" then etc...
Otherwise, if not and you go with this separate button then conceptually I would maybe remove the word 'type' and move the add button in there so it 'reads' along the row: [Add:] [(name)] so it might then kinda read as [Add:] [Frob] or [Add:] [sound] then maybe move the Remove stim button to the left under add or centre?
One solution is a mild bodge for the programmer but extra neat for the user; the other is a quick fix for the programmer but acceptable even for a nit-picking soandso like me!
-
Steady on! Here's a bit more on the previous one to chew on while I get the new one!
......If I drag the interface down to the bottom of the screen I see the type button then pops up the list above it and with its start pointing at frob, the first entry in the list but with a huge gap above to scroll up into if you see what I mean. Guess that's how the add would be. Maybe the add and remove buttons could go above the entity stims list on the same line as the type button. Also that very wide type button and selector list with a lengthy narrow list on it seems not the nicest display. What other options are there? If that width is retained then it would be nice to have columns: 6 x 5 is neater than a long list of 30. What kind of selectors are available? There is no obvious grouping of stim types so a 'start menu' type of sub-menuing system doesn't make much sense. I'd be inclined to make the button half the width. Come to think why are some of the stim inputs so wide? The time interval is like big enough to last till the universe collapses. I'm being picky now but you probably just set them all default to begin with till you sorted out what went where.
Spaces as separators - I've got a horrible deja vu feeling somebody already told me that the other day - probably you!
The 'wait' between effects is probably not worth pursuing then - it's excellent anyway that one can trigger multiple effects.
Itches, Glitches & Anything Else...
in DarkRadiant Feedback and Development
Posted
Thanks for restoring the maximize on camview etc. in v.9. I find it handy to double click it big and small.
Been meaning to mention but kept forgetting, the grid horizontal coordinate digits corrupt together and are too high on my setup. The side corruption may be my desktop dpi setting I can't tell. That is, it might simply be that every value is running over into the next one. Can they be spaced out more? The vertical thing is the top half is off the top of the window. A screenie HERE
Hold on, I see as I zoom in that they space out more so maybe it is sufficient if they are just lowered a half character height?
One more thing, can you confirm that the Dark Radiant grid units really are doom units?