Overriding tdm_weapon_arrow.script

[chakkman]

Well, I disagree. I play this game for the features it offers, not the features some mission author thinks he has to change to his personal favor. And, frankly, some of the more current missions offer too much of that "I think this works better" feature change. For example, the sounds some missions introduce add nothing over the original sounds, but are rather worse in my opinion. 

[Amadeus]

12 minutes ago, Wellingtoncrab said:

Kingsal could make a mission where you crawl around like a baby in moon gravity and I might be right there with you saying it was a bad idea. It'd still be his mission so his choice.

I think you just gave me an idea for the next April Fool's FM

[Amadeus]

1 minute ago, chakkman said:

Well, I disagree. I play this game for the features it offers, not the features some mission author thinks he has to change to his personal favor. And, frankly, some of the more current missions offer too much of that "I think this works better" feature change. For example, the sounds some missions introduce add nothing over the original sounds, but are rather worse in my opinion. 

And it's your right to disagree, and it's your right to critique those FMs. But that doesn't mean authors need to make changes to cater to your whims if they don't want to.

[nbohr1more]

Arrows are a core part of TDM. They should be moved to C++ and have dedicated Cvars for both players and mission authors.

Plan:

1) Implement Arrows in C++ ( evaluate changing some old defaults )

2) Make associated Cvars "non-archived"

3) Mappers add mission.cfg to enforce their customizations

4) Players can alter mission.cfg to their preference

Along the way, reduce some of the performance impact of the weapon script constantly invoking "raise torso" and other nonsense due to using scripts rather than C++

https://bugs.thedarkmod.com/view.php?id=4203

 

[chakkman]

3 hours ago, Amadeus said:

And it's your right to disagree, and it's your right to critique those FMs. But that doesn't mean authors need to make changes to cater to your whims if they don't want to.

I could take your reply much more serious, if you wouldn't call my valid objections "whims". If you don't care about what players think about the decisions you made in your missions (or your "whims"?), then I wonder why you make your missions public at all.

Seriously, I'd recommend to get off your high horse.

Edited May 1 by chakkman

[Amadeus]

1 hour ago, chakkman said:

I could take your reply much more serious, if you wouldn't call my valid objections "whims". If you don't care about what players think about the decisions you made in your missions (or your "whims"?), then I wonder why you make your missions public at all.

Seriously, I'd recommend to get off your high horse.

Alright, you convinced me that this convo is no longer productive. You clearly just wanna be right, so I'm not gonna spend anymore time on this.

EDIT: I cant help myself, I'll end on a more thoughtful note. I care about all the feedback I get from all players, however there is a difference between "caring" and "catering to". Just because one person says they don't like X doesn't mean I'm gonna make a change, especially when other players do like X. I'll always hear out beta testers and players and listen to their feedback, but I am by no means beholden to that feedback

[datiswous]

---

Edited May 1 by datiswous
Sorry I didn't want to continue discussion..

[stgatilov]

Speaking of actions for the missions which only tweak zoom delay.

What would you prefer right now?

1. Mission broken on the latest dev build (as it is now), but working as intended in the latest release.
2. Mission working as intended on the latest dev build, but working without customization on the latest release.

[Amadeus]

17 minutes ago, stgatilov said:

Speaking of actions for the missions which only tweak zoom delay.

 

I can only speak for myself, but I think option 2 would be fine. This will at least allow the missions to be playable on the dev builds for now, and we can see if any other issues pop up

[snatcher]

Plan B in case Joebarnin cannot get it right with immobilizations.

By Any Other Name: attached to this post are the Bow/Arrow, Blackjack and Shortsword scripts updated to 2.12.

I didn't take any liberties. Blame snatcher if something isn't right.

@joebarnin, @stgatilov

z_byanyothername_212_scripts.pk4

[snatcher]

On 5/1/2024 at 3:09 PM, ChronA said:

I think this is a slippery slope fallacy. Just because the ability to customize exists does not mean most mappers will use it. On the contrary, if one considers the customization that are already available, we see that the overwhelming majority of mappers stick to the defaults.

Ok but, at what point do we consider *it* relevant, if ever?

[ChronA]

15 hours ago, snatcher said:

Ok but, at what point do we consider *it* relevant, if ever?

That's a very valid question. Personally, I'd say the key is to watch what the otherwise-disengaged fringes of the community are saying. If first time posters or long time lurkers start coming out of the woodwork about well made new missions, praising them for their geometry and story but saying that innovative parts of the gameplay felt frustrating or off, that's probably the first sign that the innovations are starting to get out of hand.

For a more concrete example, re-read the comments on Hazard Pay. As much as I and many others love that mission, it's clearly a case where the author strayed further than many people were comfortable with.

It also points to the likely endgame if authors do take their customization too far. After getting the negative feedback, kingsal made adjustments, and now the mission is much more friendly towards player preferences that don't match the author's original vision. You don't need to restrict the mapmakers' tools to stop them from straying too far from the traditional formula. When people start speaking up, the authors will rein themselves in on their own.

Edited May 3 by ChronA

[snatcher]

This topic is going in different directions and it is difficult to tell if we all are in the same page.

Facts:

Stgatilov wants to change (improve, I guess) something and while implementing the change he realizes he will break some mission in the process. Mappers have been including (now obsolete) core files in their missions and the developer wants to know why these files were included in the first place, as in: the purpose.

• Changes in two mission are unavoidable, unless the authors go back and revisit the entire logic of their missions.
• Changes in eight missions are avoidable, in the sense that missions remain essentially the same with or without these changes.

Regardless, if the improvements are to be implemented ten missions need to be reviewed and updated.

Now my opinion:

Considering how the topic is going the next time Stgatilov wants to improve something similar he might think it twice (we all lose because of ten missions). If these same improvements were to be implemented in the future chances are not ten but fifteen missions would have to be reviewed and updated which begs the question, does the inclusion of core files in missions put the present and future development of some areas at risk? No, as long as things remain under control: preserve what must be preserved, encourage and support innovations, identify and address trends.

This requires an effort by all parties involved.

Edited May 3 by snatcher