Fidcal 175 Posted May 11, 2009 Author Report Share Posted May 11, 2009 OK, I got 10 screenshots. I can work with this. Quote Link to post Share on other sites
Fidcal 175 Posted May 11, 2009 Author Report Share Posted May 11, 2009 In the end I worked from the files and it went much better than expected. There may be some compromises here and there. All now committed and I'll do some testing later. Quote Link to post Share on other sites
Fidcal 175 Posted May 11, 2009 Author Report Share Posted May 11, 2009 I think there's more. Not all moveables are in moveable def files. Quote Link to post Share on other sites
Fidcal 175 Posted May 11, 2009 Author Report Share Posted May 11, 2009 Hopefully now finished. Have updated test/propagation3.map with more varied range of objects. These no longer have special test values added in the map but use the new values. Quote Link to post Share on other sites
Ishtvan 17 Posted May 11, 2009 Report Share Posted May 11, 2009 Sweet, haven't got a chance to test yet but it sounds promising. We might still want to have the capability to be totally silent. We used to be able to do that by just not setting sprS_bounce_*, but now that the code is automatically looking up the global suspicious sound shader, I'm not sure if there is a way to make it AI-silent anymore? Something else also occurred to me. We can no longer do quick volume offsets in the individual defs, can we, because we can't do "sprS_bounce" "<global shader name>:+15". Or can we? Don't know if that's a big deal or not. It means people couldn't make a slightly larger rock, inherit the standard one and then change the volume quickly in the local entityDef. They would have to make a new global sound def. Maybe it's okay though because they are supposed to follow categories anyway. Quote Link to post Share on other sites
Fidcal 175 Posted May 11, 2009 Author Report Share Posted May 11, 2009 I doubt it because there is no volume or alert value applied directly to the actual entities - only a size and hardness category. Could be useful if easy to implement but otherwise I think we have a reasonable compromise that is easy to follow. Quote Link to post Share on other sites
Ishtvan 17 Posted May 11, 2009 Report Share Posted May 11, 2009 I doubt it because there is no volume or alert value applied directly to the actual entities - only a size and hardness category. Could be useful if easy to implement but otherwise I think we have a reasonable compromise that is easy to follow.Well, when the code is generating the string for the global suspicious sound shader to play, it could also add the ":<offset>" after it. I guess since we're using spawnargs now, we would need to read it from a volume offset spawnarg. Seems do-able. That would allow FM authors to say "this chunk of lead is like a small hard rock, but a tad louder." Quote Link to post Share on other sites
Fidcal 175 Posted May 24, 2009 Author Report Share Posted May 24, 2009 Reviewed this again and now I've slightly increased med & large hard objects on hard surfaces. Effectively these values must be fairly close so I'm closing this on the tracker. Some may be a little low compared to real life but the values have been compromised for good gameplay. Anyone is still free to recommend changes to values of course but this is best if it arises out of real game play imo. Quote Link to post Share on other sites
Ishtvan 17 Posted May 24, 2009 Report Share Posted May 24, 2009 Yeah that seems about right. On a separate note, it seems like the alert from arrows breaking/impacting nearby and the player whacking a stone wall with the sword went down a lot? That used to get an alert from pretty far away (and I think it still should), but now they barely notice. Quote Link to post Share on other sites
Fidcal 175 Posted May 24, 2009 Author Report Share Posted May 24, 2009 Are they affected by this system? If I allocated arrows to the small hard group and the sword to medium-sized hard group. Assuming I did then I would have been thinking of a junk arrow or sword. Presumably there are separate entities for actual weapon types and moveables. If so I'll have to have a look at what I did. Quote Link to post Share on other sites
Ishtvan 17 Posted May 24, 2009 Report Share Posted May 24, 2009 I didn't think they were affected by these changes. Those sounds should be separate things defined on the projectile like snd_break and defined on the melee weapon like snd_hit_stone. They are not bounce sounds. Maybe it's the AI response that changed and the volume of those sounds needs to be pumped up accordingly. I don't know at what time arrows breaking stopped being loud. Quote Link to post Share on other sites
Springheel 4668 Posted May 24, 2009 Report Share Posted May 24, 2009 I don't know at what time arrows breaking stopped being loud. I remember commenting on that same issue back when we were playtesting St. Lucia, so it's been a while. Quote TDM Missions: A Score to Settle * A Reputation to Uphold * A New Job * A Matter of Hours Video Series: Springheel's Modules * Speedbuild Challenge * New Mappers Workshop * Building Traps Link to post Share on other sites
Fidcal 175 Posted May 24, 2009 Author Report Share Posted May 24, 2009 I didn't think they were affected by these changes. Those sounds should be separate things defined on the projectile like snd_break and defined on the melee weapon like snd_hit_stone. They are not bounce sounds. Maybe it's the AI response that changed and the volume of those sounds needs to be pumped up accordingly. I don't know at what time arrows breaking stopped being loud.OK, not my problem as far as this thread covers I recommend you add it to tracker. Quote Link to post Share on other sites
Ishtvan 17 Posted May 24, 2009 Report Share Posted May 24, 2009 Okay, it's tracked. I'm not sure what could have caused this, unless maybe the global soundshader in propagated_sounds was decreased in volume for something else and it also affected this? Quote Link to post Share on other sites
Ishtvan 17 Posted May 26, 2009 Report Share Posted May 26, 2009 For some reason the moveable candle in Demagogue's FM had a really loud sound to the AI. Maybe it just needs to be updated, but wanted to bring it up in case it's a bug. Quote Link to post Share on other sites
Fidcal 175 Posted May 26, 2009 Author Report Share Posted May 26, 2009 I checked the def and it looked like I missed it. There is candle base followed by lit candle base which inherits from it. I may have read it as one def and only added to the lit. I've now changed it. Can you confirm it was when the candle was NOT lit Ishtvan? Quote Link to post Share on other sites
Tels 279 Posted May 27, 2009 Report Share Posted May 27, 2009 I checked the def and it looked like I missed it. There is candle base followed by lit candle base which inherits from it. I may have read it as one def and only added to the lit. I've now changed it. Can you confirm it was when the candle was NOT lit Ishtvan? The "unlit" candle base is only used for candles that are "unlit at map start", but then it is always used. E.g: * unlit at map start => inherit from unlit base* lit at map start => inherit from lit base The state of the candle after map start doesn't have to do anything with it Quote "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950) "Remember: If the game lets you do it, it's not cheating." -- Xarax Link to post Share on other sites
Fidcal 175 Posted May 27, 2009 Author Report Share Posted May 27, 2009 I think we are agreeing but I'm not sure. Quote Link to post Share on other sites
Ishtvan 17 Posted May 28, 2009 Report Share Posted May 28, 2009 I think it actually started out lit. I remember pinching it out. Quote Link to post Share on other sites
Fidcal 175 Posted June 23, 2009 Author Report Share Posted June 23, 2009 [from pandora thread]-Collision sound on the book moveable used here is very loud to AI (slight bumps to it alert them a lot).-Chairs and candles were also too loud to AI. Slightly bump the chair walking past, or rock it a bit by bumping a candle into it? That's a highest level alert. Bumping things - are these alerts handled the same way as dropping? Quote Link to post Share on other sites
greebo 85 Posted June 23, 2009 Report Share Posted June 23, 2009 The collision sound itself will cause the alert, so yes, it's handled the same. Maybe pushing things will trigger many sounds in a row. Quote Link to post Share on other sites
Fidcal 175 Posted June 23, 2009 Author Report Share Posted June 23, 2009 OK, looking at the map there are two moveable readables... "classname" "atdm:moveable_book_red1_small""classname" "atdm:moveable_bookt1" Neither of these has the spr_object spawnargs. Either I missed them or they are new since I did this work. I see others like the scroll in that def file where I had already added the spr_object. Anyway, I'm just relieved it doesn't mean the method we used isn't robust! Well, this doesn't mean it's not robust anyway but you know what I mean. I'll fix these. It did occur to me when I first did this, it relies on people when they make new moveables to include these spawnargs. Many of them have to go on the actual entity def and can't inherit whereas others do so anyone might not necessarily see or know about these. Maybe that's true about all spawnargs though. I'll fix these ... OK done, untested though. Quote Link to post Share on other sites
Springheel 4668 Posted June 23, 2009 Report Share Posted June 23, 2009 Yes, it's quite possible I've made movables and not done this, as I haven't really followed the whole discussion (those two books are not new, however, they're some of the oldest entities). Quote TDM Missions: A Score to Settle * A Reputation to Uphold * A New Job * A Matter of Hours Video Series: Springheel's Modules * Speedbuild Challenge * New Mappers Workshop * Building Traps Link to post Share on other sites
Fidcal 175 Posted June 23, 2009 Author Report Share Posted June 23, 2009 They were certainly at the top of the page but I don't know how I could have missed them. I faintly remember judging what group to put a book in - yet they are the only two moveable books. - No there's not. I just looked and I missed two others. Now I'm thinking, are these moveable in the sense that they go in the inventory to read as against static books? Maybe that's what I thought at the time. I dismissed them as readables, ie, mobile in the inventory, but not actually manoeuvrable. But it only seems that way because normally you frob a book and if it goes in the inventory you usually keep it and read it. But I think there are books that are not readable but just moveable. I see we have moveable readables and readables mobile. I'd better check them all. Quote Link to post Share on other sites
Springheel 4668 Posted June 23, 2009 Report Share Posted June 23, 2009 Now I'm thinking, are these moveable in the sense that they go in the inventory to read as against static books? Even if it's something that you frob to go in inventory, the player could still drop it again, or knock it over. Quote TDM Missions: A Score to Settle * A Reputation to Uphold * A New Job * A Matter of Hours Video Series: Springheel's Modules * Speedbuild Challenge * New Mappers Workshop * Building Traps Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.