Search the Community

What do you mean the last map is opened? I have never heard of maps being opened automatically, is this a new feature? If this is a feature, then it certainly needs to be controllable. I would not vote for an "open last map automatically" feature at all for precisely the reason you suggest.

I have checked out the DarkMod source, yes. At the moment it doesn't even start to compile due to the mismatched filename cases, but this can be fixed. I guess there is no reason why I can't start getting the Linux build working, I'm a bit nervous about making changes which might affect the Windows compilation, because I would have no way of testing this until somebody else complains, but I suppose that's what we have source control for.

I wrote up a design, it was met with general approval at the time, so I wrote it that way. The specifier is there because the component type alone doesn't tell the parser what variables the FM author wants to look for with this component. For example if the FM author puts in a KO component, what do they actually want to check, KO of a particular AI specified by name, KO of a particular team specified by name, or just KO's among all AI? Once the specifier type is parsed, the system knows which variables to check on the AI that's been KO'd to see if it completes that particular objective component. The reason that there's space for two specifiers is that some cases allow for two specifiers. For example, COMP_AI_FIND_BODY : Which AI do you care about finding a body, and which bodies do you care about them finding? You could specify that a particular AI should not see a particular corpse, both by name, or a particular team should not see a particular type, i.e., team mansion guards should not see AI bodies of type human (rat bodies are okay). The second specifier is not needed in most cases though. I don't see how you could operate without the specifier. You could make a component type for every specifier, like KO_ByName, KO_ByTeam, KO_Overall, but then you'd end up with a huge list of possible components for every sensible permutation of component type and specifier type. To me it seemed cleaner to separate them. If you don't like the specifier being an enum, how else would you prefer it to be read in? I guess it could be a hashed string instead of an enum. As for string specifier value and int value, I agree there's no need for that in retrospect. It could just be converted to numeric as needed in the parser. I'm not too keen on rewriting the objectives parsing and event handling at this point, since I've still got more high-priority stuff I haven't yet finished, but if you or anyone else wants to, it's pretty self-contained in /src/MissionData.* It could probably be done without requiring much knowledge of the SDK library.

Ah, yes - it's treating it as a dynamic image for some reason and thus disallowing it cause of security reasons. Now, who in their right mind puts an apostrophe in a filename? That's no good for the Internet.

I think far cry had better environments than this. The only reason oblivion has better characters and models is because of the huge poly counts they have. A character in armour can be over 15000 polys. I don't think making everything high poly counts as being next gen. Consdiering how well this game runs on my old computer, it's certainly not next gen. Crysis is next gen, and I'd be surprised if it even runs at all on my computer.

It can be easily be balanced by adjusting what the default setting for ambient sounds is. There's no real reason to make footsteps unrealistically loud to balance something that's trivially changeable.

I've never understood what those progressive funk and techno tracks had to do with medieval cathedrals. Music like that simply didn't exist in those days, and doesn't evoke anything for me, expect generic creepiness which would fit any scary movie or game. The only reason you think different, is because they came with the game, you liked the game, so you associate them with a game you liked.

I think I can help with this. When I changed the .gui file for the main menu for the longer version of the song, I noticed this effect, too. I noticed that it played through completely after it has been cut off and restarted - what happened: in the definition for the credits screen a timer reset on 90000 was defined. For some reason it triggered the music reset, even if you didn't click the credits. I got rid of the effect by including the time reset into an if-condition that is only true when credits has been actively clicked. I'm not sure if the change got merged in, I'll check the code at home.

Its not the upgrade process thats at fault. What I mean is there are some legitimate reasons for using this type of code. If it has to run on older machines for example. Fact is its just another contrived reason to force people to upgrade. Microsoft is good at doing that. Introduce incompatibility's so older software wont work. They revise the software to work on the new os. Guess what now it doesn't work on the older ones anymore. Now people have to upgrade to use their software. Hope this makes sense im really tired. And is that really a joke ? Isn't that basically what novell and microsoft getting into bed together portends ? Embrace, extend, destroy.

Is there any reason that you couldn't just use something like the following as a parent window for the bindDefs?

I haven't had a chance to listen to your new sounds yet, but I'm sure they're great! I noticed you were remaking the footsteps. I initially wanted to avoid doing that, since the T2X footsteps had that familiar Thief sound to them, but it's all good if you do remake them. They will be our own then. One small request. Since I haven't heard them yet, I don't know if they do this...but one main reason I didn't like using Theo's footstep sounds is that they didn't have that Thiefy style to them. Theo's footsteps simply went... Clunk clunk clunk, but the Thief sounds had a nice 'heel toe' sound...more like, ker - clunk. I'm sure your footsteps are awesome.

I set them to insensitive, but I was always able to select them on my system. If this was not the intention of the GTK developers, I will indeed have to do what you suggested. The reason I set them to insensitive was that the S/R icons will get greyed out as well, but that is just cosmetics.

The empire was good. I think that Justus Liebig is the key reason it collapsed.

I spent the past few hours compiling a list of 2000 most commonly used German words and their English translations. Turns out over the past few years I have forgotten all computer skills, so it took a bit longer than expected. I can't query, program or script anymore, even forgot html. I learn fast and forget fast. In 2006 I started learning Japanese using the Pimsleur method, but what stopped me was the time it consumed, you can't control the speed of learning. In 2007 I started learning Chinese because it seemed more reasonable given that 80% of my classmates speak it. After a month I could hold simple conversations, and attepted to do so. However, it took me 3 times of saying something for them to begin understanding, apparently that's how horrible my accent was, so after those attempts I lost any spirit to continue using my Pimsleur CDs. (I think English-speaking Toronto-inhabiting people are used to English-breaking immigrants and are capable of understanding them, but Chinese people expect complete native Chinese pronunciation.) In our chemistry labs we have some documentation, textbooks, and some old yellowed posters on the wall in German. The Engineering library also contains mostly English works, with the remaining 20% being German, French, japanese, Chinese, Russian, Arabic. Recently I've been listening to a lot of German rock music. I've frequently thought most language-learning methods are very mismatched to how I learn. Most technical education is also mismatched. Usually any learning consists of long boring periods where my concentration is not needed, with very dense periods where I'm too relaxed to concentrate, and consequently fall behind. This led me to believe the best way of learning a language (once you're exposed to it) is to memorize a list of most commonly used words. And I am mostly exposed to Mandarin, French, German, Japanese, and formerly, Hindi, and Arabic. Because of the above I've compiled the 2000-word list, which Should give me about 75-80% word coverage in average reading materials, and I got a very popular Children's book, "Der Struwwelpeter" at http://de.wikisource.org/wiki/Der_Struwwelpeter. However, the Children's book seems a bit too short, and I was hoping if somebody like Sparhawk could point out where I could download other suitable reading materials with simple sentence structure and vocabulary. PS, there was a time whhen I could hold a conversation in French, Dutch and German, and could read Arabic, but I learn fast and forget fast. Last year I spoke Japanese to professor Masahiro Kawaji, he told me I should speak to Douglas Reeve instead. For some reason that demoralized me and I put away the Pimsleur CDs.

I was just noticing the animations seem really good on the characters. I was watching what happened after I'd been killed, and this guy was crouching down and looking back and forth in a really believable manner, then some walk with a slight limp, and lean on tables at the bar, etc. It all helps to make the people believable. Playing on the hardest difficulty is pretty hard, but getting easier since I found some guns with actual stopping power. The AI have surprised me on several occasions. For example I was stalking one outside the ruins of a 2 story building, I lost track of him, and then all of a sudden I was getting shot at from the second story that the AI had climbed up to get the drop on me. He must've had to do some fancy jumps to get up there too, since there was no remaining staircase. On the other hand, they sometimes do this weird grouping behavior where they all end up huddled around one point in space for some reason (I think it has to do with protecting an objective or something). This is a great opportunity to toss a 'nade right into that tightly packed group. They come to their senses again if you save and then restore though. Question: What is the key for dragging a body? The "tip" says shift + use, but I've rebound my keys and don't remember what shift was originally bound to, and couldn't figure it out.

Beyond the Red Line is a total conversion of Freespace 2, using the open-source version of the FS2 engine. The reason they're releasing a demo is because it's not done yet.

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.

Has it really been nearly a month? Bah, I need to get off my lazy butt and do more...anymore animation assignements that need to be done? Are those latest 3 being done by Domarius or are they open to anyone? Anyway, I've almost completed the runcycle that I'll use for the civie run/shielding face animation. I can also modify it for any other running animations we might need. I've included a zip with 3 different views of it (a normal one, one in slow-mo, and another of running in place). Should make it easier to get a feel for what it looks like (as with before, ignore the trailing polygons behind him as he moves forward since it won't show up on the actual animation): http://www.geocities.com/canisinvicti/Run.zip It's still a little rough in some parts, I'm considering just scrapping the hip motions and redoing them since the movement is a little eratic for the upper body at some points. And for some reason it seems like he should be running at a faster rate for as quick as he's moving his legs, so I might increase the movement speed a bit (although it also depends on just how fast we want him to be able to run in the game). Also I still need to tweak the arm movements a bit. Otherwise, I think it's good enough for now.

@Fidcal: I'm afraid you did not use the latest build I linked three posts above? The "Add S/R" button and the response scripts have already been removed/replaced/redesigned with new items. The system has been undergone quite some changes, so some of your suggestions are already implemented. I agree about your point of having a possibility to override inherited stims and responses. And this is exactly the reason why I included the index column in the list, because you will have to define a stim on the inheriting entity with the same index to override it. I will have to look at your other feedback again in more detail, I couldn't go through everything right now. I'll edit this in this post. edit: As above, the IDs are the key to override inherited stims/responses. The functionality is lacking at the moment, so I'll have to add such an option to "override" stims and provide another effect that does just nothing. I agree that Stims are different to Responses, but for consistency/flexibility reasons I'd vote for leaving them in one list. I would find it inconvenient to switch dialogs between setting up stims and responses. Then again, that's just me. The "Add S/R" is gone and has been moved into the context menu of the S/R list. Agreed and confirmed, I'll implement such an option to define an "override" stim/response using the exact id of the inherited one. There will be an "effect_nothing" that will just do nothing, if no alternative effect is desired. This works for me, the widgets are of course insensitive, but I can see the value (compare default light_torchflame entity). There is an effect_script now that can be used to fire custom scripts, if the existing predefined effects are insufficient. The parameters of this function are fixed, but you can store additional information on the entity that can in turn be used by the script. This is a more sophisticated setup and will require some additional work than just clicking. The GUI will probably be not much of a help here, I'm afraid. The entity inspector and your preferred script editor are the way to go here. What do you mean here? Some kind of textfield whose contents get stored in the entity or something different? A small set is already available, more certainly are upcoming on request (if they're easily implemented). What do you mean here exactly? Agreed, that might be safer.

I'm not sure, but you might have to set a light in such a room as well. If you don't put a light in it, it considers the room to be leaking for some reason. Or you got a compile error, not sure which as I haven't done this for some time now. EDIT: Just tested it and it doesn't require it. I seem to remember that there was something. Maybe it was just that it needed to be textured. Which would make sense, because this is required for the leaking check.

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.

Have these been mentioned here yet? For some reason, the thought of these make me drool rather sloppily... http://stores.castlekits.com/StoreFront.bok Admittedly, I could be expecting too much of these, but the set tiles and complete kits look sweet. For example, http://stores.castlekits.com/Detail.bok?no=30 . 600 pieces?! I haven't figured out what they're made from yet. The website isn't too great, and leaves a lot inconsistently unclear (counts, sizes, materials).

Hmm I haven't had much corruption yet in my current map... I don't think... I haven't BSPed it in ages. It's pretty screwed in places when I load it into D3ed (patches move 90° for no reason), but that's probably because it's mostly done in DR. Even a small manor house though takes AGES. Been mapping this morning, it's just depressing realising how much work there is. You do the brush layout, then you have to set up all the lighting, all the models, all the doors. Then you put in the loot and AI. So it's not massively hard. It's just time consuming, and you have to really think and get inspiration to keep going, which can be frustrating when you haven't got that many resources like in TDM at the moment. Then you playtest and it's bugged . Hopefully not. I'd say DR is a lot more stable than D3ed.

No, once you cross that river, then why not just have a 'magic' potion which creates a 'shield' around the player that keeps him totally safe, or keeps arrows away, or etc... The problem with 'magic' is that it's boundless. If you can easily do one totally inexplicable thing like instantly heal a broken leg with magic, there's no reason why you can't just do anything with it. That's exactly he sort of arbitrary, abstract system I'm try to get away from. Yes, but as I said, you can implement a realistic system without actually implementing every single detail of reality. It's ok to leave out certain aspects of reality, or slightly exaggerate or diminish them if it's appropriate for the gameplay. THis is still better than a totally abstract and generic system with no connection to reality at all. Bickering over what is 100% realistic or not has no purpose here, since that's t the point of the exercise. Still, as a medical man, if you can think of a better system, which is more realistic, but is also workable from a gameplay perspective, then don't be shy. All of what I said in that post was just off the top of my head, which shows how easy it is to think of alternate health systems.

What's that example meant to prove? Having no health system at all is an improvement over 'having a little health bar pop up when you're 'wounded'' What the hell does 'wounded' mean in this case anyway? We've had this discussion before, 9 times out of 10, if you're hit anywhere with an arrow, it's mission over, you're never going to carry on, and if it's only a scratch then it's not worth mentioning anyway. This idea of minor wounds gradually adding up to 100, and when you get the final small scratch which takes you from 99 to 100 damage, it means you're dead, makes me laugh. Either have a body awareness system for the player avatar where you can tell exactly where on your body you were hit and what kind of wound it is, or just have the player killed in one hit. It's not as if he's wearing any armour anyway. This idea of generic hits and generic damage and generic instant recovery is an irritating and pointless nonsense, and I don't know how you can have anything but contempt for it. Once you have this complete body awareness system, then you can start to implement some adverse affects depending on the position and severity of damage, and introduce some ways of repairing specific types of damage in a more realistic manner. I know, I know 'but people will just keep saving and reload if they have to suffer any adverse effects from damage, blah blah etc' This is yet another reason why it's necessary to have at least limited saves or auto save points, or better still, no saves at all. Any decent health system you can think of, which has actual consequences for being a stupid and useless enough player to get damaged, requires a limited save system of some kind, since, in a recent study, approx 99% of gamers were found to be worthless cheating scum who'd sooner fool themselves into thinking that they're great than face any consequences of their inadequate skills.