Search the Community

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

Sorry for the necrobump. Unfortunately, the original poster of this thread is no longer active. I want to ask whether keypad assets like this are made purely using DR or if other 3D modeling applications are also needed? I'm just asking out of curiosity. Maybe in the future, I want to learn how to create and model objects with screens like this but without the functionality of the keypad above in DarkRadiant. I'm just messing around, I don't intend to create fan missions. And if such a screen is too modern (even a CRT), is an overhead projector (https://www.avplanners.com/blog/history-with-a-local-av-company-the-overhead-projector) also too modern, even if it's given a steampunk touch?Because I remember OHPs were widely used in schools or universities 3-4 decades ago Or even if the CDC 6600 below is polished with a steampunk design (and it seems like it doesn't use vacuum tubes like the Ferranti Mercury) , would it still not fit in?

Thank you. Interesting. All the more interesting for me, as I've been a fan of Frictional Games (and their engine) since the Penumbra Tech Demo and all the first few Penumbra games. I remember when the Amnesia HLP2 engine and the editor for Amnesia missions built in that engine were first showcased to the fans, back in late 2009, early 2010, several months before the game debuted in early autumn 2010. One of the FG fans even commented "Drooling...". Penumbra wasn't much moddable, as there was no level editor and you had to build everything by hand in Maya or any other appropriate 3D modelling software. There was no HLP2 level editor equivalent, no Dark Radiant equivalent, in HLP1, it had do be done by hand. Now that it's been open-source (IIRC) for over a decade, I wouldn't be surprised if some enterprising indie dev tried to make a rudimentary level editor for it. The HLP2 version of the engine is actually quite similar to the TDM and Dark Radiant approach, though it does even allow for a "non-airtight" approach (i.e. you don't have to fully seal a space with brushes, and even a very rudimentary level will work in the HLP2 engine). Some old FG development videos, back when the more user-tools-flexible HPL2 was brand new and Amnesia still had months to go before it was published: - HPL2 level editor timelapse (this is the video that was commented on with "Drooling..." by that one eager fellow FG old-timer fan) - use of decals in the HPL2 level editor - HPL2 material editor - HLP2 model editor - HPL2 particle editor Setting up a custom story level (rather than an expaded total conversion) in HPL2, using the base game assets, with the help of the level editor. An HPL2 mapper at work, showcasing the phases of building a level in the engine, mainly via the level editor, plus some of the other aforementioned utilities accessible from the editor: 1, 2, 3, 4

Chaps can you move this conversation to a different thread, as its not related to the FM.

A recent thread of discussion has cropped up in the TDM Discord channel and a couple forum threads ( this comment and the general discussion after it came to mind) about the usability and efficacy of Flashbombs in TDM. To wit, most people seem to think they're kinda bad because they're just a stun, which still requires you to hide in a very narrow time frame and then wait for the AI to cool off after use. One of the big upsides of flashbombs in TG/T2 was that, if you had alerted human enemies chasing you, you could drop a flashbomb and then turn around and blackjack them to non-lethally remove them from play. It was an inventory-limited opportunity to recover from failure and continue playing the game, as opposed to just reloading a save. This is a fun and proactive interaction, and I propose that we add it to TDM. Specifically, I think this can be accomplished with minimal code. After a read through the public TDM git repository, I think the most appropriate change would be to adjust the condition here: https://github.com/stgatilov/darkmod_src/blob/ac0a286561630eefee1cbb44d09d77128cd3d8e7/game/ai/AI.cpp#L11892 to read as follows: if ((GetMoveType() == MOVETYPE_SLEEP || // grayman #3951 GetMind()->GetState()->GetStr() == "Blinded") && // proposed - maybe there's a better way to write this condition like checking the type or something? ((minDotVert != 1.0f) && (minDotHoriz != 1.0f))) // cos(DEG2RAD(0.0f)) indicates elite faceguard helmet { Currently, this check does not pass for blinded AIs and they move to the if-else branch at L11903, and since they're very alert because they were actively chasing the player, they cannot be blackjacked. This change should give a flashbomb-blinded AI the same knockout vulnerability angle as a sleeping AI. Helmeted human AIs (and undead/magical AIs because they can't enter that particular mind state) retain their blackjack immunity, and everyone else can be clunked in the face as a reward to the player for spending a limited resource, not flashing themselves, and having the quick thinking to turn around and draw the blackjack. The blinded mind state lasts for about 8 seconds (I forget where I found that but its a hardcoded magic number in a Damage() function somewhere), which feels a bit short but about right, and then when the state changes the player's window of opportunity is lost. My brain kinda glazed over when I looked at the SVN checkout+compilation.txt instructions, but if I can help test or debug this with a little hand holding I'd be happy to do so.

The electronic keypad is something I've wanted for a long time, along with laser tripped alarms which are next on my TODO list. I'm happy to announce they're a feature I just finished as part of a futuristic campaign I began working on! The version included here is extracted into an individual pk4 for other mappers to use. I may improve mine over time like using a GUI for the screen, for now this is a simple but finished version which does exactly everything intended. It consists of the custom script and def, models created and exported from DR reusing existing sounds and textures (only text labels had to be created), as well as prefabs for model sources and quickly placing a keypad on your map (broken or unpowered versions included). The device is operated using 12 buttons forming a numeric keypad inspired by old mobile phones, stand close look at each key and frob to input: Give your keypad a "text" spawnarg to set a password (multiple codes supported), entities targeted via "trigger_on_success" will execute when the correct code was typed, you may also set "trigger_on_fail" spawnargs to trigger targets when a bad code was written. Existing input can be cancelled with * and must be confirmed using the # key at the end, once unlocked pressing any key will re-trigger targets and lock the device back up. One aspect I'm unhappy with: I couldn't find a way for the script to directly access the entity triggering it. Because of this I had to define an additional "atdm:target_callobjectfunction" targeted by buttons which itself targets the keypad. This is only an annoyance for sanity's sake as I hoped I'd only need the keypad entity and individual buttons, yet there's also a little yellow cube sticking around which every button has to go through. Let me know if you're aware of a way to work around this; I know the script can use sys.onSignal(SIG_TRIGGER, self, "foo::bar") to run a function when triggered, but there doesn't seem to be a way to access the entity doing the triggering which is required to know which button was pressed and get its symbol. Here's the initial version with a few screenshots of how it looks and works. Feel free to use them in your FM's and share the result here! I'd love to see missions where you need to find codes in readables and remember them to access places, even having to piece them together from different sources... remember you can also use short passwords which are typed like an SMS hence the letters on the keys, for example "abe" would be "11122" (a = 1, b = 11, e = 22) 0 acts as space though I wouldn't write long sentences as they can be annoying to type in. electronic_keypad_v1.0.pk4

This looks really cool, amazing work in my opinion: https://www.moddb.com/mods/thieves-guild I'm surprised that it flew completely under the radar. I hadn't heard about it until today - just by coincidence I saw it on the TTLG Discord. From the footage available I would say, a Thief game similar to Deadly Shadows created with the original Unreal Engine. Apparently, the base game is available on GOG, however, I cannot find it there. Plus, according to ProtonDB not fully functional on Linux systems. EDIT: Here is a game play trailer from 8+ years ago (the development of the game took quite some time), there seem to be RPG elements as well: Edit 2: This seems to be a project our forum member @Jetrellis heavily involved in. Congratulations on the release! You have been working 10+ years on this? Truly a superhuman effort!

Now that Cryengine is basically free to use for community projects, and has proven itself to be ideal for large open worlds with stealth gameplay like Kingdom Come Deliverance, is there anything stopping anyone from porting TDM over with support for existing fan missions? I mean legally speaking of course, as I'm sure it would be a lot of work, but there seem to be fewer barriers than ever before. It's incredible what people have done with an engine that was built to accommodate tiny corridors on ancient hardware, but imagine an engine purpose built to render large open spaces... No more compromised visions when mapping, no more endless optimization to fit a square peg through a circular hole... And if the mission files were to be compatible with the new engine, people could just keep on mapping in DR as if nothing even changed. Cryengine Community Edition https://engine.pterosoftstudio.com/

Glad I came to the forums to check out more details about this mission after playing. I was a little confused by a Bikerdude FM only taking 10mins to run through haha. Knowing it's a tech/build demo means I'm not going to spend the next hour or so looping through it trying to figure out if I missed a secret Krampus area or encounter xD.

I played this mission and it was such an amazing experience to explore and complete this. Great surprises with the magical entry into the bag. I just wanted to @Goldwell and @kingsal if the sewers had some lore as well, I saw a dead body and a spider guarded room which I could not enter because of the spiders. I think the man came from the room above the sewers but I would like to hear from you guys. Anyways, such a great and elegant mission this was. Thanks for your work

Yeah, Thanks to everybody including @Amadeus and @Dragofer for their work in making this huge mission. Love from India

Don't forget all the work my co-authors did. While I did a lot of mapping, the story, scripting and polish would not have been possible without @Amadeus and @Dragofer

Thank you so much for your help! Also thank you for your work in this mission, amazing city you have created.

The engine has a rather cool feature of rendering perfect planar reflections using mirrorRenderMap. But it is well known that this feature can be costly, because it requires the whole world (in the worst case) to be rendered twice. There has been a request to support lower-resolution rendering to reduce GPU load (5485). This feature is added in 2.14 with new material parameter mirrorResolutionFactor. For example, in order to make mirrored rendering with 1/3 x 1/3 of native resolution, you can write the following in your material: mirrorRenderMap mirrorResolutionFactor 0.333 Of course, this has a downside of making the mirrored view more blurred. But I've seen materials which explicitly blur the rendered view, distort it, or blend with other effects, etc. In these cases the lack of crispness of the reflections is not that ugly. The second change is related to the similar feature remoteRenderMap. There has been a way to specify resolution for this feature already, but it has some weird behavior and thus is now deprecated. If you have a square screen and want it to be rendered at 512 x 512 pixels, then you can write: remoteRenderMap remoteResolution 512 512 A slightly more convoluted way is to specify three numbers: remoteRenderMap remoteResolution 1024 1024 10.0 It means: render 10.0 pixels per 1 doom unit, but limit resolution by 1024 x 1024. So if the screen is of size 64 x 64 doom units, then it will be rendered at resolution 640 x 640, if it has size 16 x 16 units, then it will be rendered at resolution 160 x 160, but if it is stretched over 200 x 200 screen, then it will be rendered at resolution 1024 x 1024 because of the cap. There is also another limit for the remote screen resolution, which is applied at the end: see below. Finally, TDM 2.14 includes a few generic optimizations for these two features: Remote screen resolution is now capped by its size on the screen. So if a remote normally has 512 x 512 resolution but the player looks at it from far enough and it occupies only 100 x 100 pixels on the screen, then the rendering resolution is lowered to 128 x 128. This is controlled by cvar r_remoteLimitResolutionByScreenSize. Mirrored view image was previously copied at fullscreen resolution. Now the copy is limited to bounding rectangle/scissor, which means wasting less GPU bandwidth for mirrored surfaces which cover a small portion of the screen. Remember however, that all the resolution/scissor tweaks can only reduce GPU load. They don't simplify the work of the renderer frontend. So if the game is CPU-limited, none of this helps.

Did this in fact actually work? From my experience using the .pk4 only works if you are developing the FM (i.e. the FM is in extracted format). If you then pack it all up into a .pk4 (with a nested .pk4 say with someone else's asset pack), then it doesn't work. I asked the dev team about this and I think stgatilov confirmed it's not supported.

Thank you for doing all this research, it's very interesting. I got a response from the person that I reached out to and this is what he found: Couldn't get the mod to work on Rune Classic version 1.10 However, Rune Gold worked with the mod. This is what he did: installed setup_rune_gold_2.0.0.5, it includes version 1.07, then updated to version 1.08 (rhov108upd_full) and installed the mod. I realize none of this is optimal, I am in the process of eliminating the mod's reliance to patch 1.08

Hi, I've played Splinter Cell trilogy last year because I joined that 52 games challenge. Furost_nova's profile | Backloggd I made a site full of level design articles in hopes of breaking into the industry. I began with google sites, but now I've migrated to mediawiki. I still want something better than mediawiki, but for now it was the easiest solution to publish text and have more freedom to format than google sites. My plan is to work in the industry. My long term goal is to make that site a professional resource and refactor everything. But that won't come until after some years of professional experience. For now I've stopped adding more articles because it's a futile endeavor. The reason is pretty much this article of mine: https://www.henry-ym.org/index.php/Environment_Art_x_Level_design_x_Writing._Ego_made_me_blind https://www.henry-ym.org I made this: https://www.moddb.com/members/frost-nova/addons I have made maps for Open Arena before. If you ever seen maps called Lego + something. Plus, a colorful map with too many colors at the same time, circular arena style, called RGB. I made it too. I deleted them from moddb because I was going to rename to remove the "lego" trademark, but I guess I forgot to upload them.

There is a new system in 2.14 for generating smoke particles (6309). In general, it reuses more common code from the other ways to generate particles (particle models and particle deform) and its behavior is more aligned with those other ways. Here are some of the differences compared to the old system that I know of. 1) The new system is FPS-independent. If I'm not mistaken, the old one I think generates 5x particles on 300 FPS and 25% of the particles on 15 FPS. 2) Two systems have a bit different spawning time. Particle stages normally work on periods of length (particleLife + deadTime). In the old system, particles spawn uniformly during the first (bunching * (particleLife + deadTime)) time, while in the new system they spawn during the first (bunching * particleLife) time, same as in particle models and particle deforms. 3) The old system does not respect cycling settings in the particle decl. It plays only one period of every particle stage and stops. However, func_smoke specifically has a high-level logic: it restarts itself if all the particles have been generated. This looks like infinite looping, but all the particle stages have the same period in this case (the maximum one). The new system can respect "cycles" parameter from .prt file if you set spawnarg "use_cycles" = "1" on func_smoke entity. So if your .prt file has e.g. 3 stages with different period and "cycles" = "0", then each stages will cycle infinitely with its own period. And if your .prt has "cycles" "10", then func_smoke will play 10 periods and stop. Note that without "use_cycles" spawnarg both systems just play one period of all particle stages. This is a very recent change. The new system is enabled by default, but it is controlled by cvar g_newSmokeParticles. If we discover serious problems with it during beta, we'll have to flip the cvar...

Why would it not work with the Classic version? I think more people have access to that.

You can ask people to test your mission here, but the beta tresting should be in this other section: https://forums.thedarkmod.com/index.php?/forum/59-tdm-mission-beta-testing/ Read also: I think it's so that there are no spoilers in view for new regular players.

I think we should create a thread where you can put requests and suggestions for Orbweaver. This thread should be NOT a discussion thread. If you want to discuss a proposal, create a specific thread for it. I want it to be only for collecting proposals, so we have an overview of what people might want to have. I guess this might also help Orb to decide what he should focus on once he gets productive. BTW: I really appreciate your effort, because we can really use this. So my personal wishlist proposal is that I would like to see a group handler. Similar like in Blender, where you can select several objects and put it in a group. When you select one or more of these groups, the objects are visible. If the group is not selected, it's invisible. In Blender and other 3D apps this is called layers (forgot the name before so I had to look it up).

I'm happy to announce the release of my third FM: Year of the Rat. This is my first city hub map, focused primarily on story characters and environment. It's my most complex project to date, taking its fair share of effort to make which was a good learning experience. As an experiment I opted to use no scripts and rely solely on the default entities, as well as no custom assets apart from the map and splash screen hence the small pk4. It features a few special elements, such as factions that are hostile only when the player commits crime or a decoder lockpick used to open electronic doors. The beta testing thread can be found here, thank you everyone who helped find the most obvious problems. You play as a famous thief nicknamed Black Jack: A man who's pulled many crazy jobs in his life, only to be hired for an absurd and insulting task by an anonymous employer. The objective is pretty straightforward: Be kind to the mice and feed them some cheese! Your silly quest takes you to the Lantern Light district during the Lunar New Year celebration, a place where gangs and corrupt nobles do their dirty deeds together. What ulterior motives and unexpected twists could your adventure entail? While the most obvious problems were patched during beta testing, some issues can't be easily resolved due to the complexity of the entity setup and objectives, meaning you may encounter a few inconsistencies. Most notably surrounding AI, which may float above chairs and not react to alerts or oppositely send the whole map into a panic: This is mostly due to how the engine handles AI and alarms. The map is small since I wanted to add more detail without having to work on large areas, as such some places can feel cramped while the skybox may be visible up close. I'll be busy so further updates are unlikely unless I decide to add new content later... you're welcome to report any issues you encounter, but keep in mind that if something wasn't fixed it's likely known but difficult to address or due to engine functionality. Spoilers for objectives and secrets as follows: Download 1.2: Google Drive, Mega. Screenshots with minor spoilers for the various areas:

I've read about this before here on the forums, even when the contest had just recently concluded, but reading about it in greater detail years later is certainly interesting. Thank you. It's a pity that it was mostly the marketing people who were involved on the Square Enix side, as I had the impression it was also the devs at EM that had played Requiem and all the other submitted missions and really liked them. I suppose it was as well, but the TDM team mostly heard from the marketing people. Yes, I wanted to note that as well. I even remember how the people over here in the TDM forums were sort of laughing at the fact that the results of the contest were favourable to TDM and had, in a sense, "proven" TDM as a worthy freeware successor to the Thief IP, with all the modding and mapping tools at one's disposal and so on, whereas Thief 4 or Thi4f or whatever Square Enix were calling it at that point, offered no such possibilities. The entire contest, while no doubt declared in good will and something I actually appreciated seeing, was such a self-own for Square Enix, ultimately to the detriment of them trying to bring back and market the reboot of an older IP. Even if Thief 2014 was a terrific reboot (which I doubt it would ever be), it would still have been hampered by people learning about modding being impossible, and looking to the trilogy and to TDM instead, to make new Thief-style stealth gaming content. Still, I appreciate they recognized the quality's of Moonbo's Requiem FM. Given many retrospectives I've seen over the years, gradually, on the 2014 Thief reboot attempt, one thing a surprising amount of them shared was noting how the game didn't feel cohesive in concept and execution, at any point. Not only not to the same level as the Thief trilogy, but also not even at the level when you consider it as an individual game, a new game on its own. Errant Signal, who's not some deep Thief fan, replayed the older games and played the reboot back when it came out, and made this exact observation already a decade ago. The reboot was just all over the place, in every department, felt clearly unfinished or rushed, and the most interesting story would be the behind the scenes at Eidos Montreal, on how mismanaged the entire project became over the course of several years. I think it's telling that, while even heavily discounted on GOG.com, Thief 2014 hasn't been selling well there, nor attracting much interest, whereas the original trilogy sells for figurative (and sometimes literal) cents on that same site - you can buy the whole trilogy for a smaller price than the reboot, which is kind of hilarious - and continues to have great sales and is considered one of the all-time bestsellers. Same here. I concur with demagogue that the actual Eidos Montreal devs behind Thief 2014, at least those who cared enough to make it at least somewhat presentable and playable - even if the actual game directors never got their act together and never decided on a consistent design apporach - those would have been much more interesting to be in contact with, even regarding the fan mission contest. The sad truth of the matter is that all too many big publishers these days, especially those formed through larger mergers, like the Eidos buyout by Square Enix, are often marketing-first, interest in developers, and veteran players and new players alike, second. I still remember the sheer amount of money spent on pointless external marketing for Thief 2014, all the while that reboot attempt never really coalesced into anything that felt consistent (rather than throwing everything at the wall, in a panic, hoping something would stick), and was also plagued by all manner of technical issues. Just an overall embarassment, and I'm not surprised that even very lenient-leaning game retrospectives of that reboot attempt. The fact that the Thief IP has been sold away to Nordic Games and Embracer in more recent years, with Square Enix no longer caring about it and other older game IPs, also says a lot. Given the Embracer Group's own woes and bad decisions, I'm not sure any new development team will ever attempt another installment of Thief, even if it was a second reboot attempt.

I can give it a spin. Like @datiswous says though it's best to create a thread in the beta test forum so we can provide feedback. Discord is another option if you use that. Or do both. EDIT: I've just sent you a PM instead.