|
|
|
 |

February 23rd, 2003, 10:36 AM
|
 |
Captain
|
|
Join Date: Jan 2001
Location: Texas
Posts: 830
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: UI Glitches
Quote:
quote: Originally posted by raynor:
An escort size vessel can only have one bridge.
|
With standard data files.
To the best of my knowledge, this is not moddable. If you look at VehicleSize.txt, then you see only this one line that refers to the bridge:
Requirement Must Have Bridge := True
Here are the relevant lines from components.txt:
Ability 1 Type := Ship Bridge
Ability 1 Descr := Contains a ship bridge.
Ability 1 Val 1 := 0
Ability 1 Val 2 := 0
One way to test the 'Bridge' functionality is to add this ability to another component. I added this ability to the Rock Colony component and then added two Rock Colony components to a ship. The game displayed the informational line: The ship must have one bridge.
Quote:
quote:
IMHO, a well thought-out UI would either remove or gray out the bridge component after you have added one to the ship. SEIV does neither of these. Instead, it tells you that you have too many.
|
The logic and data file search required to perform this on an arbitrary data file is far more complicated than the problem warrants.
The game already has the logic implemented. That's how it is able to display the message that a ship can have one bridge and prevents you from creating a ship design with more than one bridge. That's the whole point of this complaint. There is no logic or data file search changes required. It would just be a simple change to the user interface.
A ship can have exactly one bridge. If you try to build a ship with more than one bridge, the game prevents it. So, once you add the bridge to the ship, don't let the user add it again. If you *do* let the user add the bridge again, then you are just wasting their time.
Quote:
quote: Did someone say that it makes sense for 'Repeat Build' to repeat build the first item--even if the queue contains ten items? IMHO, if the queue contains more than one item, the program should warn you that the second item will never be built.
|
The program does. It's in the text that describes that only the first build item will be repeated.
Okay. Let me clarify to say that I want a feature that warns me before I leave the queue that some of the items will never be built. Once again, this is just basic UI design. You don't want to hide a message that could potentially cause the user a great deal of frustration. Just telling the user that the top-most item will be repeated would be adequate if the Last thing you clicked was that button. But because the program allows you to fill the queue *after* the button is pressed, there is a valid need for additional informational Messages.
Quote:
quote: Similarly, if the 'Repeat Build' option is selected, then the program should not allow you to add another item to the build queue.
|
As others have pointed out, there are valid reasons for allowing the other queue items to remain. I know I'm glad for it when dealing with the 100+ shipyards I have in orbit of my homeplanet in a proportions game. Without that, I would have to do far more mouse clicks to change a queue back to its standard repetitive build after building a few other units. It is a new program feature that stops repeat building facilities when the planet is full. So, yes, in that one case, it makes sense to have more than one items in the queue with repeat build turned on.
In all other cases, I would still disagree. Why would you want the game to make it easier for you to add an item to the queue that will never be built?
[ February 23, 2003, 08:52: Message edited by: raynor ]
|

February 23rd, 2003, 06:02 PM
|
 |
National Security Advisor
|
|
Join Date: Jan 2001
Location: Ohio
Posts: 8,450
Thanks: 0
Thanked 4 Times in 1 Post
|
|
Re: UI Glitches
Correct, the restriction for one bridge per ship is hardcoded. You can put an aux control on the ship, but there is no way to require a player to do so. You could I suppose mod the vehicle size and raise the maintenance on it up and then give the aux control an equal maintenance reduction. This way it would not make sense for the player to NOT have an aux control, but there would be nothing stopping him from doing so. And if he didn't read the fine print he'd have very expensive ships.
The AI can be required to build their ships with aux control through the design files, but that doesn't apply to the players.
__________________
I used to be somebody but now I am somebody else
Who I'll be tomorrow is anybody's guess
|

February 23rd, 2003, 08:28 PM
|
National Security Advisor
|
|
Join Date: Nov 2000
Posts: 5,085
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: UI Glitches
"Okay. Let me clarify to say that I want a feature that warns me before I leave the queue that some of the items will never be built. Once again, this is just basic UI design. You don't want to hide a message that could potentially cause the user a great deal of frustration. Just telling the user that the top-most item will be repeated would be adequate if the Last thing you clicked was that button. But because the program allows you to fill the queue *after* the button is pressed, there is a valid need for additional informational Messages"
This addition would very quickly get incredibly annoying, and IMO is only good until you figure out this portion of the interface- which isn't at all hard. After that, you just say "I KNOW that, stop showing me this damn box!"
Phoenix-D
__________________
Phoenix-D
I am not senile. I just talk to myself because the rest of you don't provide adequate conversation.
- Digger
|

February 24th, 2003, 01:09 AM
|
 |
Shrapnel Fanatic
|
|
Join Date: Jul 2001
Location: Southern CA, USA
Posts: 18,394
Thanks: 0
Thanked 12 Times in 10 Posts
|
|
Re: UI Glitches
[quote]Originally posted by raynor:
Quote:
This game has lots of folks who love it so much they would rather pawn off all its idiosyncracies as player misuse. I would imagine most of the players of this game are still on the nVidia and AMD band wagon as well.
|
Umm... no. That statement is just plain wrong. I don't think it could be any farther from the truth than it already is.
Also, nVidia makes the best video cards. They have the best drivers for video cards. ATI is the only company that could even come close. They usually have slightly better hardware than nVidia does, but they also have inferior and glitchy drivers that prevent their cards from being the best they could be. So, a nVidia card is generally always better than its ATI equivalent for many, many months (if not years), until ATI gets the drivers for it fixed. By that time, something much better has come out on the market, so it doesn't really help much.
AMD's are not good CPUs at all. They tend to burst into flames when they overheat, where as Intel CPUs do not. If the CPU fan goes out, most AMDs will begin smoking, and can take out the motherboard with them. Intels generally do not do this. Also, Intel CPUs are always more powerful than their AMD equivalents.
Quote:
The game already has the logic implemented. That's how it is able to display the message that a ship can have one bridge and prevents you from creating a ship design with more than one bridge. That's the whole point of this complaint. There is no logic or data file search changes required. It would just be a simple change to the user interface.
A ship can have exactly one bridge. If you try to build a ship with more than one bridge, the game prevents it. So, once you add the bridge to the ship, don't let the user add it again. If you *do* let the user add the bridge again, then you are just wasting their time.
|
Actually, no. Those things require vastly different code functions to perform. Filtering out all possible bridge components would require a lot of search function coding that does not exist. The program would need to be altered to find all components with the bridge ability, and then a "greyed out" function would have to be completely written from scratch. This requires a lot of time, and there are far better things that MM's time could be spent on by this. Ideally, the game would be able to do this sort of thing. But as a matter of practicality, the degree of the problem is very insignificant as compared to the amount of time and effort required to write brand new code to "fix" it, and then to test it thoroughly. It has nothing to do with laziness and everything to do with living in the real world, where time is not infinite.
Quote:
Originally posted by Phoenix-D:
"Okay. Let me clarify to say that I want a feature that warns me before I leave the queue that some of the items will never be built. Once again, this is just basic UI design. You don't want to hide a message that could potentially cause the user a great deal of frustration. Just telling the user that the top-most item will be repeated would be adequate if the Last thing you clicked was that button. But because the program allows you to fill the queue *after* the button is pressed, there is a valid need for additional informational Messages"
This addition would very quickly get incredibly annoying, and IMO is only good until you figure out this portion of the interface- which isn't at all hard. After that, you just say "I KNOW that, stop showing me this damn box!"
|
I was going to make an argument against this, but Phoenix' works rather well.
Quote:
It is a new program feature that stops repeat building facilities when the planet is full. So, yes, in that one case, it makes sense to have more than one items in the queue with repeat build turned on.
|
Yes, a new program feature that requires a lot of time and testing to make function, and is not worth the end result. Maybe you should try to become a programmer, and then you can learn all about the problems doing such a thing imposes.
Quote:
In all other cases, I would still disagree. Why would you want the game to make it easier for you to add an item to the queue that will never be built?
|
Because I want it to be very easy to add an item to the queue. Should the game give you an error message warning if you add a ship to a build queue that you can't afford to pay to build this turn? Absolutely not. A game is not supposed to compensate for bad decisions made by the player. Otherwise, you could not lose. What is the point of a game where you always win?
[ February 23, 2003, 23:19: Message edited by: Imperator Fyron ]
|

February 24th, 2003, 05:11 AM
|
 |
Captain
|
|
Join Date: Jan 2001
Location: Texas
Posts: 830
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: UI Glitches
nVidia makes the best mid-range video cards and out sells ATI by a very good margin. Currently, ATI makes the best high-end card. nVidia's card came out six months late, isn't really faster than ATI's high end card, sounds like a vacuum from a room away. Oh, and nVidia has already said they aren't even going to mass produce it.
Your statements about AMD chips are just ridiculous. Where the heck did you get that hilarous stuff from anyways? AMD and Intel *seemed* to be competing pretty good. In fact, right now the best bang for the buck chip *is* an AMD. But Intel is pulling away from AMD, and it seems pretty likely that the best bang for the buck may soon return to Intel.
I guess you forgot to read my post below where I tested the bridge functionality. I added it to the Rock Colony and couldn't create a ship with two of them. So then, it comes down to personal preference. You probably would rather play around with the design and possibly add three or four or one hundred components to a ship that in the end can't be there. Myself, I would prefer that the game indicated to me that I can't successfully create a ship that has two components that have the bridge functionality.
If you want to argue on an reasonably intellectual level, it is your job to refute my aforementioned argument. By dropping it, you show either that you forgot to read it or you just didn't understand it.
I find it extremely offensive that you are willing to say that you are the final judge of what is a good use of Malfador's time. I am simply making suggestions that might transform this from a "niche" game to one that might have hopes of selling as many copies as one of the MOO series.
The key problem with Phoenix argument can be found by comparing it to the number of on/off settings already provided by the game. Some folks find it annoying that the game warns them before they delete the top item from the queue. That's why Malfador added the ability to turn that feature off. Why did they add that warning in the first place? They added so that you won't spend 17 turns building a ship with a Grav. Resonator I and then accidentally waste 17 turns of production when you delete the ship from the queue.
As to your comment about me being a programmer: Why don't you take a look again at the user contributed utilities on your SEIV CD? You might just see my name staring back at you.
Your comment about the game not allowing you to add something to the queue that you don't have the resources to build is ludicrous. I find it ironic that you would make such a laughable comparision while siding with SJ in dismissing my MS Word software usability arguments.
Yep. I think that Last comment is the same as comparing an apple to a mattress. 
|

February 24th, 2003, 06:19 AM
|
 |
General
|
|
Join Date: Nov 2000
Posts: 3,013
Thanks: 17
Thanked 25 Times in 22 Posts
|
|
Re: UI Glitches
Quote:
Originally posted by raynor:
Myself, I would prefer that the game indicated to me that I can't successfully create a ship that has two components that have the bridge functionality.
|
It does. It tells you that the ship has too many.
Quote:
Your comment about the game not allowing you to add something to the queue that you don't have the resources to build is ludicrous.
|
No, it really isn't. The queue also allows you to add items with a completion time of "never". Should this be removed?
|

February 24th, 2003, 08:34 AM
|
 |
Major
|
|
Join Date: Aug 2000
Posts: 1,246
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Re: UI Glitches
Problem with ATi cards is that their drivers have sucked -- a lot -- but its getting better. I rather prefer Intel and nVidia myself.
__________________
When a cat is dropped, it always lands on its feet, and when toast is dropped, it always lands with the buttered side facing down. I propose to strap buttered toast to the back of a cat. The two will hover, spinning inches above the ground. With a giant buttered cat array, a high-speed monorail could easily link New York with Chicago.
|
Thread Tools |
|
Display Modes |
Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is On
|
|
|
|
|