Jump to content
Sign in to follow this  
ddace

CDT Update 3 Discussions Incoming!! We Need Your Input!!

Recommended Posts

Here are some changes i'd like to have:


- more advanced graphics options: especially for cel shading, since alot of people dont like this (like me :p)

- move the first person camera position higher: when using a weapon that has a bit bigger size, mostly huntress weapons, the weapon takes over alot of the screen, changing that could make first person mode more enjoyable

- tavern defence hitbox of a fence: there is this one fence you can go through, but the gap is pretty small to actually rush through it which leads to me getting slowed down there | this one: http://imgur.com/a/rRr95

- jester weapon spawns and rewards: so this change could be a bit strange, but i thought it could be nice if only the type of weapons spawned that the jester has equipped, so if the jester has a Pawn Shot and a Fusion Rift only Apprentice and Huntress weapons spawn


These are some small changes i'd like and i apologize for any grammatical mistakes if i made one.

Share this post


Link to post
Share on other sites



@Dipoklas quote:

- jester weapon spawns and rewards: so this change could be a bit strange, but i thought it could be nice if only the type of weapons spawned that the jester has equipped, so if the jester has a Pawn Shot and a Fusion Rift only Apprentice and Huntress weapons spawn

for this one i disagree one of the many reasons i love the jester is that all 4 weapons can spawn so it is easier to grind gear for all heroes with the jester  maybe it can be a setting or something idk......also i love what the CDT has done can't wait for update 3 keep up the grate job

Share this post


Link to post
Share on other sites


@Dipoklas quote:

- move the first person camera position higher: when using a weapon that has a bit bigger size, mostly huntress weapons, the weapon takes over alot of the screen, changing that could make first person mode more enjoyable

- jester weapon spawns and rewards: so this change could be a bit strange, but i thought it could be nice if only the type of weapons spawned that the jester has equipped, so if the jester has a Pawn Shot and a Fusion Rift only Apprentice and Huntress weapons spawn

- You can hide the Weapon model from First-Person camera, just press whatever is your default key to hide the HUD, for me its H. That hides the weapon model as well as pet model from First-Person view so you have better visibility.

- That would make playing as other classes obsolete, since Jester is already one of the best classes out there for DPS and in general. You can buff, de-buff, heal, upgrade, damage-all, kill a % of enemies with the jester. And the one reason why people use other chars in class based reward maps is primarily the randomness in getting the reward that comes with Jester. If that is taken away I'm afraid apart from Monk and Jester no character will be used.

Share this post


Link to post
Share on other sites

Can you reduce timeout between mini-waves of enemies on Foundries and Forges & The Magus Quarters? I think it's a little bit longer than it needs to be.

P.S. Sorry for bad English, just I'm Russian.

Upd: And maybe beams on Myths? For players who just farming Myths. Switchable Myths blue beam. I think it will be useful for 74-83 lvl :)

Share this post


Link to post
Share on other sites

I had a new idea for survival lemme know what you think.
Add an option to increase the player based mob count on survivals:
-- Some maps drop to <20 FPS if you bring in extra chars just for more enemies.
-- Plus it requires to create redundant summoners to have more mobs and in turn more drops. When you only really need one for all repairing / healing purposes.
-- Also becomes a bit hard to properly look at items under splitscreen.

How this will (possibly)work:
-- Just like Mix Mode toggle option, we can have another toggle option to set whether we want more mobs or not from the beginning.
-- So let say I check the option to increase default mob count, it opens up a pop-up that starts from 1 and goes till 4(or 6 or 8 depending on the map).
-- Assuming I select 3, that means, even with 1 player, the mob count will be capped as to what it would be if there were 3 actual players. Now, suppose if I invited another player, the mob count would increase to that of 4 players as it normally happens. But if 1 player leaves, it will go back to the default which was selected before starting the map, i.e. 3 player mob count in this case.
-- But, if it is selected as 2(i.e. for total 2 players), then if someone joins in it will increase normally(to the max possible player-based mob count for that map), but if they were to leave it'll return back to the one that was selected by the host, so 2-player based mob count in this case.
-- If mix mode is selected with increased mob count, then it stacks up with that too w.r.t. tougher mobs, more hp and more count if there are more players.
-- Possible benefits of this is, it removes unnecessary redundancy in creating extra characters(mainly summoners), can possibly improve performance since there is no split screen, and (subjectively) helps at looking at gear on the map even better, as there is full screen space. Another one is -- players that only wish to farm armor can have the full possible mob count, so this in-a-way makes survivals more lucrative.
-- Disadvantages? I can't think of any, let me know if you can think of. :)

Share this post


Link to post
Share on other sites

The main disadvantage is the amount of coding required for this. There are a few ways I can think of how they would implement this, and none of them are easy or small changes. Basically the big problem here is that this is something that benefits people not all that much and the time used for this could be used for other things that will target a much larger part of the playerbase. The CDT doesn't have infinite time.

One way I could think of setting this up without being too messy and requiring catastrophic amounts of time, is just setting a new game mode before the map starts. "Add 0-5 ghost slots", next to the required join level. You would still have to implement a check for the ghost slot value in wave counters, reward distribution and monster stats but if you forego the option to change this mid-game it shouldn't actually be that bad.

I am not sure how archaic or complex the wave code itself is but since the scaling for player count exists already, it's a question of adding one layer of checking for the player count, which would be actual players plus ghost tokens. If the code of each map needs to be modified separately, that would increase the time required exponentially. If it's a global modification, it is probably worth considering.

A big issue I see happening is how the game will behave if you set ghost tokens to maximum and still have people in your tavern.

Share this post


Link to post
Share on other sites

I didn't really understand your suggestion, sounds a bit more complex and odd to me actually from whatever I could gather.

Also on the contrary having the ability to set mob count at max players, does or will benefit people, because they dont have to actually bring in more characters to get more mobs and in turn to get more item drops on maps. Not to mention the significant fps drop that comes along with splitscreen.
As far as coding goes, I'm not sure how much work this requires, but from the looks of it I could say not that much becasue the suggestion is fairly simple -- giving the ability to have max player mob count on a particular map, but with just one player. It just requires some flags and checks to be added and a little bit of incrementation right from the beginning.

Currently the only way to do this is add players during build phase, start the run and remove them, but is tedious to do that.

Share this post


Link to post
Share on other sites


@Black Mamba quote:

Currently the only way to do this is add players during build phase, start the run and remove them, but is tedious to do that.

This sounds like the perfect solution to your problem :)

Share this post


Link to post
Share on other sites

Mamba, the game has to check at build phase (and probably during all phases actually) for active_players value, which is just another scaling variable for wave length, monster stats and what not. What you want is to manipulate active_players with a second variable which I just call ghost_tokens since the game will think players are there but really aren't. (Hence, no split screen, hence ghosts)

That still means that in every instance of the code that has anything to do with player count, they need to actually make the active_player segment call the ghosttoken value to modify the active_player segment. That by itself means they need to somewhere in memory set the value for this, store it, and then have it called. So not only do they need to add new code, they also need to modify existing code, which could dramatically break stuff.

Basically, all this is good for is "no FPS drops for people who farm with 4 chars". I can think of dozens of more important things than that and I use 4 player split screen for a lot of things. 

You need to understand that what you think is "simple" is not always simple in terms of code.

There might be an easier way that adding a second variable to modify player_count but I kinda doubt it. And you also need to understand you can't just "set wave size to max" because wave size is not something fixed but calculated in runtime based on active players, wave number and what not.


After everything is said, to me this seems like a big waste of time that also carries the possibility of introducing entirely new bugs never seen before. (Also, heck no should we allow people to just run lab by pretending to have 6 characters in there.)

Share this post


Link to post
Share on other sites

Poet -- Yea but its very tedious, and I don't want to reveal the well known bugs that are already there in that. But people who know what I'm talking about will agree with the suggestion. :)

Kuugen -- I think I kind of understand what you mean now. If in terms of coding if what I suggested seems hard/complex to implement then perhaps we can just have an option for max possible mobs by default, and no extra players can be added in. Also my suggestion doesn't touch rewards, only mob count. So that way you have to choose between more rewards or more mobs per wave.

What you are suggesting is, feels like a simulation of more players thereby leading to more rewards. Rather what I'm saying is simply setting a flag for higher mob count based on a number selected before starting the map. Please don't unnecessarily over-complicate it! Let the CDT think about it how they can go around doing it or not, or if it is even possible. Thanks!

Share this post


Link to post
Share on other sites

The "max possible mobs by default" would still need SOMETHING to tell the game to make that happen, which still means you need to modify player count in the wave calculation somehow since that is the primary factor that goes into it. That's why this is not something so easy. Even if you want this to not actually simulate players existing, you still need to make the game think there are more players than there really are. Unless they change how wave size is calculated, which is a barrel of worms. 

I don't have the actual code but wave size should be something like this, if the code is relatively standard (this is super simplified just to give an example, the actual code probably looks nothing like this)

spawn_moinster_multiplier=(active_player*waves_passed*wave_number; get_mix_mode_state; IF=True; call mix_mode_multi)

Basically, they could

1) manipulate active players in some way

2) add a new segment in front that calls for a check on a new 'mode', like MM, that then goes ahead and says active_player is 4(or 6)

Changing waves_passed or wave number, or even the basic spawn count that gets multiplied, is gonna break everything.

There might be some obvious third way I can't think of (Probable but I personally doubt it) but in general, I still stand by my point that this is wasting a bunch of time better spent elsewhere.

Share this post


Link to post
Share on other sites

Temple O' Love Cupids could still use a slightly reduced flying height. I know I might get some heat for this, but unless you are super pro(which most people are not), then its near impossible to kill them using Melee characters. Having killed it twice with Barbs(as part of a personal goal) I know ToL can be ridiculously painful to beat with melee characters. Its even harder compared to Phoenix versus Melee Characters, so that's something.

IMO maps should not be limited to just X particular class being viable. Some classes can be the best at a map, but at the same time other classes should have about as much chance at killing bosses as that particular class(es). In this case, if you are not a Ranged character, you simply can't kill the Cupids unless you are very-very-lucky or use a Barb with Tornado Stance and jump high enough without getting hit by the damn Cupids all the time.

Also, earlier I had mentioned to [[48136,users]] about "Krytykal Stryke" not being able to hit the Cupids(pre-CDT). However I tested it recently with my Kryt Stryke and I got the Cupids down easily. I think this is related to one of the fixes where the Old One Belly Crystal not being ale to be hit was fixed with some weapons.
That being said, I'll re-test this with Ranger Skin, EV and other Skins just to be sure if this wasn't a one off incident. Becasue 3.5 years back when the DLC was released, I had tested it with my Krytykal Stryke and I couldn't hit the cupids(which was also mentioned by me a few years back -- 
link).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...