Obsttorte

Looks promising. I agree with peter that beeing able to configure the light used in the preview would be useful. I am not sure whether several lights are necessary, but beeing able to set the light color and texture would be useful as the lights often used in fms (torches, candles etc...) differs heavely from a plain white light. Thanks for the effort.

I agree with @VanishedOnethat making cameras vulnerable to water arrows should not be the default behaviour. If a mapper really wants the player to be able to temporally "disable" the camera, he could simple place a torch where the player uses the water arrow on and that gets relit by ai or an electric light and a light switch. Cameras are already relative limited in a sense that they can't move and are often restricted in their fov. So their should be some advantage compared to guards that outweight that. Otherwise mappers may only use those things due to aesthethics, which would be a waste of the work invested imho.

Youtube suggested me this channel a while ago. Really cool stuff the dude is doing. The annotations are in german, but he only writes what he currently does or what material he is using. For me watching him doing what he is doing and the final result is much more interesting, though.

Since when is money needed to mod a game. And since when are players known for beeing social. I always thought the whole point of having a hobby behind a computer screen is to stay away from society.

That is actually something that has been discussed. The problem is that working with guis is "not nice" at least.

They are recognizable. As Nico stated they follow a specific naming scheme. @Nico A.No, your suggestions would not solve the issue. It is not only about loot values, but also their respective distribution in the mission and about the values of the items to be bought in the shop and their usefulness for the next mission. This is something that needs to be carefully calculated. I did this on my first mission and it took more than five minutes. Most mappers however do not do this. They simple follow the paradigm of "a bit of loot here and there for the player to pick up", especially as they didn't expect that the loot could serve a different purpose except to be found. Bundling missions to campaign requires an update of each mission in that campaign. You will not be able to bypass this if you want a result that benefits from the missions beeing arranged as a campaign. Additionally you basically suggest providing the mission twice on our servers and in the in game downloader. That could be confusing. DMP and CMP as you call them would need to be distinguishable in the downloader, so this would need to be tweaked accordingly. And you would have to repack the missions into campaigns and rebalance the loot. This is not possible without the authors permission. And any issue with the "campaign" would probably be first reported to the mission author, although their are not responsible for that stuff. Still they would have to deal with that, but will only do so if it has any benefit for their work. And currently I see none. Maybe you should ask the authors who created a series of missions what they think about your proposal before continuing your work, as otherwise you may end up with no result and a lot of time wasted.

Just out of curiousity: What if a mapper doesn't want this feature for his missions? Maybe he doesn't like the idea of loot etc. getting carried over from one to another mission if said missions weren't designed with that in mind or vice versa designed with a fixed set of equipment available. And how do you handle missions without a job to buy equipment? Your suggestions basically change the missions, and the general approach has always been to avoid changes that do so with already existing fms. So if mappers don't want this or are not available we would basically need a way to disable this feature for those missions. On another note: What is the benefit of all of this? I understand that gathering loot to buy equipment for the upcoming mission can be a great motivator and enhance the gameplay, but only if those missions are designed with that in mind. Just take a look at the amount of loot you can normally acquire in a mission (often several thousands) versus the costs of the equipment (a few bucks). Even without such a difference the amount of loot that can be found and the price of the equipment need to be carefully balanced to gain desired effect, even more if you want equipment to be carried over additionally. One just has to take a look at Deadly Shadows to see how such a simple sounding thing can fail. And this game was designed with that feature in mind. From professional and experienced game designers. P.S.: Old Habits 1 & 2 are no successive missions. The second one is a rebuild of the first one (the naming wasn't my idea). So there should definetely be no carryover from one to another.

This definetely goes into the right direction. Unfortunately, "==" always returns true and "!=" always returns false, no matter the content of the string. Guess I am still doing something wrong. Thanks thus far.

Nevermind, it is not that important. Thanks anyways.

These are all integers except the last expression, which is exactly the syntax I am using and it is not working. The difference for the last instance, though, is that $gui::title is a spawnarg.

Yeah, but that isn't a string but an integer. From what I can see in the source code strings should be doable, too, and somehow I think I even did that in the past. But either I am mistaken or I use the wrong syntax. However, there is no logical reason why a comparision between strings should not be doable.

Does anybody know how to compare strings in guis? Or how to find out whether a string is empty? Somehow I neither get it to work nor can I find anything useful on this in the web or the code. The latter implies that it should work, but it doesn't Frustrating.

@peter_spy I can reproduce your observations. I've taken a look at the code and there is a check for whether a portal skybox needs rendering, so in theory the rendering should be skipped if it is not within the current pvs. Either something is wrong with that code or the statistics console output is wrong or our interpretation of said values. Disabling portalsky via console reduces the view to 4. However, maybe the view count is just the amount of potential views (like reserved viewports) and not those actually rendered. I see whether I can make the skybox a bit more performance hungry to see whether it gets disabled if out of view or not. EDIT: Visportals indeed seem to not have the desired effect, independent from whether the old or new skybox method is used (according to the console description of g_enablePortalSky). Furthermore, I've placed several ai and tons of light in the skybox, so lots of shadows are casted on the floor of the skybox room. This causes the framerate to drop when I look downwards (at the floor, where there is no skybox material, not even behind walls etc...), whereas the performance improves when looking upwards (at the skybox!!!). Although we rarely have stuff placed at the bottom of the skyboxes I think this is unintentional, and the functions for checking whether rendering of the skybox is needed are broken. On the good side: caulk sky still seems to work.

With "behind the visportal" I guess you mean to the right?! I don't know for sure what "views" is counting, though. I would have to repeat my caulk sky test to see whether something has changed ... and I would need another screenshot from the very same scene but with the visportal on the right open, so I can compare the stats. This way I can only guess what's on.

If you are doing it out of respect for him and his work it can't be tasteless. Intentions are what count, not how others perceive it.

Re @peter_spy 1.) is definetely true (as written in my post, maybe I was a bit unclear). 2.) sounds odd. I noticed when working with caulk sky in the past that the sky stopped rendering when there was no visportal textured surface in the currently rendered area (noticeable as the caulked surfaces suddenly turned from skybox to black). There have been adjustments made both to the vp's as to the way portal skies are rendered if I am not mistaken, so maybe something changed along those. Haven't touched DarkRadiand in a while (except for setting up scripts or custom objects, but no real mapping). Re @Frost_Salamander The behaviour of a pendulum is depending on one value only. This could be the swing speed at the lowest point, the altitude of the swing or the largest angle. More then one is not possible. freq and speed as suggested by Dragofer to belong to each other, so specifying one should make the other redudant. I don't know which one gets the higher priority, though. Angle is used to change the swing direction. BTW.: If you want to create a swinging hanging cagelamp or oil lamp binding it to a func_pendulum bound to another func_pendulum swinging into another direction at a different altitude/frequency gives you a nice effect. Just don't use too many of them in a scene as they eat performance. If you want more control over the movement you would need to use a func_mover and script the behaviour. This is only required if you need something very specific.

I agree with what Dragofer posted. The skybox is only rendered when there is at least one surface within the currently rendered areas that has the portal_sky texture on it. This doesn't imply that this surface or the skybox as such is neccessarely visible. I am not sure what older engine version you are refering to, but it was always the case since I started working with the code, so I would assume for about 10 years at least. Actually I assume it was always like that. @Petike the Taffer there are essentially two "easy" ways to keep performance issues low in a scene like you are describing it. Make the courtyard cramped, as non-convex as possible without it starting to look odd. This also makes gameplay more interesting compared to one giant cuboid where everything is observable for the player. Use static skies instead of portal skies. You can also combine both approaches, but I would start with (1). I don't understand what you mean with your transparent room idea. If it is transparent it won't block the player's view and thus not contribute to improving performance.

Yeah, they have an acceleration and deceleration part. The pendulum movement however is calculated from the length of it iirc. So the approach is slightly different.

A pendulum isn't a door, though. The latter moves at constant speed, a pendulum doesn't. You could try "snd_accel", "snd_decel" and "snd_move".

Blessed be thee. I wanted to look up something there a few days ago just to notice that the site isn't available anymore. Good to know there is a backup, as this one has proven to be very useful.

You could try it the other way round. Instead of using a light entity with a model you could use a model with a def_attached light. This way the spawnargs refer to the model used and changes to the light can either be done by using a custom light attached and specifying the spawnargs in the respective def (if you want uniform looking lights) or via set spawnarg on attachment_name. EDIT: There seem to be a spawnarg called noshadows_lit in addition to the noshadows one. I assume that this one may do what you ask for. However, on the models I've checked it is already set to 1. Are you sure the light model is casting a shadow?

That is right, but it will be binary. So the portal is either closed or opened. The issue is that the switch between those two states can be rather abrupt, especially when happening on close distances due to performance limitations, and thus be noticeable to the player. You can see such issues even in AAA titles if you look carefully enough. So the mapper should try to disguise this switches if possible. Another thing is that if the portal opens and the scenery behind the window is compareable bright, it will make said switch pretty obvious either. Hence the idea of an alternative skin that takes this into account. However, the exact setup is dependent on the exact situation. If you combine scripts and proper materials this is doable. It may not yield the same quality as the Q4 portals you've mentioned (never worked with them, so I can't judge on this), but it doesn't have to be perfect either way. The goal is just to make it less obvious to the player that the portal is not translucent on long distances. No issues with that. As said I've done so myself in the past. But as you state yourself you use it in a small area without "any fancy stuff". In larger or generally higher detailed areas (exterior or interior, doesn't matter) this can get problematic, though, and this is were the magic of LOD comes into play.

The fading could be mimiced via proper materials and some script. On large distances you use an opaque window texture with the visportal closed. When close enough so that the visportal is open, you use the translucent version. Switching can be done via skins. The translucent version would need an additional layer that makes it appear like the opaque version and said layer needs to get fade out when approaching the window. Obviously the quality of the result will depend on the textures used. @SeriousToni: Builder Roads features glass windows and my Old Habits rebuild either iirc.

They serve the best cocktails there

You can restrict the frames of an animation to be used in the respective md5anim file. It can be opened in a text editor like notepad++. Remove the frames you don't want and change the framerate to speed it up or slow it down. Getting it to loop well will require some testing, though. I dunno whether there is a working animation editor in TDM, but DarkRadiant comes with an animation viewer at least. Could be useful to get it to loop.