Jump to content
The Dark Mod Forums

TDM flame particle options


Baddcog

TDM flame particles for 1.08  

24 members have voted

  1. 1. Which flame particle option do you prefer?

    • Having a flame particle be players choice above all (easy to change at will)
      4
    • Having a flame particle that only the mapper can choose (if you don't like it too bad)
      20


Recommended Posts

I don't see reason for polarization that's why I didn't vote. I think both option is not implemented yet. If so then, amount of manhours can be used for combining both particles into one with some artistic touch (including different colors) which can satisfy both sides. In this way we'll continue to use single torch particle again. Everything is solved. :)

 

Well I really tried not to make it polarizing. But the fact is, #1 option is easiest and it gives mappers/players a choice. It retro fits to all maps.

 

#2 is harder on the team and it only gives the mapper the choice and leaves the player out of the equation. it will leave maps one way or the other but all maps will never be consistent.

 

If that's polarizing so be it. It's the plain and simple facts.

 

#3

 

Edit:

 

Ha! I see I wasn't supposed to vote. Nor ask for tree videos.

 

Since mappers spend far more time on a FM than players ever do, I'd vote for anything that makes life easier for the mapper, not harder.

 

As a player, I think there are way way more choices in the menus than I care to deal with or care about, but that's my own opinion.

 

I didn't say you weren't supposed to vote did I? I simply stated that all the votes look like they are going to mapper deciding the particles for the player, and nobody that has voted to that point was seeing it from the players perspective imo.

 

I said the videos aren't needed because this is NOT a debate about which particles we use as stock. It's about simplicity for mappers, and mappers/players choice.

 

Again, a menu option IS NOT an option. The only option is to drag/drop a folder. And that's only if you care enough about the particles you see (whether TDM stock or mapper chosen) to bother and waste 10 seconds installing a folder in another location.

 

You appear to have voted for #2, and yet #1 IS the simplest option for a mapper. How can I not make this point?

Is it easier to drag/drop a folder before you zip? Or is it easier to have two of every torch entity in the gamesys, or to have to check a spawnarg on every light you create so that all flames in your map look the same?

---

 

But the debate is over for me.

 

Everyone seems to prefer option 2 which means two things.

 

* Someone needs to step up and finish the new particles.

 

* Then they need to create another entity for each and every flame light entity so the mapper has the choice. They also need to do it in a clean and organized fashion. Or a coder needs to add support for a particle swap spawnarg and it will need tested thoroughly through out the mod, old maps and new. All this because I wanted to finish my light entity work and asked if we were going with the new particle or the old (because someone left them only half swapped out).

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Next: In the interest of keeping most/all FMs working indefinitely, how about not giving excessive modding powers to Joe GamePlayer?

I guess you didn't read my post very well.

 

Giving the player the choice of flames actually makes it EASIER to keep all maps past and present consistent to players viewing preference. By forcing a particle by mappers choice means all old FM's will have one particle style. And all new fm's will be mix matched.

I'm afraid I'm still with Springheel on this one. A torchflame particle may be indefinitely backwards-compatible, but other addons may not be indefinitely backwards-compatible. I'm going to analogize my earlier point to try to make it more clear, borrowing some of your own vocabulary.

_____________________

 

Suppose Rodney Redneck purchases a 12-gauge shotgun. He really loves his shotgun, but there's something about the barrel that he doesn't like. So Rodney Redneck gets a metal file and makes his changes to the gun barrel to his own personal preference.

 

Two weeks later, the shotgun barrel explodes, the gun now useless. Rodney Redneck calls the gun manufacturer and cusses up a storm how his gun must have been defective.

 

Poor Rodney Redneck doesn't know that it was his tampering at fault, and the poor gun manufacturer doesn't know that Rodney did any tampering at all. It becomes a nightmare for both sides. If Rodney Redneck was an intelligent, informed gunsmith he probably could have made the changes without any danger. If Rodney Redneck had consulted with the gun manufacturer first, perhaps they would have been able to accomodate him.

 

But no. Rodney Redneck ended up forcing his own preferences on the finished 12-gauge shotgun, and proverbially "shot himself in the foot".

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

Then they need to create another entity for each and every flame light entity so the mapper has the choice.

 

That's not necessary at all. The only difference between an old torch entity and one using the new flames would be a single def_attach spawnarg.

 

I just tested it, and it's quite easy to place default torch entities, select them all, add "def_attach" "light_torchflame_new01", and voila.

Link to comment
Share on other sites

This is almost as exciting as the China GP. Who's winning?

 

Arcturus' new torchicles are rather awesome and if they're not already, it'd be nice to roll them out to mappers asap.

 

I don't think it's obvious that TDM should assume that all previous torches should be replaced, by order of the peoples' republic of Bridgeport, with torchicles, and it's possible that a mapper may even prefer the old torches for some strange, unfathomable aesthetic, technical or egotistical reason.

 

Not sure how that transpires into votes (or even what we're voting for), but hray - new torches \o/

Link to comment
Share on other sites

As someone who's dangled his feet in the shallow end of FM design (and reconciled himself to never getting further than halfway through page 2 of Fidcal's TDM Beginner's Guide), my noob perspective is: If there's an option that (i) keeps it as easy as possible for those amazing people who can design FMs to get on and produce more of them, and also (ii) keeps it as easy as possible for techno-noobs like me to play them, choose that one. :)

 

(Have a suspicion it may not be that simple though.)

Sorry, but this is ridiculous hyperbole. Do players feel "weak and impotent" because big scary mapper "forces" all their preferences for textures and models and sounds and entities and readables on them? :rolleyes: I don't know what makes flame particles the tipping point.

+1. Out of the 35-odd TDM FMs I've played, there have only been 4 I've stopped playing because I felt insurmountably 'weak and impotent', and that was down to gameplay design - it was nothing to do with how stuff looked. (And I'm planning to give at least 2 of those 4 another go at some point anyway).
Link to comment
Share on other sites

Yep. Who is supposed to be the villain here?

 

Is it the dev team + mapper? (whom I argue should have this kind of design power)

Or is it the player? (who is supposed to be a kind of audience to the dev team and mapper's vision)

 

It's like the player is being given veto power over the mission-maker.

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

I'm afraid I'm still with Springheel on this one. A torchflame particle may be indefinitely backwards-compatible, but other addons may not be indefinitely backwards-compatible. I'm going to analogize my earlier point to try to make it more clear, borrowing some of your own vocabulary.

_____________________

 

Suppose Rodney Redneck purchases a 12-gauge shotgun. He really loves his shotgun, but there's something about the barrel that he doesn't like. So Rodney Redneck gets a metal file and makes his changes to the gun barrel to his own personal preference.

 

Two weeks later, the shotgun barrel explodes, the gun now useless. Rodney Redneck calls the gun manufacturer and cusses up a storm how his gun must have been defective.

 

Poor Rodney Redneck doesn't know that it was his tampering at fault, and the poor gun manufacturer doesn't know that Rodney did any tampering at all. It becomes a nightmare for both sides. If Rodney Redneck was an intelligent, informed gunsmith he probably could have made the changes without any danger. If Rodney Redneck had consulted with the gun manufacturer first, perhaps they would have been able to accomodate him.

 

But no. Rodney Redneck ended up forcing his own preferences on the finished 12-gauge shotgun, and proverbially "shot himself in the foot".

 

Actually I'm not going to read the rodney redneck story at all. The flame is backwards compatible because of the name. All the settings should be quite similar so swapping them out only requires dropping the image into a folder (new image same name). How is this so hard to understand?

This is how the T2 flame packs are done. You only drop an image file into a folder. Simple, done, everything retro fitted.

 

That's not necessary at all. The only difference between an old torch entity and one using the new flames would be a single def_attach spawnarg.

 

I just tested it, and it's quite easy to place default torch entities, select them all, add "def_attach" "light_torchflame_new01", and voila.

 

OK, then we just leave the choice to mappers. No new entities, no code. But a mapper still has to add that to every torch (possibly hundreds per map, I dunno, maybe you can select them all at once somehow). Still easier than just making torches and dropping a folder in their zip 1 time? No, it still requires premade entities for both flame types. All we have to do to leave the choice to mappers is give them a folder to drag/drop. That's it. NO EDITOR WORK AT ALL. No entities, no def attach, nothing.

 

This is almost as exciting as the China GP. Who's winning?

 

Arcturus' new torchicles are rather awesome and if they're not already, it'd be nice to roll them out to mappers asap.

 

I don't think it's obvious that TDM should assume that all previous torches should be replaced, by order of the peoples' republic of Bridgeport, with torchicles, and it's possible that a mapper may even prefer the old torches for some strange, unfathomable aesthetic, technical or egotistical reason.

 

Not sure how that transpires into votes (or even what we're voting for), but hray - new torches \o/

 

All this is about (why do I have to say it again?) is that #1 allows someone to drag/drop a folder depending on their personal preference (mapper or player). It doesn't require extra work. It doesn't force new or old particles on anyone.

It makes one (whichever flame is chosen) be the stock TDM flame like always. And another is in a folder to drag/drop at mapper/players will.

 

#2 makes the mapper do more work, or the team to do more work and allows the mapper to more easily force a certain particle on the player. And the artistic choice argument is BS. Because the mapper has that choice in both respects.

This choice can STILL let players override the mappers choice, it ONLY makes it harder on the mapper. To override you do the same exact thing as I propose in #1, you drag/drop a folder.

So for all the mappers who want to force a particle because of artistic choice, you WILL do more work, the player can still have their choice anyway.

Which makes #2 only have the benefit of being harder to work with. That's the ONLY benefit.

 

As someone who's dangled his feet in the shallow end of FM design (and reconciled himself to never getting further than halfway through page 2 of Fidcal's TDM Beginner's Guide), my noob perspective is: If there's an option that (i) keeps it as easy as possible for those amazing people who can design FMs to get on and produce more of them, and also (ii) keeps it as easy as possible for techno-noobs like me to play them, choose that one. :)

 

(Have a suspicion it may not be that simple though.)

+1. Out of the 35-odd TDM FMs I've played, there have only been 4 I've stopped playing because I felt insurmountably 'weak and impotent', and that was down to gameplay design - it was nothing to do with how stuff looked. (And I'm planning to give at least 2 of those 4 another go at some point anyway).

 

That quote as most is taken out of context. If the player wants the old flames because he likes them better it is harder to replace them if the mapper builds another particle into the map. (not much though).

 

But with #1 the choice would be set up ready to go.

 

Again, #2 ONLY makes it harder on the mapper. That's the only thing it does, yet everyone has argued for it from the start. It is pointless and has no merit.

 

#1 is quicker, easier, less work. And both choices have the same outcome anyway.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Yep. Who is supposed to be the villain here?

 

Is it the dev team + mapper? (whom I argue should have this kind of design power)

Or is it the player? (who is supposed to be a kind of audience to the dev team and mapper's vision)

 

It's like the player is being given veto power over the mission-maker.

 

Really, because the player like the old flame better than the new one, they are vetoing the mapper?

 

Anyway, it only takes 3 seconds to change it to players prefs anyway.

 

Do we complain the player can noclip? That completely vetos and distorts any gameplay the author had in mind.

 

Since when did TDM development turn to, fuck the player, we want them to see it this way. If that's the direction we want to take (though it can never be enforced and i really don't see why people can't accept players choice of particles) then we need to get rid of the bow aimer. TDM team never wanted a bow aimer, that's a mod, an add on, and God forbid a players choice of visual.

 

Is there really any mapper here who would be butt hurt because some random player doesn't like the same flame particles as them? Do you feel better knowing that a player wont like them but 'haha, they have to see them anyway'?

----------

Upon 1.08 release I will just release a pack myself that overides the flames for the players choice. TDM can stick to 'artistic integrity' and I will release a pack that they player can have their choice in 3 seconds.

 

This whole debate is pointless.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Im kind of astounded that this little thing is discussed so much by the community and the dev team. Why are you mauling each other? As I read how much the opinions differ on this, I would make it easy:

  • create a .pdf which contains the 3 screenshots and how you can change the actual used flame with another optional
  • put the optional sprites into the same folder as the .pdf
  • let it be downloaded with tdm_updater for 1.08

I know this is the same like Baddcog said - but in my opinion it is the easiest way to get by all the differences you have there.

 

Don't waste your time on such little things :)

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

Actually I'm not going to read the rodney redneck story at all. The flame is backwards compatible because of the name. All the settings should be quite similar so swapping them out only requires dropping the image into a folder (new image same name). How is this so hard to understand?

This is how the T2 flame packs are done. You only drop an image file into a folder. Simple, done, everything retro fitted.

Thank you for dismissing my clarification as foolish nonsense.

 

You are absolutely correct: the flame is 100% backwards compatible in its technical implementation. I know how the D3 code handles pk4 files. I know that it will perfectly overwrite the base asset. I know that a mere particle effect cannot change gameplay in any way. That is not what I am arguing over.

 

Since when did TDM development turn to, fuck the player, we want them to see it this way. If that's the direction we want to take (though it can never be enforced and i really don't see why people can't accept players choice of particles) then we need to get rid of the bow aimer. TDM team never wanted a bow aimer, that's a mod, an add on, and God forbid a players choice of visual.

 

Is there really any mapper here who would be butt hurt because some random player doesn't like the same flame particles as them? Do you feel better knowing that a player wont like them but 'haha, they have to see them anyway'?

Thank you for the ad hominum attack.

 

As stated in previous posts, I have no preference about one little particle definition. But since you seem to think that my arguments are only regarding this one particle, let me give you some different cases.

  1. Suppose someone creates a nice shiny new model addon pack with high-resolution books. What if there is an FM that says references a red book, but the addon pack overrides it with a green colored model? "Fuck the mapper, my books are pretty."
  2. Or perhaps someone creates an addon pk4 that overrides the entity definition for the proguard: brand-new anims, shiny new mesh, etc. What happens if a future FM calls an anim that the overriding definition does not have? Crash-to-main-menu. To reciprocate your hyperbole, that would be a player saying "Fuck the dev team, my new proguard is better, even if it breaks this mission."
  3. One of my WIPs has vanilla TDM tree models with some handdrawn brushwork CM so the player can climb the branches up to a mission item. Suppose, though, that an addon pk4 is made that overrides that tree model with another model because of someone's personal preference. Now my mission is likely broken. "Fuck the mapper, I want to see it my way. My tree is much better."
  4. Or perhaps someone creates an addon pk4 that overrides the entity definition for atdm:ai_base, to give the AI more realistic acuity and behavior. What happens if the dev team creates brand-new AI behavior, and puts its args in atdm:ai_base? The player will never get to see that behavior (or more accurately, TDM will likely refuse to start because of the code changes). "Fuck the dev team's changes, my AI behavior is better than whatever behavior they added."

 

Your cry is "now this one thing is completely consistent!" See how all of the above examples actually destroy consistency!

 

____

 

@SeriousToni: This is actually pretty tame. You should see some of the arguments waaay back when oDDity was still on the team. Those were really heated. :D

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

I'm assuming the intent all along was to replace the existing particle effect correct? If so, what needs to be done in order for this replacement asset to gain majority approval? The mod is almost 2 GBs so if you can avoid including redundant assets then that's the best course of action.

 

So what does everyone say? Either it's better or it isn't. If it's better it replaces the existing asset. If it's not then the contributor retools it to address the complaints and resubmits it. I say it's a suitable replacement.

Link to comment
Share on other sites

Some people prefer the old particles (1.07 flames) and some people prefer the new ones. It's actually probably 50/50.

The whole debate is based on this one, possibly false assumption. Anyway don't make this an addon to be installed by players, because most people won't even know about its existance, or won't bother even if they like it better.

It's only a model...

Link to comment
Share on other sites

I propose a new magic arrow that allows players to switch between flames and flamicles and back again by shooting at them.

 

This allows mappers to apply their artistic vision by choosing the default for individual torches. It empowers players to change the game to their preferences. And, crucially, doesn't clutter the options screens. It would require only simple scripting and could make efficient use of existing assets - just paint one of the existing arrows to look like a rainbow and off you go.

 

Ladies and gentlemen, I think we have a solution.

 

It could also be used to switch rug textures on the fly.

  • Like 3
Link to comment
Share on other sites

The new flames are heading in the right direction. As both a player and (unaccomplished) mapper I'd say include the new one when it's ready and deprecate the old.

 

If it works the same, and has similar properties, then it won't break anyone's mission. It's also not important enough for a literal flame war.

Link to comment
Share on other sites

Oh dear!

I looked at the flames, shrugged and said: meh, both are fine. I don't care which one. Wait a while and there is a frickin' UN security council debate going on here.

 

Howsabout the team decide internally what to do, using post #36 as a guideline? Development history shows that the team has always taken the best course of action for the mod, why wouldn't it do so now?

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

I propose a new magic arrow that allows players to switch between flames and flamicles and back again by shooting at them.

 

This allows mappers to apply their artistic vision by choosing the default for individual torches. It empowers players to change the game to their preferences. And, crucially, doesn't clutter the options screens. It would require only simple scripting and could make efficient use of existing assets - just paint one of the existing arrows to look like a rainbow and off you go.

 

Ladies and gentlemen, I think we have a solution.

 

It could also be used to switch rug textures on the fly.

 

 

 

Ladies and gentlemen, I think we have a solution.

 

B)

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Thank you for dismissing my clarification as foolish nonsense.

 

You are absolutely correct: the flame is 100% backwards compatible in its technical implementation. I know how the D3 code handles pk4 files. I know that it will perfectly overwrite the base asset. I know that a mere particle effect cannot change gameplay in any way. That is not what I am arguing over.

 

Thank you for the ad hominum attack.

 

As stated in previous posts, I have no preference about one little particle definition. But since you seem to think that my arguments are only regarding this one particle, let me give you some different cases.

  1. Suppose someone creates a nice shiny new model addon pack with high-resolution books. What if there is an FM that says references a red book, but the addon pack overrides it with a green colored model? "Fuck the mapper, my books are pretty."
  2. Or perhaps someone creates an addon pk4 that overrides the entity definition for the proguard: brand-new anims, shiny new mesh, etc. What happens if a future FM calls an anim that the overriding definition does not have? Crash-to-main-menu. To reciprocate your hyperbole, that would be a player saying "Fuck the dev team, my new proguard is better, even if it breaks this mission."
  3. One of my WIPs has vanilla TDM tree models with some handdrawn brushwork CM so the player can climb the branches up to a mission item. Suppose, though, that an addon pk4 is made that overrides that tree model with another model because of someone's personal preference. Now my mission is likely broken. "Fuck the mapper, I want to see it my way. My tree is much better."
  4. Or perhaps someone creates an addon pk4 that overrides the entity definition for atdm:ai_base, to give the AI more realistic acuity and behavior. What happens if the dev team creates brand-new AI behavior, and puts its args in atdm:ai_base? The player will never get to see that behavior (or more accurately, TDM will likely refuse to start because of the code changes). "Fuck the dev team's changes, my AI behavior is better than whatever behavior they added."

 

Your cry is "now this one thing is completely consistent!" See how all of the above examples actually destroy consistency!

 

____

 

@SeriousToni: This is actually pretty tame. You should see some of the arguments waaay back when oDDity was still on the team. Those were really heated. :D

 

All your arguements are invalid due to this one single point.

 

The flame model is completely backwards compatiible. It is only a texture change.

 

Your four arguments all point to what if "an add on pack is done wrong". Well, if so then it would screw things up. Which is not the case here so why argue that point?

If someone makes a tree replacement pack it should conform to existing trees but make them better.

If someone makes a book pack it should be a 'better pack' that still matches sizes/colors.

If someone makes a new anim of course they should make it work in game.

If someone makes a new base ai def it should work with the game.

 

Are you seriously arguing that 'what if someone screws up an update/improvement pack and it causes issues' is the same as having a simple flame texture replacement pack? And if it was so broken people would just remove it and not use it anyway.

 

those things don't break consistency, they break the game.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

The whole debate is based on this one, possibly false assumption. Anyway don't make this an addon to be installed by players, because most people won't even know about its existance, or won't bother even if they like it better.

 

I guess it's a false assumption. In the thread about which one to use about half the people said they liked the new one, some prople liked the old.

 

I was only asking which one I should implement for 1.08 on ALL models as it is only on half of them now.

 

Then it turned into we have to have options for mappers because artistic integrity is at stake.

 

So I mentioned just having a drag/drop folder of old particles that the mapper and/or player could choose from at their own preference.

meaning most likely TDM flames would be upgraded, if anyone prefers the old it's easy to use them still)

 

Which turned into :We need editor options (artistic integrity), We can't let player decide (artistic integrity) and now "what if someone upgrades books and makes red ones green".

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Oh dear!

I looked at the flames, shrugged and said: meh, both are fine. I don't care which one. Wait a while and there is a frickin' UN security council debate going on here.

 

Howsabout the team decide internally what to do, using post #36 as a guideline? Development history shows that the team has always taken the best course of action for the mod, why wouldn't it do so now?

 

Because half the wants option A, half the team option B, and some of them option C and no compromise is in sight, and the "boss" (art directory) doesn't want to force a decision. Hence, a draw and no solution :)

"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 comment
Share on other sites

the "boss" (art directory) doesn't want to force a decision.

 

I'd prefer a consensus, but if there isn't one I'll make a final decision shortly.

Link to comment
Share on other sites

I had never truly witnessed a flame war until reading this thread today.

 

I liked the new version personally. I have always found the current torch flame rather fake looking. The third option posted on page 1 looked great to me...perhaps it just needs to be sped up slightly, but I think it is magnitudes better than what we currently have...which looks like a booster rocket. lol In any case, include both...but for the love of God...no menu options for fracking flames.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...