Fidcal

I've been creating model doors by two methods with no problem that I noticed: Create brush, give it atdm:mover_door, select model in entity inspector and click button 'Choose Model' Or... Create model, edit the name func_static to atdm:mover_door But now I find with the first method I see the origin point appears in DR to be way out - maybe 25 units to one side and some 1500 units high. Yet both doors work fine in the game. There is no other entity listed in the entity list. I've rebooted XP and started with a fresh map but still the same. This is the top view HERE as the side view the origin is too high to get in the same image. I can't understand when this started as it could not have always been like this - I've made a hell of a lot of test doors and done a lot of rotating testing where I've paid attention to the centre of rotation.

What s & r is working in the mod so far that I can test? Firstly I've tested the damage stim by applying a stim to an object with various parameters then approaching it, contacting it and the player reacts sensibly to the settings so that's fine. Next I thought I'd stick with damage as I know it works but test applying a response from another object. I made a house model added houseStim, radius 300, mag 10, duration 1000. Next I made a crate > 300 units away and added a houseStim response : Damage > Info_Player_Start > entityDef damage_fire In game I carried and dropped the crate next the house but can't get any response. What more is needed? Or have I misunderstood how it works? Or both! [EDIT] I saw my error the moment I posted this. Forget 'duration' - I changed that to 'interval' - what was I thinking! But it still doesn't work so... ?

Just sent off for a couple of gigs of RAM as I'm getting lockups with DR plus Doom plus a few other programs running all at the same time with 500Mb RAM. I've noticed big missions take quite a while to load. Presumably most of this is processing time as the data is read in. In memory is this data in such a form that DR could have its own save format which would be the processed data? This would use more disk space but load and save faster. The mapper need only save as a map file to test. Just a thought. Not sure if there is any real value in that. Probably depends how often mappers open and save without actually testing.

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?

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?

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.

This is the original block... BLOCK After rotating... WEDGE

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