This is the replies from the Q&A questions to the lead programmers. The replies are based on the information currently available and every reply can be subject to changes later on, based on new information or events.
Please note that many of the questions in the Q-thread were design/support-oriented and are therefore not in this one. More Q&A's will follow later on.
--
What kind of programming and other improvements are coming regarding PvP and future Land Grabs? (PVP framing, reviving after being killed, timing of LG, jumping, target box etc.)
• With the new physics engine in place it'll be easier to hit other participants, due to increased updating of positions between peers. Other than that, the exact rules in the next LG phase is not yet determined, other than there will be several changes in order to update the system based on the possibilities now available in Entropia, that wasn't there when the first LG took place (like personal teleportation, to mention one).
I wanted to know why you guys sometimes take so long to fix some bugs that seem to be easy to fix?
• Some of the older systems are not up-to-date with our current design guidelines. When fixing bugs in these systems, it's more difficult to predict side effects that can ultimately result in a new bug for the end user. Thus we avoid modifying them until a new design proposal is in place.
Are there currently specific plans to parallelize EU so that the complete freezes while eg opening storage, auction, inventory, map, skills, etc etc etc, don't happen, and so that the bigger and more complex client each VU can run optimally on new processors (70% CPUs from Intel will be multicore by year's end)? If not, why not, and if so, when?
• Rewriting systems that are based on synchronous event handling to asynchronous is a big undertaking, which is the main reason we’ve not already done it for the user interface backend (which is responsible for the freezes mentioned). Specific plans to further parallelize the EU client are in the roadmap for next year.
Will EU be available in a windowed mode, and if so, can you tell us when that time frame might be?
• The EU client already works in windowed mode, but this option is not yet available for the end user. This can easily be implemented if such a demand exists.
How many programmers are there? How many senior developers, junior developers, male, female? Are some working on new features while others are fixing bugs?
In other words: programmers, tell a little something about yourself and your team.
• The team working at MindArk, which to date consists of eleven programmers, is very experienced and I wouldn’t call any of them junior developers =). We all come from different backgrounds in the computer industry with everything between five and ten years of professional software development experience, from the corporate sector to games development. Normally each individual is responsible for fixing bugs in the systems they have knowledge about, but the distribution of tasks varies a lot from one VU to the next. We don’t have specific roles in the sense mentioned in the question.
What do the programmers think is the biggest problem with the current engine?
• I am not sure how the interpret “current engine” here, but the main problem for any large-scale software project is the constantly growing code base. New and effective design strategies are sometimes difficult to implement due to massive amounts of legacy code that must be maintained and patched to work. We try very hard to eliminate parts of the engine that are considered out-of-date or working poorly.
How do the programmers plan to deal with (unnecessary) bloat in EU, which usually contributes to lag, such as this instance of the old "PE Guide" button control lurking inside the ClientLoader, seeing that the notion of redesigning the program from scratch has been rejected
• It is correct that rewriting the whole code base for EU is out of the question, as it would involve tremendous cost for little return. Here at MindArk it’s everyone’s responsibility to clean out unused resources and code. The notion that lag is due to unused resources is not very likely however.
When will be the memory leak fixed ?
• Identifying memory leaks is a difficult task and I cannot give any approximated time schedule when all leaks will be completely removed.
Is it possible to change this drag & drop system to just simple click system? Like, when you drag your armor on, EU freezes a littlebit everytime. Same thing with TT when you buy ammo / bombs / probes. would it be a little lighter to the system?
• The freezing occurs when the avatar’s visualization is updated to reflect the user’s action, and we believe that to be an important feature. There is some room for optimization though.
Haven't read any of this, but my major question would be whether the devs use any Change Management implementation?
If not, why not?
If so, when was it implemented, and how come certain bugs pop up again after they were fixed during the last VU?
• Bugs reappear due to changes in code and not because of the bug-list management. Bugs that tend to come back often usually reside in older systems that are difficult to maintain and enhance.
What is the purpose of the "this mob cannot be damaged" condition, and why can a mob in that condition still damage me?
This is a problem that is costing us participants thousand's of dollars every year.
• The reason for this behaviour is to avoid exploits of mobs that have gotten stuck in the environment. Sometimes this logic malfunctions and tags healthy and free mobs as not damageable. There is a fix out that should correct this problem.
I've noticed for me that the biggest challenges to overcome are often unseen by users while the simplest tasks are seen as miraculous breakthroughs by the end user.
Which feature/function of EU was the biggest challenge to implement but goes mostly unnoticed by participants and conversely what was the easiest feature/function to implement that is heralded as a great improvement?
• The wormhole implementation and effects was probably the biggest (and most impressive) system that is experienced by the smallest amount of users.
How is the divide between developers working on new features and those working on bug fixes set as a %?
• The time spent by each developer on fixing bugs depends very much on the impact the previous VU had on the community. There are as many answers as there are VU’s to this question I’m afraid.
Can you give some precision on the test before each VU
* they are you carried out on dedicated servers or the same servers
that the real one environment
* how much people for make this tests
* which kind of test carried out you...
Think of seeking another solution to improve these tests because force is to note that many bug appears (Re appears) has each VU.
It's very hard for a player to understand how some bug can't be see.
• The tests are carried out on an equivalent park as the servers running the real environment. Our QA department goes through most scenarios of every system that is likely to have been affected by the recent changes in code. Developers test the systems they are currently working with, and should guarantee their functionality when the VU heads for QA.
When will I be able to change game resolution to match monitors resolution?
• This hasn’t been decided yet, but you can try to change the aspect ratio (Login Window/Options) to better match that of your monitor.
How many servers are currently being used to run Entropia Universe. How many meters of cable is used and whats the total power consumption.
• I am afraid we cannot disclose that information, even if I did know the length of cables or the power consumption. =)
Please note that many of the questions in the Q-thread were design/support-oriented and are therefore not in this one. More Q&A's will follow later on.
--
What kind of programming and other improvements are coming regarding PvP and future Land Grabs? (PVP framing, reviving after being killed, timing of LG, jumping, target box etc.)
• With the new physics engine in place it'll be easier to hit other participants, due to increased updating of positions between peers. Other than that, the exact rules in the next LG phase is not yet determined, other than there will be several changes in order to update the system based on the possibilities now available in Entropia, that wasn't there when the first LG took place (like personal teleportation, to mention one).
I wanted to know why you guys sometimes take so long to fix some bugs that seem to be easy to fix?
• Some of the older systems are not up-to-date with our current design guidelines. When fixing bugs in these systems, it's more difficult to predict side effects that can ultimately result in a new bug for the end user. Thus we avoid modifying them until a new design proposal is in place.
Are there currently specific plans to parallelize EU so that the complete freezes while eg opening storage, auction, inventory, map, skills, etc etc etc, don't happen, and so that the bigger and more complex client each VU can run optimally on new processors (70% CPUs from Intel will be multicore by year's end)? If not, why not, and if so, when?
• Rewriting systems that are based on synchronous event handling to asynchronous is a big undertaking, which is the main reason we’ve not already done it for the user interface backend (which is responsible for the freezes mentioned). Specific plans to further parallelize the EU client are in the roadmap for next year.
Will EU be available in a windowed mode, and if so, can you tell us when that time frame might be?
• The EU client already works in windowed mode, but this option is not yet available for the end user. This can easily be implemented if such a demand exists.
How many programmers are there? How many senior developers, junior developers, male, female? Are some working on new features while others are fixing bugs?
In other words: programmers, tell a little something about yourself and your team.
• The team working at MindArk, which to date consists of eleven programmers, is very experienced and I wouldn’t call any of them junior developers =). We all come from different backgrounds in the computer industry with everything between five and ten years of professional software development experience, from the corporate sector to games development. Normally each individual is responsible for fixing bugs in the systems they have knowledge about, but the distribution of tasks varies a lot from one VU to the next. We don’t have specific roles in the sense mentioned in the question.
What do the programmers think is the biggest problem with the current engine?
• I am not sure how the interpret “current engine” here, but the main problem for any large-scale software project is the constantly growing code base. New and effective design strategies are sometimes difficult to implement due to massive amounts of legacy code that must be maintained and patched to work. We try very hard to eliminate parts of the engine that are considered out-of-date or working poorly.
How do the programmers plan to deal with (unnecessary) bloat in EU, which usually contributes to lag, such as this instance of the old "PE Guide" button control lurking inside the ClientLoader, seeing that the notion of redesigning the program from scratch has been rejected
• It is correct that rewriting the whole code base for EU is out of the question, as it would involve tremendous cost for little return. Here at MindArk it’s everyone’s responsibility to clean out unused resources and code. The notion that lag is due to unused resources is not very likely however.
When will be the memory leak fixed ?
• Identifying memory leaks is a difficult task and I cannot give any approximated time schedule when all leaks will be completely removed.
Is it possible to change this drag & drop system to just simple click system? Like, when you drag your armor on, EU freezes a littlebit everytime. Same thing with TT when you buy ammo / bombs / probes. would it be a little lighter to the system?
• The freezing occurs when the avatar’s visualization is updated to reflect the user’s action, and we believe that to be an important feature. There is some room for optimization though.
Haven't read any of this, but my major question would be whether the devs use any Change Management implementation?
If not, why not?
If so, when was it implemented, and how come certain bugs pop up again after they were fixed during the last VU?
• Bugs reappear due to changes in code and not because of the bug-list management. Bugs that tend to come back often usually reside in older systems that are difficult to maintain and enhance.
What is the purpose of the "this mob cannot be damaged" condition, and why can a mob in that condition still damage me?
This is a problem that is costing us participants thousand's of dollars every year.
• The reason for this behaviour is to avoid exploits of mobs that have gotten stuck in the environment. Sometimes this logic malfunctions and tags healthy and free mobs as not damageable. There is a fix out that should correct this problem.
I've noticed for me that the biggest challenges to overcome are often unseen by users while the simplest tasks are seen as miraculous breakthroughs by the end user.
Which feature/function of EU was the biggest challenge to implement but goes mostly unnoticed by participants and conversely what was the easiest feature/function to implement that is heralded as a great improvement?
• The wormhole implementation and effects was probably the biggest (and most impressive) system that is experienced by the smallest amount of users.
How is the divide between developers working on new features and those working on bug fixes set as a %?
• The time spent by each developer on fixing bugs depends very much on the impact the previous VU had on the community. There are as many answers as there are VU’s to this question I’m afraid.
Can you give some precision on the test before each VU
* they are you carried out on dedicated servers or the same servers
that the real one environment
* how much people for make this tests
* which kind of test carried out you...
Think of seeking another solution to improve these tests because force is to note that many bug appears (Re appears) has each VU.
It's very hard for a player to understand how some bug can't be see.
• The tests are carried out on an equivalent park as the servers running the real environment. Our QA department goes through most scenarios of every system that is likely to have been affected by the recent changes in code. Developers test the systems they are currently working with, and should guarantee their functionality when the VU heads for QA.
When will I be able to change game resolution to match monitors resolution?
• This hasn’t been decided yet, but you can try to change the aspect ratio (Login Window/Options) to better match that of your monitor.
How many servers are currently being used to run Entropia Universe. How many meters of cable is used and whats the total power consumption.
• I am afraid we cannot disclose that information, even if I did know the length of cables or the power consumption. =)
Nice to see this show up today! 
