Dragofer
-
Posts
2682 -
Joined
-
Last visited
-
Days Won
161
Posts posted by Dragofer
-
-
On 7/15/2022 at 8:26 AM, wesp5 said:
Speaking of which, would it be possible to display the long descriptions from the shop menu when we highlight a player tool on the big inventory screen? This way players could always take a look to remember what tool does what.
Yeah, try looking at how popup tooltips were done for main menu settings. Shop item descriptions are found after #str_02256 in strings/english.lang
canBeBlownOut seems to exist to stop flames from being extinguished by fire arrow blasts.
-
Yeah, I mentioned door handling position entities for this a little earlier on.
-
44 minutes ago, wesp5 said:
Thanks, I think I found the right line now :)! Also while testing this in the training mission I added a flint and all the other common tools there. Dragofer, if you plan to update the mission in the core game because of the chest typo, it might make sense to use my updated version. I can send it to you!
Thanks for the offer, but you would also need explanations and training scenarios for these tools, just like for the other mechanics. You didn't mention doing that, so I assume that you just added the entities to the map.
Your code example is from the LightsToggle function, but what was meant is the LightsOn function, since this is what gets called by a fire stim. I suppose that's the function you added the line to now.
-
1 hour ago, wesp5 said:
I did add a line to ignition functions, but this only works on lamps that can be turned off and on, so it's not really needed as I will keep them frobable anyway. Normal oil lamps need a fire stim to be relit though and I haven't dared yet to change anything there because the stim code looks even more difficult than the normal one ;)! It's in tdm_light_holders.script, no?
When an oilflame is exposed to a fire stim it calls a script function "response_ignite" of its light_ext scriptobject, which in turn calls the function "LightsOn" of the tdm_light_holder scriptobject on any light holder it's attached to. That's where you would add the line setFrobable(1) to make them frobable again.
-
9 minutes ago, wesp5 said:
I already did that and it works fine, only you can't extinguish the lamp if you ignite it again. This will probably happen very rare if ever so it would be a good enough solution, but then having the lamps highlight up on frob doesn't really disturb me anyway! For a real solution we would need to enable frobing again after stim_fire and I have the same problem like snatcher here, because unless I can differentiate fire sources, fireplaces and torches will suddenly become frobable too...
Did you also add a line to the ignition function? It sounds like you only modify frobability with extinguishing.
For letting this apply only to small exposed oil flames you can check whether the light's model spawnarg is "light_oilflame.prt".
-
3 hours ago, wesp5 said:
So is there a way to hide the frob highlight if a oil-lamp is unlit or even make it not frobable then? Also I can't remember a secret switch being triggered by a oil-lamp...
You can add a line to the tdm_lightholder script's extinguish/relight functions to disable or enable frobability.
You can also check whether the lamp has the "frobable" "1" spawnarg set. This indicates the mapper wants the player to frob the oil light, i.e. for a secret, so you should do nothing in that case.
-
All flames are setup to be extinguished when they come into contact with water stims (steam is something different than stim). You can't give something a water stim that should only extinguish some flames.
-
There'd imo be some value in maintaining the AIUse setting of the door, since in my view it should be suspicious to an AI if they suddenly see a secret door ajar. It'd also permit them to escape if they're lured into the secret compartment and the player then shuts the door on them. I believe door handling position entities either side of the door give that kind of control.
The AAS obstacle entity is probably not necessary if going the AIUse route since the code already recognises door spawnclasses and generates dynamic monsterclip around them. AIUse is mostly for the benefit of the AI scripts and some code functions, if Im not mistaken.
-
I think door handling position entities give you some more control over how and from which side AIs can interact with a door. But it is a tricky scenario.
-
Well it's objectively untrue that mappers have no plan or design for their stealth gameplay and tools. If players think a mapper hasn't done a good job they're free to provide feedback or change it for themselves. However, it's not the task of the dev team to overwrite mappers' intentions out of a belief that this would improve the level design.
-
1 hour ago, Obsttorte said:
If there is something almost all missions have in common is that there is no balancing in regards to the amount of tools given. The typical answers I got when asking mission authors on that matter is "it might be useful/needed". At the same time, the majority of the people on this forum consider ghosting more or less the way to play. So any discussion about tools is more or less pointless.
This is something of a bold assumption. Maybe some authors aren't very good at balancing, but I believe all mappers I'm regularly in contact with put significant thought into how stealth gameplay and tool availability is balanced in their missions. A common idea is wanting to allow for various playstyles and ways of solving a situation, not just ghosting. Making all oil lamps hand-extinguishable would indeed raise the likelihood of players ending the mission with 10+ water arrows.
-
FM authors have balanced their maps and water arrow quantities around these lamps not being hand-extinguishable since TDM's beginnings. It'd be like lowering the light radius of all lights - the gameplay would change in a way not intended by the authors, even if we might think it would make them more realistic. I think it's extremely unlikely someone would come and rebalance the gameplay of all 100+ maps to accommodate for such a tweak.
Also, we now have a whole set of proper oil lamps with glass and switches that can be switched on or off.
-
1 hour ago, Obsttorte said:
Making an entity unfrobable that has a frob peer to other entities will make the latter unfrobable, too.
Hm, I can't say I've run into that problem when I simply disabled frobability for the chest body in my original script. Wesp5 seems to have played with it for a while until he ran into a special kind of container where the body had to be frobbed in order to cause the door to open. Maybe such cases can be identified by checking for which entity has lockpicking spawnargs.
-
2 hours ago, snatcher said:
Right
I can't figure out anything. I am unable to modify any aspect (size, alpha, shader...) of the object currently highlighted.
You could try changing shaderParm11,that's what frob highlight stages use
-
- Popular Post
- Popular Post
The time has come to release the first large ship asset with a fully mapped exterior and interior for TDM: the merchantman, as first seen in Perilous Refuge as well as a decorative scale model in various other FMs:
QuoteThis is a large trading ship, comparable in size to a galleon, based on the colonial traders (indiamen) which dealt in the lucrative trade of exotic goods, required only a small crew and were more than capable of defending their cargo.
Designed to be fully reusable, it comes as a set of modular prefabs that can be assembled in less than a minute in any map. It features 3 internal decks including a tract of cabins, a spacious multi-deck cargo hold and officers' accommodation befitting their status. Both moored and sailing variants of the rigging are available, opening up the possibility of making missions on the high seas. The internal partitioning can be rearranged by mappers using the accompanying set of modules, and example furnishing prefabs are available for each deck. Pier modules should make it easy for the ship to dock anywhere. The new deck texture is courtesy of peter_spy.
Mappers are more than welcome to use this ship (or the other, smaller fully mapped ships, the brig and the yacht), even just to try it out in their maps. That'd quite appreciated before it's eventually added to core assets.
Download
-
5
-
1
-
- Popular Post
- Popular Post
4 hours ago, Oktokolo said:Respect for achieving that ignore count though. I hadn't the impression that this community is easy on the trigger. But i also don't know how many ignore me...
It's like in real life. If you make a point of being condescending to those around you because you aren't "here to get along with anyone" and constantly getting in their faces about the slightest of things, they won't want anything to do with you.
-
5
-
1 hour ago, Oktokolo said:
Nort seems to haveÂ
I don't see memes there. Looks like Nort has a negative diplomacy skill and likes finding and fixing bugs. Some fixes actually got approved by a developer (and yes, that the console is full of errors and warnings by default isn't really nice when you try to debug your own errors). So i see nothing banworthy in my casual scrolldown of "Everything posted by Nort".
Wonder, what's actually going on here.
The guy's ended up on at least 10 ignore lists and in his final days was posting advice on how to avoid getting raped. It was high time for him to go.
-
1
-
-
Newbie comes on the scene imagining he knows everything best, insults everyone else as lazy/incompetent/drunk etc. every time he criticises something, spams nonsense or offensive status updates at a great pace and takes on a victim role when he gets called out and anti-trolled by others. Now he's banned and left behind some memes for this community as his legacy.
-
1
-
1
-
-
I got quite good results manually reordering render order inside my lighthouse. Lamp beam > transparent windows > foggy skybox. Of course it helps that you can't really look into the lighthouse top from outside up close.
-
Here's the camgoyle sentient turret that I originally made for the FM Written in Stone. It's based on the new security camera entity and augmented with scripting to allow it to fire magical projectiles at the enemies it detects. People are more than welcome to use it and to convert it into something else, such as a mechanical turret.
Features
- Predicts the target's position based on its current velocity to fire more accurately. This can be disabled, i.e. on certain difficulties. Also traces towards the target before shooting to ensure the projectile has an unobstructed flight path.
- Uses a custom, purplish magical projectile with new sfx as a new alternative to fireballs.
- Comes with a scripted power source pedestal that can be placed anywhere in the map and be disabled by a special inventoryable staff, "atdm:mage_hand_staff". See prefabs/ai/machines for a prefab.
- Can be destroyed by fire arrows, causing it to break apart into pieces that fly about the room. Smoke will billow forth from the husk that still remains in place.
- The spotlight is set to be volumetric. You can use your own spotlight with the "spotlight_custom" spawnarg (see also: Security Camera wiki for other common functionality).
- By default the camgoyle is on the undead team, #8, so it'll only shoot at living targets such as the player.
-
3
-
1
-
3 hours ago, Marbrien said:
The link in the first post no longer works, and I don't see v1.1 in the Downloadable Missions list ingame. The Mission Details page of the TDM site appears to have v1 only. Is the new version of the mission now completely unavailable?
OK, I've just done a download from the Mission Details page. It does have links to v1.1, it's just that it describes it as being version 1.Â
Can confirm the mission downloader offers the correct version with the fix, just seems that there's a discrepancy between the version numbers stored in the mission downloader and in the FM files.
-
I actually think an own topic would be appropriate if you intend to start a discussion of a specific mechanic. We've only just moved a discussion of gear availability that started in the Noble Affairs FM thread into its own thread.
-
1
-
-
31 minutes ago, geegee said:
Sorry for offending y'all with my POS attempt at an FM.
geegee has left the building.
Something to realise is that when you put out any kind of artistic work, you'll inevitably receive both positive and negative feedback. Every mapper that's been at it for a while will have received copious amounts of both, and some of the criticism will have felt totally unjustified to them. At the end it's just an opinion, and if they had let the criticism discourage them we wouldn't have any mappers left. It's the satisfaction of expressing yourself artistically (as well as seeing people enjoy your work, as is the case here) that makes it all worth it.
-
2
-
-
14 minutes ago, Obsttorte said:
That would be exactly the behaviour that was in place to begin with, and which we want to fix. The AI should NOT go to agitated searching everytime it spots a missing item.
In my view the problem is that the code first checks the spawnarg, then sets alert level to agitated searching, so you always get agitated searching.
If this order were switched around you'd have agitated searching as the default, which the spawnarg would override if it's been set by the mapper.
17 minutes ago, Obsttorte said:I would not want to make any changes to the absence marker related code. It is used by default and there may be a reason why the code is only executed in that scenario. So unless someone can come up with a scenario why it should be different...
Yeah, I don't really see how other entities than absence markers would emit this stim. However, the old code always modified the alert level regardless of whether it's from an absence marker, and it seems to have worked alright these past years (apart from the spawnarg not working). The proposed revision changes this to only occur if that condition is met, which I don't know what consequences it'll have.
So, what are you working on right now?
in TDM Editors Guild
Posted
Had best bring a knife to carve a path through that fog.