Can we get an ETA on the new dungeon DB?
- Thread starter 130n
- Start date
fr3357
Member
- Joined
- Jun 16, 2011
- Messages
- 525
- Reaction score
- 4
It isnt as simple as A tells B, then B tells, C.... If A is uncertain of how long his work will take because he is still trying to figure it out, he might say to B I can probably get in in a couple of days. Then B goes and says Hey C a couple of days it will be ready... Then a couple of days pass, C is all like WTF I WAS TOLD ACOUPLE OF DAYS and then it pings back up.
Where it could be simply left with A being kind enough to come to C and Say hey guys ... GREAT NEWS I got some cool shizz for you thats almost done, I will get it to u as soon as I can. Really its as simple as when they figure it out they figure it out, coding isnt like manual labor if you know how to put 4 bolts into something and tighten it takes 5 mins, and you need to make 20x of them its 20x5mins.... It is more utilizing logic which has no true definition to the ability and time it takes to defeat riddles.
a riddle may take you 5 mins to figure out where it might take the next guy 3 years? but you expect that person to answer how long it will take him, when he himself hasnt quite established the answer? you see ?
"When its done, its done"
Dude, first of all, what he meant was MODS, not mobs as in lots of ppl..
I run a company myself, and everytime i ask for something from an employee i ask for a date/time delivery. If they dont give you an ETA that leaves some options basically (not related to DB per say):
A) They dont know how to do the job properly and are still figuring it out
B) They are not putting any effort into it, aka STALL
C) They simply afraid to promisse and dont deliver
If you know the job that must be done you CAN know how much time you will take to make it, even if its a wide estimation or simply, a guess based on your knowledge.
Trying to deviate from it stating defensive arguments for someone else (correct me if im wrong, but you are not part of the staff, are you?) is simply... bleh...
We, the "MOB", want an estimate date (1 week, 2 weeks, 3 weeks.. w/e is fine). Thats not too much to ask, and you have to comprehend it.
Except you probably have 0 knowledge in programming and don't realize when adding or changing something you have to see how it effects the entire program. You have to wrap what you want to add around the program and make it all work together with 0 bugs. Saying I can do this in x hours is bs you run into bugs you did not see coming and have to fix them. I was told something funny in school when I was younger for every bug you fix in the code you create 2 more
Except you probably have 0 knowledge in programming and don't realize when adding or changing something you have to see how it effects the entire program. You have to wrap what you want to add around the program and make it all work together with 0 bugs. Saying I can do this in x hours is bs you run into bugs you did not see coming and have to fix them. I was told something funny in school when I was younger for every bug you fix in the code you create 2 more
If a program is setup properly, you will not run into an issue creating new code (as you described). Typically, bugs are centralized in the area that they are created in. For example, a bug in combat shouldn't effect a feature in looting. If a bug caused issues all throughout the program, that's one hell of a debugging task (given that it's a decently sized program, as Demonbuddy is).
Also, if you are creating two bugs for every bug you fix in your code... you aren't a very good software engineer. (I do it for a living, by the way. lol)
Last edited:
jinny1
New Member
- Joined
- Jun 10, 2012
- Messages
- 554
- Reaction score
- 1
This guy got banned but now started a new account to troll us again
cdmichaelb
New Member
- Joined
- May 13, 2011
- Messages
- 243
- Reaction score
- 1
Stop worrying about the ETA, and it will be a pleasant surprise when it's finally here.
You are quite funny there is tons of statistical data and more to proof you are wrong. It is actually inverse proportional when it comes to intellect useage. The more pressure or incentive you apply, the longer the given task takes. This isn't up for debate either it is a fact.
Opposing to mechanical labor, where pressure and incentives speed the process up.
And to the software programmer below. I went through some university coding seminars to get the basics. It had a bit of coding involved and an awful lot of theory how to actually code. Interestingly back in the day I would call it nonsense and was very doubtful of those teachings.
The most basic thing they taught was for every line of code your produce you will at least write two more in the final version. If your structure was a bit flawed you would end up with a lot of higher amounts.
So over more then a month ago I decided to do my own little autoit script for core farming. When DB wasn't even released. The map is very easy you have fixpoints and stuff you could navigate through the thing or readjust your position in case you where thrown out of pace.
Now I segmented the run into multiple pieces and tested every part 100 times. The segment e.g. from start to first corner would only get a pass if it would run flawlessly 100/100. And I actually watched my script do it 100 times correctly, then I added more line for the next corner which did not interfere in any way with my previous lines. Not even the same variables where used and what happened? The first segment crashed down to be 1 success out of 10. I had to rewrite it about 10 times before I had segment 1 and 2 going at which point DB was released.
I still have no explanation how it was even possible to interfere with the first lines since there was no connection.
This is just one example, back in the day when I did C I had similar problems occur so I am wondering as coding beginner I see those problems yet you claim to be the professional and don't encounter that?
Apoc
Well-Known Member
- Joined
- Jan 16, 2010
- Messages
- 2,790
- Reaction score
- 94
Enough with all the flaming.
Unfortunately, this release has a lot of changes, so the changelog is taking a bit longer to collect than we expected. Expect an update within an hour or two.
Not to rain on your parade, but the type of work you do has no bearing on "what the other company leaves for you". We need to pull data from the game, which means we need to spend time figuring out how the game does it, so we can make use of it. This takes time. We can say "2hrs" to find out that it'll take a week because of edge cases that need to be handled, or a completely wonky way the game does something. What we do isn't an exact science. Yes, we can plan what we're going to do, and what we want to accomplish. We do that. However, it mostly boils down to the type of information we can pull from the game. We don't have the luxury of being able to just "go" and make it work. (Trust me, writing programs that don't rely on other processes, is very easy compared to writing something to interact with a game in a safe, and efficient manner.) Oh, and I program for a living. Who'da thunk?
That's why we create THREE bugs for every bug fix! We're awesome software engineers!
Serious note; read my reply above. What we do isn't an exact science. (If we fix a bug in reading unit attributes, it may cause a bug elsewhere to be uncovered, that was "working" because of the bug we just fixed.) It happens, there's not much we can do about it. The more we learn about the client, the more bugs we find in our own code, and the more bugs we fix.
Unfortunately, this release has a lot of changes, so the changelog is taking a bit longer to collect than we expected. Expect an update within an hour or two.
Not to rain on your parade, but the type of work you do has no bearing on "what the other company leaves for you". We need to pull data from the game, which means we need to spend time figuring out how the game does it, so we can make use of it. This takes time. We can say "2hrs" to find out that it'll take a week because of edge cases that need to be handled, or a completely wonky way the game does something. What we do isn't an exact science. Yes, we can plan what we're going to do, and what we want to accomplish. We do that. However, it mostly boils down to the type of information we can pull from the game. We don't have the luxury of being able to just "go" and make it work. (Trust me, writing programs that don't rely on other processes, is very easy compared to writing something to interact with a game in a safe, and efficient manner.) Oh, and I program for a living. Who'da thunk?
That's why we create THREE bugs for every bug fix! We're awesome software engineers!
Serious note; read my reply above. What we do isn't an exact science. (If we fix a bug in reading unit attributes, it may cause a bug elsewhere to be uncovered, that was "working" because of the bug we just fixed.) It happens, there's not much we can do about it. The more we learn about the client, the more bugs we find in our own code, and the more bugs we fix.
Last edited:
fr3357
Member
- Joined
- Jun 16, 2011
- Messages
- 525
- Reaction score
- 4
+1 to this, completely understand coding, and it can be a headache at times. I am just super glad you guys are getting close to this breaking point. I hope no rushes come from people asking, this update will make this bot shine over every other one and people will be like "There is something else to use?"
xsol
Member
- Joined
- Nov 7, 2011
- Messages
- 503
- Reaction score
- 12
When you are working with anything that is dependent on code from a 3rd party (especially when reversing) you are at the mercy of the 3rd party code as well as having to deal with the easy day to day Jr. Programmer BS. It kills me to see obvious Jr. entry level programmers talking smack about things they clearly have no clue about.
I am not a RE pro and probably never will be, but I have spent years working on Client\Server apps where the client must connect to and support MANY variant servers and OFTEN I spent DAYS if not WEEKS going over wire traces to attempt to isolate and prove a server bug that the server providers claim doesn't exist. Let me tell you knowing what you are doing, and knowing what you could be looking for, doesn't help you cause the weird bug on the remote system or fix it. Those of you dealling with your little petty dynamic data driven web pages etc that think you know something, let me clue you in, you don't know anything; furthermore, if you are a "manager" lmfao you don't know your head from your ass
If either of these guys is you, you have no room to talk about anything; respect you betters and check your god complex
[video=youtube;5W_wd9Qf0IE]http://www.youtube.com/watch?v=5W_wd9Qf0IE[/video]
Gingerbread
New Member
- Joined
- Jul 29, 2012
- Messages
- 171
- Reaction score
- 3
If I worked for an employer who asked me pointless questions all the time I'd quit pretty quickly. (FWIW I own 2 companies of my own) While often you need to know when things are going to happen:
i) Life is rarely black and white, anything that depends on other people to happen is very likely to be late.
ii) asking people "when?" every time actually slows down the process of them doing whatever it is.
iii) Getting a "wide estimation" is worse.
I want accuracy in peoples deadlines, and I want to know that they know I want it as soon as they can get it done right.
Speak for yourself. As it turned out it's out now! I am still sitting back happily using .185 and am waiting for a few days so some more bugs get squished and the great people here like radonic and giles can get their heads around profiles/plugins and randomness.
Patience is a virtue and all that, and from where I am sitting I see the DB devs working at improving DB and new releases being cranked out at a respectable pace.
Thanks apoc kick et al. Keep up the hard work, can't wait to see how far DB has come in a couple more months from now.
And here I didn't want to write exactly that, because I thought it would be over the line. With you on that one though
Not with your companies, you can keep 'em 
Bro, we're all DB supporters here. I, for instance, stuck up to it and didn't think about asking for refund not even once. I'm a long time Honorbuddy user and I know the quality shit they provide. I even dedicated some of my time to develop a plugin for the community.
We just wanted to know how long should we wait to get what was promised. We were not chasing them with pitch forks and threatening to leave their business, we are here because we are loyal costumers that deserve to know what's going on.
Now it's out and we got our answer. No need to quarrel over this anymore.
So, please, stop kissing ass, we're all DB/HB supporters here.