New construction tool(idea)
Some know that here i made stacker tool for gmod i ws wondering if it is possible to make one for tribes.. I was imagening that it would work like this:
Player gets stacker tool
Player deploys 20x20 pad
Player aims to pad whit stacker tool
Player sets stacking height to 8 meter
Player fires and there is pad on 8 meters height from original pad
What you say? Or is it even possible
Also answer to vote poll
Player gets stacker tool
Player deploys 20x20 pad
Player aims to pad whit stacker tool
Player sets stacking height to 8 meter
Player fires and there is pad on 8 meters height from original pad
What you say? Or is it even possible
Also answer to vote poll
Comments
Do you think I should make it right now?
it sounds pointless
Especially if the X & Y axis remains the same so you dont have to move the 2nd or 3rd etc... to line up the pieces.
How bout a cloning tool? You spend time to get a piece just right then realise you need 6 of them. hmm...
I think you just like to gripe at us.
What's pointless is you telling us all how/what to build and why.
The editor tool is still broken, by the way.
Whats it with you and spewing forth oddities? (my new favorite phrase)
How is it pointlessly difficult? Well... let's take a look at it from the user interface perspective.
As a construction player, we have easy access to four mode selection hotkeys, two activation hotkeys, and four degrees of freedom for movement.
Two of those mode selection hotkeys, and one of the activation hotkeys are reserved for deployables. The same resources are available for tools. Both deployables and tools can take advantage of the 4DOF.
The selection hotkeys are the most constrained resources, while the 4DOF is the least constrained resource. Further, a well designed tool accomplishes its goal by using the fewest resources, and the lowest constrained resources that it can to accomplish its goal. The more constrained resources you are required to use through the design of the tool, the less user friendly, and the less effective the tool is.
So, let's take a look at a few of the examples in Construction:
Firstly, the Construction tool itself. The two selection hotkeys are used to select a tool mode among a hierarchical menu of about a dozen options. It requires at worst 8 hotkey presses to switch between any two modes -- interestingly, most of the highest keypresses are for activating the group rotation functionality, which unsurprisingly is the least used capability of the tool. The tool additionally provides a limited use of the 4DOF in the simple rotation functions -- where you hit a piece controls the axis of its rotation (and importantly, you don't need to know which axis is which).
Next, we can look at the merge tool, and its later, officially sanctioned evolution into the Merge/Isometric/Split Tool. Initially the merge tool used only the 4DOF and the activation capabilities to perform its task. You would select two objects by clicking on them and they would be merged, if it was possible. With the MIST, a hierarchy of functions was added where no more than 4 hotkey activations were required to reach standard tool functionality. I specifically enabled an accurate and effective automatic axis selector for the split functionality using the 4DOF input, so only the first two of 8 split modes would really be necessary. In those auto-axis selection modes, where you hit a piece to split it matters. Since moving the mouse around is less user resource intensive than pushing hotkey buttons, people almost always rely on those capabilities. Additionally, the auto-axis selection is axis agnostic, so users don't need to know which one is X, Y, or Z. The advanced functionality is available for those who do wish to use it.
Further, we can look at two iterations of my ECM texture tool. The first iteration used one selection hotkey for the forward texture list operation, and the other for the reverse texture list operation. With 54 textures available, it would require, 27 keystrokes amortized over standard use per texture switch operation, with a maximum of 53. After user testing, it became extremely obvious that this number of keystrokes was excessively unusable. I switched to a hierarchical form with 6 major categories, with an average of 9 textures in each category. This meant that maximum hotkey distance between two textures reduced to 14 keystrokes, with average considerably smaller. Usability increased substantially.
Now... up to this point, the only non-discrete operations that happened as part of these tools were the rotation and auto-axis selection features. Everything else was unaffected by individual object topology. Does moving or resizing a piece fall into a discrete operation like texturing, or is it a more fluid operation?
I would argue that they are more fluid operations. When we look at a space that we want to fill, we as humans don't think of it in terms of quantitative linear space projections. We look to fill a space, visually, with an approximation in our brain about length. When we are forced to use a quantitative value in these situations, our approach is heuristic -- we guess and correct our guesses until the results become satisfactory. If we have reference points, those guesses can be very good, but we must still carry out those mental calculations, and the fill action attempt.
In the case of chat commands for changing the size of an object, or shifting it about, the calculation is followed by a long action of typing/editing a command and sending it to the server for processing. If we know exactly how we want the piece to look, such a method is pretty much ideal. However, as humans, we rarely think in terms of virtual meters without reference guidance from similar objects that are close by. In those cases, the test and evaluation of our guesses must happen quickly. The 4DOF capabilities that we have as part of mouse input is ideal for making small adjustments if we have rapid visual feedback. That sort of eye-muscle loop is what the human brain is designed to do. In the absence of that feedback, and with clunky ineffective input, the tool will never feel natural.
So, I've described why it is difficult, but not why it is pointlessly difficult.
What information do you get as a programmer writing a tool like the editor tool? You get the player's position. You get the object's position. You get where the player hit the object as part of the raycast. You even get where the player is facing. You get a crap ton of special spatial mathematics functions as part of Construction. Why the hell would you ignore this information when you could put it to such good use in a tool for moving objects? Why do players need to know which axis is which for scaling or shifting a piece? Why does the hit point on the object make no difference on the functionality of the tool? Why is there no real-time fluid calculation of translation/scale distance?
The modifier tool, and your editor tool rip fail to take advantage of all of this information. You use 4DOF only for a binary, discrete selection of objects. You use mode selection hotkeys so much that anyone who calls it easy to use must be blind. You waste the user inputs that give the most information with the least effor. You overuse the user inputs that give almost no information with the most effort.
It's difficult to use because you are trying to fit discrete mappings of an operation that is intrinsically fluid. It is pointless because all of the information to make it better is being ignored by your tool.
The ECM editor tool was a 48 hour project from start to current state. Yes, I know I have some rather uncommon capabilities in these areas, but you cannot possibly think your editor tool is anything close to acceptable. I'm sure anyone who really applied themselves could figure out how to create a tool similar to mine.
It is about asking the right questions of yourself and of the problem you want to solve. It is about user experience, and maximizing effectiveness by using all information that you can.
It is NOT about pointless tools like the one suggested in this topic.
It's interesting to wonder as I read it (because its 1:41 am and i just finished watching a somewhat scary movie and wants to sleep soundly) whether you thought about the ui decisions before the fact or just saw that it happens to fit the certerias just now
that said, there are some things where exact precise movement is preferred, or when spacial input is non-ideal. For one, although people think in a relative imprecise way, the building system in t2 is essentially a 0.5m grid (if you use LSBs), and it is not difficult to think in terms of objects as residing in the grid, and having a generally good idea of where objects need to go. so it shouldn't be too hard to move ojects around in 0.5 meter intervals.
It also is a problem when you can't physically give the spacial information. Say you want to move a piece up, but there's a pad above and below making it impossible for you to actually hit the faces that has the right normals... in that case spacial information is useless since its impossible for you to give it.
Another problem is unpredictability, i never ever used the auto-axis split feature because half the time it does the split ont he wrong axis. Maybe its because i don't know the mechanism behind how the axis is chosen, but there isn't any handy documentation system that explains it to me. So i always end up relying on manual axis selecting.
Rotation tool suffers from the same unpredicatbility problem, sometimes you want to push a beam up and it rotates around its axis.
Adv. Rotate system is not used very much mostly due to its complciated setup time and inaccurate results. you need to place the center of ratation exactly, and you'd probably have to measure it out with beams, that takes time. you have to select each object individually, that takes time. You make a mistake, you are fucked and you are eithe rleft with a blob of pieces in a bad place which you might recover from and start over, or you have to get rid of the errant pieces.
One of the major factors i see with a more rigid system is the ease of undo-ing. If you kick something 0.5 meters in the z direction, it is pretty trivial to see what you have to do to undo it (0.5 meters in -z, or -0.5 meters in z). whereas it is hard to generate an inverse to a spacial input.
"i hit the end of the beam a bit off causing it to rotate on its axis instead of its base by accident, now i need to somehow hit the beam at a bit off in the other way so it rotates back, oops oh fuck i pushed it by accident, let me just restart"
or, "okay let me slide this piece over here.. fuck i accidentally set it before i finished moving. lets see... it slid by 1.231293 meters.. so i need to slide it by 2.76871 meters to complete my move... okay.. 2.753... 2.783... 2.772... fucking why can't you get to 2.76871?!!"
these are basically the 3 major problems i see with spacial input schemes.
unable to specify exact, accurate values
unable to specify the desired value
unable to enter the inverse operation for undo
I already did, just for fun. Although it's not exactly like yours and it has a few "quirks." I never released it because I didn't get permission from you to take your idea and duplicate it. So, the weapon code is gone, but I still have the manipulation function.