Editor improvements

[raptor]

Hi all,

We wish to get a feel for what the community thinks would be the nicest features, improvements, or fixes for the bitfighter editor.

We traditionally make minor improvements/fixes for each release; for instance, for 019 we've done (so far):

• Level database upload
• Several Lua API changes and support for more complex scripting as well as a plugin panel (F9)
• Fix most problems with annoying migrations of Turrets/FFs
• Better UI and input handling of the various menus
• New rotate-about-center-of-selected-objects actions
• Other bugfixes, etc.

So the question I propose to you is: What's missing?

I welcome both quality *and* quantity of requests/responses, but be aware that the Editor is incredibly complex and we'll still be moving at a slow rate of improvement.

Hi all,

We wish to get a feel for what the community thinks would be the nicest features, improvements, or fixes for the bitfighter editor.

We traditionally make minor improvements/fixes for each release; for instance, for 019 we've done (so far):

• Level database upload
• Several Lua API changes and support for more complex scripting as well as a plugin panel (F9)
• Fix most problems with annoying migrations of Turrets/FFs
• Better UI and input handling of the various menus
• New rotate-about-center-of-selected-objects actions
• Other bugfixes, etc.

So the question I propose to you is: What's missing?

I welcome both quality *and* quantity of requests/responses, but be aware that the Editor is incredibly complex and we'll still be moving at a slow rate of improvement.

Smells like a release is coming...

OK here is what I think.

1.Save as option for maps.

2. Load map option.

3. Load new map option (more then 1 map at once?)

4. New Map option.

5. Have the level editor grid above all objects. (try placing a large zone then placing a object at coordinates 7,13)

6. Have all zone types be placed below all other objects in the level editor. (problem of trying to places objects in a large zone.)

7. Replace all rotate around 0,0 commands with a fixed point rotation system.

amgine

[Quartz]

OK here is what I think.

1.Save as option for maps.

2. Load map option.

3. Load new map option (more then 1 map at once?)

4. New Map option.

5. Have the level editor grid above all objects. (try placing a large zone then placing a object at coordinates 7,13)

6. Have all zone types be placed below all other objects in the level editor. (problem of trying to places objects in a large zone.)

7. Replace all rotate around 0,0 commands with a fixed point rotation system.

amgine

1. I really like this idea.
2. Pointless.
3. Neutral.
4. Pointless.
5. Can you elaborate on this one, amgine?
6. Heh, yeah, the layering is exceedingly random and difficult to work with. Some solution there would be handy, though I'm not sure how to do it. Good idea.
7. NOOOOOO, GOD NO. Rotating about 0, 0 is fine. It's uniform, it's consistent. Anyone who wants to do away with rotating about the center seriously needs to consider that their methods might be the problem, not the editor.

As usual, I got nothin'. I work with the tools I am given and I don't believe I am very limited ... of course, for all I know, I *am* limited in some way, I just don't know it yet! I remember thinking the Zap Editor was good, hah. Wow was I wrong.

I would really like a negative-number function for the projector/turret regeneration. Not sure if that's an editor request though, lol.

2. So you dont have to quit to lobby then go back in to load a map.

3. Creates a brand new map template so you can be creating more then 1 map at once.

4. Loads another pre existing map so you can be editing more then 1 at once.

5. Have the level grid be displayed above all other objects : when a zone is placed (or any other item for that matter) you cannot see the grid on that part of a map ie making it hard to place a item on say 5,9.

6. Problem with rotate around 0,0 is on large maps the item will warp 999,999 coordinates away from where you need it to be placed at least add some sort of better clarification then?

Btw quartz why would turrets losing health over time be helpfull it deosnt seem very usefull to me...

quartz - that's... actually a really cool idea. Strengthens the importance of repair. But, I feel that as weak as turrets and forcefields are, degeneration would worsen their value tremendously. What do you think?

raptor - Has there been any dev discussion on the potential for art objects (colored poly shapes and lines) in 019? Last I checked the biggest hurdle was figuring out how to differentiate goal and loadout zones to appear different visually so as to not confuse users. I think this deserves more discussion - there are lots of potential solutions for this including checkerboard/striped/pattern, flashing/glowing, thicker vs thinner borderlines, etc.

My thoughts:

1. I'd like to see improvements to text in Bitfighter. Text editing is kind of a pain since there's no cursor to select and modify different parts of text. If I write out something with the text line tool and make an error, I have to spam delete button and reinput everything just to fix something minor.

I should be able to press the left or right arrow key to move a flashing underline cursor left or right to change different parts of text. This is a basic upgrade. Ability to highlight then modify text - used via mouse - would be ideal but I realize it's more complicated.

(Worth noting - I bring this up because text difficulties are most apparent in the level editor, but it does affect the entire game. Typing in chat, for example, would benefit greatly from a cursor.)

1b. Along with this, I'd like to be able to type a variable instead of scrolling to it in applicable fields. For example, setting speed of a speedzone should be accomplished not by holding the left or right arrow key, but by typing in a few numbers. There are a lot of editor functions that rely on using the left and right arrow keys for changing variables and it's (a) time-consuming and (b) often incapable of producing a precise value. Text entry would fix both issues.

1c. I would also like to see the option for multiple lines in a single text object. Shift + return to enter a new line, perhaps.

2. Color wheel for specifying team colors. Having to hold R / G / B is a bit of a pain, especially if I missed first grade and have no idea what combination of colors makes what. No, seriously, I attended first grade but color matching still baffles me, let alone trying to wrap my head around R / G / B.

3. As amgine and quartz said, a simple layering tool would be a huge help. Let me determine if a zone is to overlap a wall or underlap (is that a word? you know what I mean). You can keep the automatic layering for new users, but for advanced level editors manual layering should be a thing.

4. Minor issue but it's bothered me for some time - on the initial level editor selection screen, we should be able to scroll vertically through a list of maps to edit (or choose to create new) instead of having to hold down the left/right arrow key to navigate.

Thanks!

[raptor]

@sky_lark

Good news! kaen has already done your #1(a) and watusimoto has done your #4.

agreed #2 still confueses me to this day if it was RYB it would be easier but RGB is confusing.

also agree with 1b tpying makes things easier and gives more varity.

[kaen]

And to alleviate #3 I wrote a fit-things-to-other-things plugin (which uses the "scissor" lua API) so that you can avoid the need to have things overlap in the first place. I know that's a not a final solution, but layer support is a bunch of work for this late in the cycle.

[raptor]

Object layer support is an extremely significant change to the bitfighter rendering engine. Much more thought would need to be put into it and it may even deserve its own topic.

so version 19a then or version 20?

Sweet, half the suggestions I make have already been accomplished by you guys haha.

@amgine My point was that the system for choosing colors - having to perform trial and error to find an accurate color - needed an overhaul. Changing R G B to R Y B wouldn't alleviate my complaint, even if it did become a little easier to use.

@kaen How similar is that to vertex snapping? Snapping is mostly good but I have had some difficulty with it in the past.

@raptor/kaen Fair enough, thanks for the feedback.

[kaen]

@kaen How similar is that to vertex snapping? Snapping is mostly good but I have had some difficulty with it in the past.

It is essentially automated vertex snapping. In fact that's such an accurate description that I'm going to rename it Autosnap.

[watusimoto]

A couple of responses to various random posts.

First, you can do Save As (mostly) -- hit F3 and you can change the name of the file in which the level will be saved.

As for specifying layer order, I see no legitimate reason for this. We already order by big > small so, for example, a repair item does not get covered by a loadout zone. But other than that, loadout zones and goals, for example, should not be overlapping, so layer order is unimportant. The only use cases I've heard are borderline abusive, like trying to hide walls beneath a loadout zone. Yuck.

Entering numbers in a number input (rather than using up and down) is something I've been thinking we should do for a while.

Multiple lines in a text object could probably be accomplished by using \n as a line separator; we already have code for parsing and rendering multiline strings, so it should be relatively easy to make that happen.

Finally, you can use one of a zillion online tools like http://www.colorpicker.com/ to get your rgb values if you get confused. This isn't a particularly good one, but is the first I found. Even better, stick with the basics. There's a reason why they're easy to choose!

[Skybax]

Yeah RGB is super easy if Google is your friend :3
I think the best thing to do is search the hex code for a specific color, and then find a hex to RGB percent converter. Although I think it's going to be changed from percent to pure RGB? So that will just make it easier lol

[Quartz]

Just gonna say R Y B is the worst idea I've ever heard. We're dealing with pixels on a screen here; that is *light.* Light works in R G B. Paint works in R Y B. We are not painting our computer screens now are we?

Anyway, sky's color wheel idea is pretty good.

instead of a color wheel how about a full blown color picker option?

The problem with R G B color input isn't that it's hard to determine a color's value (well, mostly not that), but that it's a very unintuitive method for choosing a team color.

Think about it: Having to hold R G B keys on your keyboard - one at a time for several seconds each - versus clicking the color that looks good right away. Color wheel does the job in a millisecond, is super easy to change, and can be narrowed down to a precise color without difficulty. Let players use their eyes to pick a color and make the machine do the work of assigning a RGB value.

Using a tool out of game is awfully inconvenient, but I suppose it would work as an alternate solution.

@amgine could you elaborate? What would a "full blown color picker option" look like, and what advantages would it have over a color wheel?

[watusimoto]

We are not painting our computer screens now are we?

Uhh... maybe I've been doing it wrong.

[watusimoto]

the best thing to do is search the hex code for a specific color

I made a case yesterday to look at allowing hex code color inputs. I think we'd want that regardless of whether we implement a color picker of some sort.

[bobdaduck]

I think we'd want that regardless of whether we implement a color picker of some sort.

For a community composed almost exclusively of 12 year olds?

[Skybax]

I think we'd want that regardless of whether we implement a color picker of some sort.

For a community composed almost exclusively of 12 year olds?

http://www.computerhope.com/htmcolor.htm
Google is soooo eassyyyyyyy... even a 12 year old could do it

[Quartz]

We already have nobody playing this game. Making it less intuitive isn't going to draw more players in.

It's unintuitive at first because the GUI doesn't at least show you the many screens, or at least link to them. Some people like to work with mouse first, until they learn the hotkeys

e.g.put the following in a bar
Configure Teams screen
Instructions (Pg 1, 2, 3, 4)
Should all be available in a help area within the editor itself.
Changing teams, should be like the walls skinny thing - at the bottom in a small text that says,
hit 0-9 to change teams. Shift + 0 makes hostile.
Let the player try to change team, and when he discovers that teams aren't set, he will try to figure out how to add teams himself. Just that little hint will prompt him.

Some stuff, like making walls skinny is intuitive, bcus the first time you click on a wall you made using right click you see the options for - and +
But making polywalls smaller (scaling) is a hassle. You need to hit three hot keys - ctrl shift x, first of all. then you need to type it in exactly. in my case .9
plus you have to memorize that, no, you did not do this wall yet.

Then making walls in the first place, takes a while. So you have to right click to start placing them, and left click to finish? Be thankful nobody's using those mac one click mice anymore
`click took me a while, I had to ask to find out. I DID read the instructions, but I don't really pay attention. I only knew about it because I saw bittown had lines that you could drive over

[Quartz]

Then making walls in the first place, takes a while. So you have to right click to start placing them, and left click to finish? Be thankful nobody's using those mac one click mice anymore

Heh, I remember back in Zap days when I did. I got real used to having my hand over the CTRL key. CTRL+Left Click = Right Click

As far as the color wheel goes, for reference, the consensus prior to forum wipe was that (a) it would undoubtedly improve the easiness of adding new colored teams but (b) that easiness may not warrant the effort of development given the effectiveness of alternative solutions (ie. googling for rgb codes) and (c) there was concern that it would encourage players too much to use abnormal colors.

However, I still think there ought to be a better medium for color selection. I brought up the color wheel not because I wanted more colors - or more people to use more colors - but because the system of holding R G B for several seconds is really primitive. Googling rgb codes doesn't solve that issue. There's got to be a better way to input rg codes faster.

Entering numbers in a number input (rather than using up and down) is something I've been thinking we should do for a while.

This would be one solution.

[bobdaduck]

What if we just forced everyone to go into the .level file and open it in notepad and manually type in the numbers? That seemed to work okay back in the day.

In half seriousness, Zap! was the most unintuitive thing ever, and it still had a fair amount of players.

Oh! Will you be making inertia placable? Also change the text to perhaps something different looking? (Since you're doing a gear for load outs and flag for goals!)

Oh! Will you be making inertia placable? Also change the text to perhaps something different looking? (Since you're doing a gear for load outs and flag for goals!)

[Inertia being slipzones, for clarification]

[watusimoto]

Probably not -- I consider SlipZones to be a failed experiment. Unfortunately too many people found out about them and now it's hard to kill the feature.

Please don't remove them, I have a level in my sig that's working a lot better with them, and I feel it's my first quality level too. Just made it and I am happy with how it turned out.

I understand if they are spammed it's bad. But the same with turrets, repairs, etc. But I found a perfect time and place for them:)

yeah some levels like figure 8 and nascar are fun.

slip zones ere to slippery if they had less slip they might work better.

slip zones ere to slippery if they had less slip they might work better.

Wouldn't that defeat their purpose?

edit: I mean... if you made them any less slippery, to the point where you had traction, it'd lose much of its appeal, and to be honest, would get annoying fast.

[watusimoto]

Actually, we've developed a invisible slip-zone with no slippiness whatsoever, and since 018a, they've been randomly inserted into most levels. Seems that no one has really noticed!

Actually, we've developed a invisible slip-zone with no slippiness whatsoever, and since 018a, they've been randomly inserted into most levels. Seems that no one has really noticed!

[sam686]

New rotate-about-center-of-selected-objects actions

I don't think many people want it to rotate/flip around center-of-selected-objects. Selecting only one point item (spawn point or health item), and then rotate/flip center-of-selected-objects effectively does absolutely nothing.

Better idea may be to flip/rotate around the mouse cursor, makes it easier to choose where it rotates.

[Quartz]

We already have rotating about 0,0 ... I really don't understand why could we possibly need anything more. -_-; It's not like you could accomplish anything more or less with some other form of rotation.

[kaen]

We already have rotating about 0,0 ... I really don't understand why could we possibly need anything more. -_-; It's not like you could accomplish anything more or less with some other form of rotation.

A new user in 018a hitting R doesn't expect his objects to change their center position. That's not the behavior of any other "rotate" function in any other program.

Also, you have an error in your terminology. 018a revolves objects when you hit R, it doesn't rotate them. The earth rotates every 24 hours but takes a year to revolve around the sun.

Finally, you actually have both features in 019, we just bumped the old R function (revolution) to Ctrl + R or something like that.

We already have rotating about 0,0 ... I really don't understand why could we possibly need anything more. -_-; It's not like you could accomplish anything more or less with some other form of rotation.

Inconvenience, really. I don't want to drag every object I need rotated (or revolved...? Fuck it, I'm an arts major) to 0 0 and then back to its proper spot. Way more convenient and efficient to have it done around a vertex in the item or my cursor.

[Quartz]

(In all seriousness I'll get used to it, but it WILL take some getting used to.)

[watusimoto]

Someday, hopefully someday soon, you'll be able to remap keys in the editor. It's an easy but time consuming project that just needs a volunteer! This would be a good learning project for a self-motivated person who wants to dip their toes into the C++ universe.

[Skybax]

Someday, hopefully someday soon, you'll be able to remap keys in the editor. It's an easy but time consuming project that just needs a volunteer! This would be a good learning project for a self-motivated person who wants to dip their toes into the C++ universe.

I feel like you've said this before.

[watusimoto]

I have, and some of the internals have been done. We just need to find the worker bee willing to take on the job.

[Little_Apple]

I might be able to do it, just need to sort out some things with xcode.

I would do it, but learning the UI is gonna be a pain ._.

I would do it, but with absolutely no knowledge of C++, I'd probably spend twenty minutes doodling around with Hello World, then go eat a cookie.

I would do it, but with absolutely no knowledge of C++, I'd probably spend twenty minutes doodling around with Hello World, then go eat a cookie.

+4984

[Skybax]

I took a C++ class in highschool, but I almost failed it cause my teacher was a total idiot that had no idea what he was teaching.

But I do love coding lol

I would do it, but with absolutely no knowledge of C++, I'd probably spend twenty minutes doodling around with Hello World, then go eat a cookie.

+4984

[watusimoto]

learning the UI is gonna be a pain

No doubt, but there is relatively little UI work required for this. The task consists of 3 major parts: getting the keybindings into the INI, using the INI values in the editor, and updating the help.

The help updating is probably the easiest part, due to improvements we've made for the 019 upgrade. The hardest part will probably be figuring out what all the keybindings are, where they are used, and coming up with good names for the INI variables and such.