Fidcal

Haha - Just waiting for the go ahead - but it's got better since I wrote that.

I don't think this should work anyway but trying to parent a brush directly with a model door entity gives the error: "The instruction at nnn referenced memory at nnn. The memory could not be read. Click on OK to terminate the program." Shall I add to bugtracker?

Yes both same door model, greebo. Well, this might give a clue as to where the flaw lies maybe. I just reloaded the test map and the rogue is now in the normal correct position. Rubbing my eyes I created a new door and on this one the origin showed in the wrong place again. I then saved the map and instantly it was corrected. Maybe that's why I never noticed before since I save very frequently. Since the doors work OK in game it presumably is a temporary display glitch but is reproduceable. Let me know if you want any log output or whatever or an entry in bug tracker.

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?