Fidcal

Dark Radiant 0.8.1 of 12 Apr 04 Thinking I was in Dromed I tried to zoom out with the minus key and noticed instead the minor grid lines disappeared. On the shortcut list I see it is listed as TexToolGridDown but there is also TexToolGridUp with the plus key but I couldn't get this to work on the keyboard or keypad plus key. I got the grid lines back with the number keys OK so no problem there.

Thanks yes greebo, it's now asking for another file. I'll try the binary folder first. See if that fixes it. I assume the other you mentioned is the whole source package for GTK Radiant on which DR is based? To where do I extract the binary folder? Straight into the DR main folder?

OK, thanks greebo, got it (though strangely Opera insisted on changing it exe and then .dll.exe but I finally forced it to .dll. However, now DR is asking for libpng13.dll. Can you oblige please?

I'd think that would be fine. Do you mean a separate list pops up over the add button and the current pop down list from the type box stays where it is? Sound good if so. I think I just picked up on the idea of saving coding by just having one selector list but whatever works so long as the user can select what stim to add. And it's easy to use. And it's easy to code. And it works OK. And it looks good. And everybody likes it! Haha! No pressure. I very much appreciate the new upload. I'm just getting it now. This broadband makes it so much faster it looks like it'll be downloaded before I post this.. Yes, but I get an error when I try to run DR now. I get libcairo-2.dll not found. Can you upload that somewhere for me please? Or update the whole download and I'll get it again. Thanks. Unless WinRar has unzipped it to the wrong path - can't see it. No a DR folder search can't find it.

I also just get the outline highlight on the inherited stims if I use the arrow keys but I get nothing in the edit boxes at all. see HERE. If I add a frob stim then check 'radius' then the default 10 appears but I cannot change it. Further, if I cancel and exit and re-open the dialog then that default radius shows for the inherited stims too. It might just be the map I am using. I am using the fire entity in the snow map. Maybe the stim properties are just not set up here yet to get DR to make sense of it. My broadband is now activated but I'd be reluctant to get that awesome 3GB plus download yet as I am only allowed 5GB a month and don't know yet how much I'll be using for other stuff! Hate to download it and find myself internet paralysed till next month! As for the selector list I was visualizing a drop down box like the one now that drops down from the type button on the right. The same one could still drop down but activated by both that button and the add button. Or alternatively a pop up box. To replace the edit boxes temporarily with an 'embedded' selector list might seem odd. Hope that makes sense.

Without mentioning DM I've been trying to find out HERE how many new user stim names a Dromeder might need. That is, if DM went the route of a finite number of set unused names allocated to the mapper, what might be a practical limit. I don't want to encourage the fixed allocation of user name route but if taken it might not need to be that large. Note also the unusual method of using a min and max intensity as a 'wavelength' so the same name could be used over and over for different tasks like a key ID. I assume 'magnitude' in DR is the equivalent to 'intensity' but is it intended that a response would respond to any value up to the set magnitude or just exclusively to that one value? Dromed has min, max settings plus no min (ignore min) and no max. If the above 'trick' were available so a mapper was not completely stuck after using all user names then perhaps only 10 fixed names UserStim0 to 9 might be enough. I'm thinking of if the only practical way to provide them was in a selector list where a hundred such names would be ridiculous. At the end of the day the ideal will always be for the mapper to have the option to create distinctive new names.

I think it's because I'm using the beta that I'm not seeing what you're seeing. I cannot even select any of the inherited stims or responses - ie, clicking on them does not highlight them. And on added response effects I get the error message I reported before. I've never yet seen any response effects. I take the point about adding providing defaults which you then change but if the item itself is not what is wanted it feels to me like asking for burger and fries and the waiter brings a hot dog with a note 'you can change this for any food item you wish.' I don't mind customising my fries with ketchup but I'd prefer to actually get fries from the start. Does the selector list have to be an integral part of the selector button? I envisage the two buttons as you now have them : 'add' at the bottom left and the type button at top right but both open the same selector list. The edit button function points to the highlighted stim in the left list; the add button function points to the next place at the bottom of that list. I like the idea of keeping editing on one side and the add and remove buttons on the left side. But I think if clicking the 'Add' button makes a list appear on the right it won't be confusing. A compromise might be that when the 'add' button is clicked it adds a blank highlighted numbered place holder at the bottom. I know this sounds nitpicking but I just hate wanting to add a holyStim and click add and a frobStim is added. It just feels 'huh?' to me. I still think the ideal is to click 'Add' and a list appears and you select what you want. When you create an entity you select from a list; you don't click 'add entity' and a zombie is created which you then change for a bucket. It is accepted that you might then change the default properties of the bucket to something else but the zombie would be something of a surprise.

Yes, it's definitely starting to look great. Very nice. I like also that in DR you do all these stretchy resizable dialogs where the content resizes itself as far as possible to fit. Not all programmers bother and just have one rigid dialog, often with a lot of waste space. The tabs give you more room - be nice to see it when the other fields are added. Still adds a frob which then has to be changed but I assume you are going to change that to a selector from the add button or merge with the type button as an add/edit button? So the user will click that button, if an existing stim or response is highlighted then selecting a stim name will change it but if no existing stim is selected then a new one is created from the selector. Hope also to see the properties of the inherited stims and responses even if they can't be changed. That is planned isn't it?

Thanks greebo. Downloading... Looking forward to seeing this one.

Yes but just because Dromeders sometimes used s & r to achieve effects that Dromed did not provide by any other means does not mean that they did not also use s & r as useful vicinity triggers when no other vicinity trigger would have been suitable or even work at all. If map makers cannot create new stim names or at least use some reserved unused names, how will they set up a new stim/response trigger when needed? Even if a script does what they want if they need a trigger where two things come into contact, how will they create such a trigger? They will be forced into the bad practice of using an existing stim name and taking care not to allow anything else that responds to that stim to ever come into contact with it. There will always be the risk of conflict. It is not the effect that is the problem; it is needing an exclusive trigger that cannot trigger something else by mistake or indeed, the response you want be triggered by a different trigger than intended. If a mapper needs to set up a situation where an effect or event ONLY takes place when Item A comes into the vicinity of Item B, then an exclusive trigger is needed - even if the effect is some simple already-provided for effect. Let me recall some examples from my own T2 missions... Example 1 : The player has to place an ring on a particular table. I added a new stim I named ringStim to the ring and a response to that stim on an unrendered marker covering the surface of the table. If I had used an existing stim such as fireStim then the ring might kill the player or an AI carrying a torch wanders too near the table and 'Objective Complete' displays. If I used say, an existing stim called 'frobStim' to send a signal then if frobStim is used anywhere else in the mission then there is the risk of conflict. The player or another AI brings some other item with frobStim on it near the table and 'Objective complete' pops up. Or the true ring is not dropped on the table but on or near something else with a frobStim on it and it calls a completely different effect. Example 2 : An AI has to fight a winged harpy like creature with 'flight' simulated by vertical motions up three to six feet as the AI attacks with a sword. I add a new stim to the AI's sword, let's say harpyStim, and a response to that stim on the creature. As the AI's sword comes close to the creature an incremental vertical teleport offset response kicks in as the response to the harpyStim on the sword. The creature flits about its attacker in quite a realistic way. Again I cannot use an existing stim name such as waterStim or the AI might find torches being extinguished by his sword and the harpy will fly if I wet it with a water arrow. Might be fun but not what is intended. So it's the exclusive trigger that is the problem. How to trigger an exclusive effect when sword and harpy come close and when ring and table come into contact. If there is a serious problem with a mapper adding new names then just include some unused ones : UserStimA to UserStimX or whatever can be squeezed in (the more the better, a dozen might not be enough.) They should be easy to include. If they are not used there is no harm done but if they are not included then mappers will improvise with existing names and keep their fingers crossed. By merely adding a few names to a list you provide Dark Mod with immense extra power and flexibility to the imaginative mapper. More efficient of course if the mapper can give them sensible names - maybe even virtual names - an extra string field to help the mapper ID his creation. If Dark Mod provides some other means of detecting when two items are in vicinity of each other with the flexibility and control of S & R then why include S & R? Even if Dark Mod might provide an alternate way to effecting my two examples, can it be guaranteed to do so in every possible situation that a mapper would like to implement?

Just to reinforce this, Dromeders routinely create their own stims. Here are extracts from an old Dromed S & R tutorial by Sledge. Note the importance of the last sentence of the first paragraph... "When doing your own effects, it is best to create an entirely new source or "stim." Click on Stimulus in this part of the Object Hierarchy and click "Add." Type in the name of whatever stim you like. Then, save the gamesys AND the mission you're working on. You have to re-open your mission for this particular change to take effect. Make sure you have set the gamesys in your mission (set_gamesys x.gam) before you save and re-open the mission. If you have a new stim to use, whatever new effects you create will in no way affect anything else in the game." "For most things, you will want to choose your own custom stim. From the drag down menu, select the name of a stim. If you added one previously (see above) and saved your gamesys and re-opened your mission, your new stim should appear at the bottom of this menu." I see this tutorial includes a list of all response effects and what they do in Dromed (though I'd have to examine it more closely to see if it is T2 or T1.) The whole text file might be of interest and stimulate ideas. It is published publically somewhere but if anyone wants I can upload it to my site. It's only about 36K so can be skipped through reasonably quickly for anything relevant. Hell, it's no effort so I'll put it up anyway HERE The topic of the mapper making changes to the properties of archetypes (which again, Dromeders are used to) has been raised and might need its own thread at some point. I see the def files but not the hierachy - what properties would be inherited by other entities. I won't pursue this here but many Dromeders would be looking to see how to do this if they moved over to TDM.

A stim name itself is just a label, a name without any properties whatsoever. What properties does 'waterStim' have? None of itself. Any properties such as radius or contact, intensity, etc are defined in an archetype or instance and can be different in other archetypes or instances. Suppose I want to make a map with radio-active materials in a mine, maybe a few rats down there get radioactive too. I need to create a new stim and call it perhaps radiumStim. Where would I add that name in DR? There must be a list of default stims to which the map maker can add more for that map only. Anyway, once added to the list of stim names for that map it has no powers nor properties of any kind. It's just a name. I might change my mind or forget it and not even use it at all. When I add that stim name to some rock I define some properties on that rock archetype or instance alone to be associated with that label radiumStim. On one rock it might be used as a weak radius stim and on another as a strong contact stim. Whatever properties I define are on a particular archetype or instance only and can be different on the next one. If, in Dark Mod, it is NEVER possible for the map maker to add new stims then it is ESSENTIAL that a generous set of spare stim names be included and NOT used in the general hierachy so they are free for the map maker to define. Various unused generic names might be included such as magicStim, vomitStim, slowDeathStim, etc. but the possibilities are endless so maybe the answer is to include names like A1 thro' A9, B1 thro' B9, etc so if I want to create a radiumStim I can at least use the name R1. It is possible but risky to use existing stim names that are already in use for something else. For example, if Dark Mod includes a 'holyStim' for use on holy water against undead and my map does not use undead I could use that stim for some other purpose like a stinkStim the player might drop to deter human guards from the area for a time. But if undead with a built in response to holyStim came along they would die which is not what is intended. A poor example but you can see that map makers need to take great care if using stims for other purposes that they do not come into contact with the wrong response. It is bad practice to re-use stims that way. Hence the need for the map maker to be able to create new ones or at least use ones that he/she knows are not used. Care also needs to be taken with third party add-ons that might include use of these normally unused stim names that they are declared.

Agreed. By 'separate list' I meant separate from the right context menu not a separate dialog - a drop down list box or whatever in the same dialog but shared by the two selectors : the right context menu and the add button. OR (as I'm not sure but maybe this is what you are doing) just the add button alone. By 'dynamic' I meant, well I think I misused the word, I meant not a fixed passive list of stims that is hardwired into your code but will include new stims as they are added. Suppose I'm stating the obvious really but it had to be said. I agree about buttons 'Save and Close' and 'Cancel' sounds good to me, and removing the revert button. Orbweaver : I think the tabbed pane is an even better idea than separate dialogs; I'd forgotten about those. That sounds perfect to me. My suggestion to separate stims and responses is an organizational and conceptual one. When they are mixed it suggests a group of similar things - that there is some kind of commonality of type. There isn't. And you 'never' access them together. At the moment there are already two quite distinct sections bolted together to form one dialog with a few buttons shared and two unlike types mixed in a list. It can be made to work yes but if it had started with two tabs I doubt anyone now would be wondering whether to attach the two tabs side by side so they can be seen together. I suppose I've laboured the point but I was asked for my views on the s & r interface and I like to do a thorough job!

I forgot to include if I select a response then right-click into the lower list and choose "Add new Effect" I get 'Error eclass pointer invalid.'

OK, I'll assess it afresh as I see it now without reference to or influence by any other proposals or plans. I've been examining this all afternoon so these are my views below. Hope there is something of use... Firstly I stand by what I said before that stims and responses are completely different and I would prefer them listed separately because the user will be dealing with them separately at different times, even exclusively. These are typical examples of how I might normally be working with S & R in real situations... Example 1 : I want to make an existing floor surface, say a carpet, damage the player when he walks over it. I select the carpet and add a fire stim or any stim that already exists that will provide the effect I want. I have no interest in the carpet's responses to other stims, whether it fades in sunlight or dissolves in acid is of no more consequence for this task than its coordinates or its colour. Job done; I do not need to concern myself with the player as I selected an existing stim that does what I want and I know the player will already have the response to it that I want. Example 2 : Ditto above but this time I want the player to be thrown backwards when he steps on the carpet. Again I go to the carpet. Again I have no interest in the carpet's responses to anything. This time there is no suitable stim so I want to invent a new name say, throwStim. Creating a stim actually just creates a label, nothing more. Will it be possible to create this name within the editor or must it be added separately then selected in the editor? (as in Dromed) Adding the stim to an entity defines its properties on that entity or entity type alone. I want to add it and select say, 'contact' type. The intensity is unimportant in this case. I've finished with the carpet and the stim. I close the s & r interface. That task is done. Now as a separate operation on a different entity I want to add a response to the player. I am not interested in any stims that are on the player I am only interested in adding or editing a response to the throwStim. I am no more interested in the player's stims than I am interested in any other property of the player; they are irrelevant. I DO want to see a list of responses in case a response to touchStim is already there or I want to select it later to re-edit it. You are not normally going to be adding/editing both stims and responses on the same entity as part of the same task. Even if I could think of a situation where I want to add both a stim and a response to the same entity at the same time they are still different tasks and I see no reason to mix them in the same list. Furthermore, at present it seems you can convert a stim into a response and vice versa which is meaningless. If I add a response in entity A to stim B to set the property C on entity D to be the same as entity E and later hit the stim button then presumably all thoses settings are lost and the item in the list is now a stim B doing nothing and to which I now need to add a radius and other qualifying properties. I might as well change an ocean into a cabbage, losing all of its aqueous nature and then start adding vegetable properties. Having the same interface might be OK so long as the two are listed separately but I'm beginning to wonder if there is even any point having the same interface. But I started to create a mockup (see S&R MOCKUP) but this persuaded me that they are best in two separate interfaces. Stims have completely different fields to the responses; they are incompatible and make less and less sense to me together both in useage and conceptually. Here is a rough mockup of two separate editor interfaces. Both require much more of course: STIM EDITOR MOCKUP RESPONSE EDITOR MOCKUP You might wonder where do scripts go in the above response editor? They are included in the effect drop down list as eg, 'call script'. The user then selects the 'edit effect' button and enter the script name and any parameters and these are displayed below the effects box. If you stay with the current mix of s & r in the same interface then it still has two separate sections anyway, one to cover stim properties and one to cover response properties. It's a nice idea to unify but you will never be using it that way - you will be using it as a stim editor on one occasion and a response editor on another - and both will be a compromise to cram them together on one panel. Why not have two separate dedicated interfaces where there is no muddle or confusion? To continue with the current s & r: I cannot select existing inherited s & r to examine them let alone edit them. Right clicking to add or delete is fine but a separate add button is the more common useage. It is true that in for example, the Wndows Explorer interface one can right click an empty space in a window to say, create a new text document but there are also separate options in the file menu to select 'new' or of course in a text editor. At the moment the onlything I can add to the list is a frob stim and then change it later to something else. Horrible but I now see the problem. If the menu is hard wired into the program then you have to create a default entry before you can edit it. I suggest that both the right click menu 'add stim' and a separate add button both call up a separate list, either a list box or a menu such as on the type button now. Whatever is used it must be dynamic so new ones can be added. A separate 'change stim' button calls up the same list but only when an existing stim is selected. I think I would be tempted to do away with or disable the X close button at top right and to avoid any doubt whatsoever have two buttons 'OK' and 'Cancel' which I believe are in more common useage. 'Apply' is elsewhere used to mean 'apply but don't exit' whereas 'OK' means 'apply and exit'. While 'close' does not explicitly mean 'cancel and close'. With a radius stim is needed not only the radius and intensity but also a flag to indicate if the intensity falls of slowly from the centre to the circumference or is constant throughout. The stim needs a period cycle, eg, every 3000 milliseconds, and the number of cycles with the default (in my experience) of unlimited plus an option to destroy its host entity on completion. Thus from creation the stim might fire six times every 3 seconds then end with or without destroying the entity. Or the stim might continue indefinitely though thoughout the duration of the game.

Downloaded yesterday's DR from post #46 in this thread and extracted it over my previous DR install. Just a very quick look: S & R not working at all for me. The interface comes up but all options are disabled except the bottom three buttons. If I open an existing entity that already has s & r then they show but their response effects do not nor are they editable in any way. Is this because I am using the beta issue of DM? Hang on, if I right click in the top box (not obvious) I get Add new s/r. If I click it then it adds a frob stim and no other choice. Ah! so then I can change it to something else? !! I have to go out but I'll check this later but first impression is VERY confusing. I'm assuming this is not working right. I HOPE it's not working as intended!

OK, last night I only saw the other thread and didn't realize there was a new download. No problem, in fact good to refresh for myself how it was. I just downloaded the new one and will post later. PS : I have finally ordered broadband but this will take another week or so to be activated.

OK, now posted on the S & R thread.

OK, feelings about the S & R interface. This is without reference to anything that has been posted above but is just my reactions to the S & R dialog in DR v.0.8.1 (sorry but that's the number in the 'about' but it's a later update!) By 'dialog' or 'dialogue' I mean the main displayed panel or interface. I might use 'source' and 'stim' to mean the same thing. Likewise 'response' and 'receptron'. Though technically they are not quite the same things. First here are the links to images of the Dromed interface for anyone's reference: Dromed Source dialog Dromed Receptron dialog I like the idea of having one dialogue for both S & R but not so sure about having them in a mixed list. Nor do I see the reason for the ID number to be visible to the user unless you have some debug output where it's of use. Unless you can actually pinpoint a use I'd drop it. So I personally would favour having two separate lists in the one dialog. There may even be a case for having two separate dialogs (like Dromed) if it is going to get cluttered. An alternative to consider is one dialog but can switch between showing stims and response lists. After all, although related, stim and response are two quite different things. Remove the Stim and Response and Add S/R buttons and replace those three buttons with just two : Add Stim and Add Response. As it is you can change a stim to a response and back again. Hard to visualize the effect of this once set up. Here's me browsing through the fire S & R in the snow test map... I note I cannot select the inherited S & R that is already there. I see water, fire, and KO responses plus fire and visual stims. At the bottom in response scripts I see Fire, knockout, and water which also I cannot edit. I need some means of either modifying or aborting inherited S & R. In Dromed the only way to stop an inherited response is to add another of the same name set to abort; this then functioned first and stopped the normal response. I would like to see the possibility of changing a fire like this so a water arrow does not extinguish it or its a big fire and you need more water. Not great examples but there are situations when you want to be able to change the default - and probably the way is an over-ride that has an OPTION to abort any existing s & r of the same name plus an option to add a new one. So to change the damage points done by a fire one might either be able to modify the default or cancel it and substitute another. Even if the inherited s & r cannot be changed I think one should see the values associated therewith, eg, what is the intensity or type (radius/contact) of the fire? The scripts need a means of adding parameters; at its simplest a sequence of string values with separators. Room for comments might be useful. Adding custom scripts should be a less-often-used alternative to give 'infinite' flexibility. 99% of all response effects ought to be selected from a list like Dromed with various fields for the parameters. Of course, these are then passed to scripts. Good examples are in the Dromed receptron image link above. The target object is the object on which the effect is to act. 'Me' in that group is the object on which the response property is set 'Source' means the object giving the stim The agent object is for reference information, eg, a teleport might be absolute or offset from a target object. Other parameters are added via the 'Edit Effect' button which reveals a fields input, eg, for the teleport offset. Althought the Dromed interface has been criticised you can see the simplicity of being to read the list of receptrons on an object and see the actual effect of a stim, eg, add metaproperty. I would consider a separate delete button from the right context menu option. Maybe the revert button should have a confirm y/n as some s & r can take a while to set up and it would be rather devastating to have it blown away with a careless mouse. I've gotta go. I'll look at this again later or tomorrow. I'm on UK time.

I'm well motivated - in fact I had already took another very quick look at S & R earlier today. Thing is, although I know a bit about S & R I am a total beginner with DR and Doom editing generally so I have been trying the last week or so to get familiar with mapping first. But progress has been real slow because of the fragmented info (which is why I was pushing for one big beginner's tutorial) In other words, if I was using Dromed I could knock together all kinds of S & R tests very quickly but not with DR. For example, I grabbed a crate earlier and added a water response with the intent of testing it by shooting at it with a water arrow. But so far there are no selectable responses built in except to trigger a script. But of course I don't know the names of any scripts let alone any parameters they might need... haha! I wanted to look at the (supposedly) fire stim on a torch but have been unable to make a proper torch! Duh! I made a couple of things with arrows that thereafter could not be selected in xyz or camera so had to abandon that test map! You see I'm hampered by gross ignorance at the moment. Anyway, if you just want feedback on the interface itself I'll take another look later. I do have one or two things about the interface to mention but I want to spend an hour with it. I'll probably dig through some existing test maps but is there much use of S & R in there to look at?

IMO all three view coordinates should be stored (and saved when the program exits for restoring when DR is re-opened IF the user has set to load the last used map - and BTW again IMO, the zoom position and last view too so the view is exactly as left by the user to continue working.) In the top view the Z coordinate is not needed but if it is stored then when one flips to side view the Z coordinate is used to place the view position. I only show one view pane at a time but if more than one view pane is displayed then all three view coords must already be stored somewhere surely? Hang on... now I see if I open another pane it is creating another pane with its own two coordinates? If so, then if instead of multiple pairs of coordinates, all three coordinates are stored once then every view pane can access and update those same three.

XYZ ORTHOVIEWS: Ctrl + tab = cycles through top, front, side views AND... moves view centre to selected item ELSE... moves centre to camera if nothing selected. Ctrl + Alt + Tab = View to camera on selected view Crtl + Shift + Tab = View to camera on all views (I think!) They ALL move the viewer to the camera or an object. I'd also really like to be able to just KEEP the current centre, whether there is a selection or not. I have often dragged the view off to one side and while examining it use Ctrl+TAB to see it from three views. This loses my view position to the camera or selected object which I find disorienting. I much prefer cycling through views of the same thing to be from the same position. The current choices might be fine for some situations but my preferred default would just be to keep my current position (EVEN if one view is widely far away!) In any event, I see no harm in having the option even if no default shortcut is assigned. I'd make it my default Ctrl + Tab I think.

OK, got this now thanks Greebo and it seems to be in order. Player start OK. See how it goes over the next few days but I think it should be alright. Looking good.

wonky is my middle name

Greebo : Can you point me in the right direction please? The only link I have for DR is at sourceforge... http://sourceforge.net/project/showfiles.php?group_id=161727 I do use ftp so if there is some info on where and how to connect to some TDM resource let me know where the details are.