Bitfighter 013 beta 4 released [[WINDOWS & OS X]]

[watusimoto]

This is pretty much the final product for 013. There's still a couple of things to get straightened out, but this is basically it.

Download here

At this point, it's Windows only. I've contacted Ryan to ask him to build this for OS X, and I'll be getting a Linux build going soon.

This features a modified installer for Windows that should put the various files in more standard Windows locations. Please let me know if this is an improvement over previous versions that put user modifiable files in the install folder.

Large chunks of the editor had to be rewritten to support NavZone editing, which is much better than in previous versions, so pay particular attention to the editor. I'll be posting a full change log soon so you can know what to looking for. This will be a very big release.

If you find any bugs, post in the 013 Pre-Release Issues forum.

[Unknown]

I'll say the navmesh editing is better. The only other thing I'd want with it is the capability to snap to wall edges.

[watusimoto]

Wall snap is enabled when you are working with various zone things, turrets, and forcefields. Other things make less sense to snap to wall edges.

[watusimoto]

List of stuff that changed since 012, only partially ordered

Big changes

• Added energy item
• Added ability to add arbitrary linework to levels, complementing existing text. To add lines, hold ~ and right-click.
• Started trasnsition of Join menu into Game Lobby
• Started developing framework for remote server management
  
  Smaller changes
• Added Restart Level to game options menu if you have level change permissions
• Moved Add 2 Mins option to LevelChanger permission level (with older servers you'll still need admin rights)
• Added asteroids, testItems, soccerball, and resourceItems to help screen, enhanced instruction colors
• Fixed several in-game crashing issues
• Minor efficiency improvements on rendering routines
• Retrieve games now allow non-team flags
• Bouncers now do half-damage to shooter, rather than full as in previous releases
• Triples no longer damage shooter
• Password entry in INI file now changed to ServerPassword -- if you use this, you'll need to manually update your INI file
• HuntersFlagItem can no longer be used in level files. Please use FlagItem -1 instead!! Note that this line is only present in hand-modified level files
• Min/max player level params now used when selecting levels
• Slight improvement when rendering walls joining at acute angles
• XBOX controller on windows now much better supported
• Bot nav mesh zones can be displayed in-game by using /dzones command
• Soccer ball now warps back to starting point rather than "drifting" back
• Loadout/weapon indicators now more "vector graphicy", colors no longer botched on Vista/Win7
• Infrastructure in place for goals with different values -- only need editor UI and level file syntax
  
  SFX
• New sound when ship hit by projectile
• New sound when using GoFast
• New SFX when players join/quit game
  
  Bots
• Added enhanced timer class to Lua scripting
• Moved some "unwrapped" functionality into main() function
• Renamed getMove() function to onTick() ==] existing bots will need to be updated
• Fixed module "always on" bug
• Fixed "shoot through shielded robot" bug
• Event manager now working. Can now add game events easily.
• Added ShipSpawned, ShipKilled events
• Added ship:isAlive() method
• Return nil rather than dummy value when method called on dead ship (e.g. in 012, ship:getLoc() returned 0,0 if ship was dead, now returns nil)
• Got rid of NexusFlagitem --] Now all flag are FlagItems, for all games
• getName() function now run first, so game will have bot's name before any real game logic gets run
• Created Player object with info about individual players/bots which you can get from Ship, GameInfo, and TeamInfo objects
• Restructured the way bots are initialized so that all bots are loaded and getName()s are run before any main() functions are run
• Can now pass arguments to bots from level file using arg struct, just like with levelgens
• Robots now shown on scoreboard and in various menus where players are listed
• Robot names are now "uniqued"
• Overrode Lua's random generator to use one that's a bit more... random
• Added setAngle() and setPolar() methods to point object
  
  Editor
• Many small improvements to editor
• Fixed editor crashing issue caused by double-delete of item
• Fixed editor crash while caused by pasting objects in the middle of a drag operation
• Undo/redo more efficient -- will perform better with large levels and deep undo states (and will no longer crash!)
• Added autosave -- will keep a current copy of the level on disk in the event of a crash (though crashes are much rarer now)
• Ctrl-left click now starts a wall
• Can now add arbitrary line items in editor: hold "~" while right-clicking to start
• Editor remembers name of last edited file
• Ctrl-A can now be used to hide navMeshZones
• Improved preview mode (when holding Tab key)
• Text in editor now subject to same min/max size constraints as text in the game
• Team names can be changed in the editor
• When moving, items now snap to grid based on vertex closest to cursor, giving much greater control over placement. Snapping vertex highlighted in magenta.
• Can now snap items to other items, not just to grid
• Hovering over an item no longer counts as selecting it
• Increased readibility of node numbers on selected lines/polygons
• Holding tab now only shows range of selected turrets/spybugs
• When editing navMeshZones, non-convex zones rendered in red to indicate potential problems
• Improved snapping of nav mesh zones, including rendering of connections between zones
• Grid fades when grid-snapping disabled
• Changing wall widths is now undoable
• Arbitrary scaling of selected items now works with Ctrl-Shift-X
• There are now multiple edit modes (normal, bot nav mesh zone mode, etc.) customized for different purposes -- use Ctrl-A to toggle
• Switched H and F key assignments -- F now inserts forcefield, H flips selection around horizontal axis
• Holding shift while panning causes pan speed to increase -- good for larger levels at higher zoom scales
• Improved coordinate display on dock -- now shows coords of snapping vertex when dragging an item
• Editor now starts with (0,0) centered on the middle of the screen
  
  Server management
• Added /shutdown, /setlevpass, /setserverpass, and /setadminpass chat commands (see in-game help)
• Added /setservername and /setserverdescr commands
• Added /deletecurrentlevel command to remove level from remote server (file not deleted, but won't be loaded in future)
• New orderly shutdown process when using /shutdown command (i.e. players notified, dedicated servers can be terminated, etc.)
• If level change password is left blank, all players granted access (not so for admin password)
• If level change password is set to blank, all players currently connected are silently granted access to level change menu
• -password command line parameter changed to -serverpassword
• When all players leave game, game advances to next level, and suspends itself until a player joins. That way, when players join, level is "fresh" and ready to go. May also reduce processor load and power consumption
• Added ability to put game into suspended animation, automatically restarting when other players join (/suspend command)
  
  Linux
• Added ability to specify locations of various resouces on the cmd line. See http://bitfighter.org/wiki/index.php?ti ... ng_folders for details.
  
  Windows
• Windows installer now does a better job of installing files in their "proper" location
  
  Bugs
• Fixed rare Zap-era crash condition when player shoots a soccer ball, but quits game before goal is scored
• Fixed turret/forcefield "in the middle of space" bug
• Fixed textItem bounds miscalculation that caused large text to "jump" onto screen
• Fixed /dcoord display position bug
• Fixed robot bug reporting incorrect team for flags

[Unknown]

I meant wall snap for the nav zones. It makes sense for them to snap to those edges so that you can get a perfect fit into the stage.

Also, what are you talking about with the weapon/module indicators? They look the same to me.

[watusimoto]

You have wall snap for nav zones, as well as other polygonal features (loadout zones, etc.)

As for the indicators, they should now be green when deactivated, and red when activated, with the background not changing color. If you see different, post a screenshot!

Haven't tried out everything yet, but the energy packs look great. Possibly a little too much energy, however.

[C. Bob]

Just a quick note; the "green when deactivated" bit may be counterintuitive. I don't use the loadout indicators, but I know that I usually associate green with activity and things being "on", whereas I associate red with inactivity and the state of being "off". I know that you mean for red in this case to refer to combat activity -- as in red alert and the like and "engaged", whereas green is the pacific "disengaged" -- but I'm not sure I would like it if I was to use the indicators. You might try reversing the colors, so that green is on and red off.

Alternatively, you could have the loadout indicators be based on the player's team's dominant color, with a light shade being the "on" and dark "off".

- Bob

[Unknown]

I still suggest that the indicators not be fills. It doesn't really look good nor matches the rest of the game.

[watusimoto]

They're not filled!

[Unknown]

The indicators haven't changed. I've checked the file version, but it is the 013 beta.

[watusimoto]

Surely not in the most recent beta (beta 2)...

Here is what I see:

Capture.PNG

[Unknown]

Re-downloaded the install again. Installed in same directory. No change. Installed in different directory. No change. Is there something in the .ini that needs to be changed from the last version?

[watusimoto]

OK, something's messed up. When I run from the compiler, it works, when I do a fresh install it doesn't. I'll repackage the game and upload again.

[watusimoto]

Announcing Bitfighter 013 beta 3!

This is the _real_ beta 3; don't be fooled by inferior betas that only pretend to be the _real_ beta 3.

Download here

[watusimoto]

If you've already downloaded and installed Bitfighter 013, PLEASE DO SO AGAIN WITH THE LINK AT THE TOP OF THIS THREAD!!!

There was yet another problem with the packaging, as of yet unresolved, that lead to another incorrect version being distributed. My development machine died a few weeks back, then my backup machine followed into oblivion, then I upgraded to the newest version of Visual C++, and somewhere along the line something's got mucked up.

What's included in the installer this time is a debug version. It's a bit heavier download, and dumps all the logging info to a terminal window, but is otherwise the same thing, and is good for testing.

So, download and install again, and, hopefully this time, all will be well.

This will fix some of the issues users were having in the editor.

[Unknown]

Works well. However, I do have a few issues with the game and editor.

• Repairables already on the map do not auto snap and show their location.
• (opinion) Repairables do not snap to the grid. While it is nice to see what they look like and exactly where they will be, that should only occur when holding tab. Otherwise it should be a schematic. Same goes for the speed zones and teleporters.
• Text items now all display "Your text here" instead of what they were in the text file.
• The walls aren't rendered while I am moving their vertices. While it doesn't cause problems, it does bother me.
• Error pops up when I try to host: "Couldn't find class rep for dynamic class: CTFFlagItem"
• bitfighter.ini gets a default path of C:\Users\<username>\AppData\Local\Bitfighter/levels
• The default path for levels/bots/levelgens should probably be in My Documents for easier access. Having it deep inside the Users folder makes it hard to get to.

Thank goodness for some of the new features though, especially navmesh support. The wall snapping will make the creation of maps with navmeshes much easier.

Thank you for your hard work, Wat!

[watusimoto]

The OS/X version is ready for testing:

Download link

[watusimoto]

In this post, "repairables" = turrets & force fields.

* Repairables already on the map do not auto snap and show their location.

I presume this to mean that the items do not snap when loaded. They should, and this is a bug. Will be fixed in the next beta.

* (opinion) Repairables do not snap to the grid. While it is nice to see what they look like and exactly where they will be, that should only occur when holding tab. Otherwise it should be a schematic. Same goes for the speed zones and teleporters.

Why do you feel this way?

* Text items now all display "Your text here" instead of what they were in the text file.

This is a bug. A stupid bug, and a trivial fix that has now been fixed in my code.

* The walls aren't rendered while I am moving their vertices. While it doesn't cause problems, it does bother me.

It turns out this is really hard to do with the new way we're processing walls internally. Maybe at some point we'll figure it out; in the meantime, I suspect it will stop bothering you when you get used to it.

* Error pops up when I try to host: "Couldn't find class rep for dynamic class: CTFFlagItem"

Was this a new level, or an existing one? I'm guessing old level... if so, try editing the level and changing CTFFlagItem to FlagItem.

* bitfighter.ini gets a default path of C:\Users\<username>\AppData\Local\Bitfighter/levels
* The default path for levels/bots/levelgens should probably be in My Documents for easier access. Having it deep inside the Users folder makes it hard to get to.

This may be so. It is easily configurable by modifying the shortcut you use to launch the app (you can move only the robots folder if you want -- see the wiki section on command line options for details).

If you arguing that the default install location should be changed, well, I'll change it if you can make a case that doing so would abide by some sort of standard practice.

[C. Bob]

I admit I slightly prefer the old style of graphics in the editor, but that's just because of personal preference -- ever since I started making maps (in a much earlier version of BF), it's been based on basically the original Zap editor's graphic style, and seeing that radically change is just tricky to get used to. I don't think the old graphics are necessarily better -- though, one could argue that the moving teleporters make it harder to concentrate when you're in the editor, and that you could think and design the level more clearly without them. The preview feature, in any case, makes it easy enough to see things as they really are. I don't necessarily like seeing everything as it really is in the editor, without holding down the Preview key, but I don't have a very strong feeling about it. I imagine I'd get used to it if it stayed the way it is.

However, the repairables seem more annoying to place than before. The preview feature doesn't always show when they'll show up, for instance. I'm also not at all a fan of the repairables not automatically snapping to grid -- I feel that items should not snap to grid, if and only if the designer holds down the space bar, thus de facto waiving his right to grid-aligned items. It's hard enough making a symmetrical, grid-aligned level as it is without having to look over each and every repairable item to make sure they're placed just the way you want them to be.

Nevertheless, though, it looks like a good release so far, and it will be a great foundation for the further, even more revolutionary changes I hope to see coming in the future.

- Bob

[watusimoto]

the repairables seem more annoying to place than before. The preview feature doesn't always show when they'll show up, for instance.

They should. If they don't it's a bug. I went to great pains to rebuild the editor so it can use the same code for snapping as the game uses when the level loads, to ensure the results are identical. I have yet to find a single instance where there is a difference. If you have a sample, please post it!

I'm also not at all a fan of the repairables not automatically snapping to grid -- I feel that items should not snap to grid, if and only if the designer holds down the space bar, thus de facto waiving his right to grid-aligned items. It's hard enough making a symmetrical, grid-aligned level as it is without having to look over each and every repairable item to make sure they're placed just the way you want them to be.

OK, I buy that argument -- you want to make it easy to ensure things line up nicely, and I see why the wall-only snap makes that difficult. But surely you agree that when the item is not within snapping range of a wall, it hardly matters if it snaps to the grid or not, as the item will be omitted from the level when it loads.

I have an idea that might satisfy you (though it will be tricky to implement...) What if the item snapped to the wall at the point at which grid lines intersected the wall? Then you'd get the best of both worlds -- true location along with the alignment benefits of the grid snapping.

If you like that idea, please post a quick bug report at Source Forge, and I'll try to get it in for the next release. You can just use the text from the paragraph above if you like.

[karamazovapy]

* bitfighter.ini gets a default path of C:\Users\<username>\AppData\Local\Bitfighter/levels
* The default path for levels/bots/levelgens should probably be in My Documents for easier access. Having it deep inside the Users folder makes it hard to get to.

If you arguing that the default install location should be changed, well, I'll change it if you can make a case that doing so would abide by some sort of standard practice.

Why bury it at all? I'm constantly digging through my levels folder, and putting anywhere other than bitfighter\levels is just a pain in the ass. Maybe I'm weird in liking all my "stuff" in one place...or maybe I'm just very Windows 3.1. I dunno. I just don't see the advantage to specifying the install directory and then having to chase down your levels directory somewhere else.

edit:
I also agree that it's more difficult to see what you're doing (specifically where you're placing the box) through the swirling teleporter. The lack of snapping on repairables is frustrating because they slide along axes in ways you don't necessarily want them to during placement. Besides that, it's a little nauseating to see them jump all over the place from surface to surface when you drag your cursor across the screen.

[watusimoto]

I also agree that it's more difficult to see what you're doing (specifically where you're placing the box) through the swirling teleporter.

I suppose we _could_ use a wire-frame non-animated outline of the teleporter in non-tab mode; that would be easy enough.

I'm really not sure what the right answer is for the turrets & ffs... I think the dynamic snapping is helpful, especially to new players. This isn't a technical issue -- using grid-snapped icons would be easy -- but rather a design issue.

[C. Bob]

I don't really see what was wrong with the old system, regarding force fields; as a new user, I think I always preferred things to follow the grid. That said, if you have a system that can consistently preserve old functionality, I'm willing to trust your statement that it will work fine this other way.

Also, although I didn't notice it before, I agree with their statements on the level folder path -- even if it is consistently done that way by other apps (by dumping it in some "application support" folder) that still doesn't mean that it's the best system for this game, or for any game. I've always found it to be a hassle, personally, and would prefer to keep the current default, although if we don't, it still isn't a big deal to me -- I'll just change the bitfighter.ini file to keep it the way it was, the same as I've done with all the other changes I didn't like.

[Unknown]

If players are intended to be able to go and edit files, the standard practice is to have a folder in My Documents. For example, for Bitfighter, the file path for levels should be "My Documents\Bitfighter\levels\".

Schematics are easier to read when zoomed out, and have much less clutter. Having both an arrow AND a teleporter graphic is too much. Also, TAB is, as I understand, meant to show you exactly what it will look like anyways. It doesn't have much of a function if it is already that way.

With repairables, it's probably just my habits that form my opinion as well as the ability to make everything symmetrical.

[watusimoto]

Having both an arrow AND a teleporter graphic is too much.

OK, we can try a green polygon the size of the teleporter in "regular mode" and save the swirling graphic for <tab> mode.

[karamazovapy]

TAB is, as I understand, meant to show you exactly what it will look like anyways. It doesn't have much of a function if it is already that way.

This is how I feel about snapping/not snapping repairables.

Another question to ask about where user files are placed is whether standard windows permissions allow access. Presumably, most people will have gone through the process of changing "ownership" of their system files so they can work with them, but less advanced may not have gone to the trouble of dealing with access and permissions. I think "My Documents" is locked by default in Windows 7, and I think AppData is a hidden, locked, system folder.

[watusimoto]

TAB is, as I understand, meant to show you exactly what it will look like anyways. It doesn't have much of a function if it is already that way.

True, but we should show as much as possible w/o tab, as long as we can do it without degrading usability. The animated teleporters are a distraction, which is a good argument for hiding them behind the tab key.

[C. Bob]

I've tested various force fields, and it seems that they consistently lose their previewability after the level has been saved, once. Also, some inexplicably refuse to snap to the wall, whereas you can try another part of the same wallitem and it works fine.

  Code:

GameType 10 8
Team Blue 0 0 1
BarrierMaker 50 0 0  0 3  3 3  3 0  0 0
BarrierMaker 50 1 1  1 2  2 2  2 1  1 1
ForceFieldProjector 0 2.58431 0.0980392  0
ForceFieldProjector 0 0.901961 0.992474  0
Spawn 0 1.5 2.5
ForceFieldProjector 0 2.09694 1.39744  0
ForceFieldProjector 0 0.424988 2.85857  0
ForceFieldProjector 0 1.48191 0.901961  0
ForceFieldProjector 0 2.90196 2.25637  0
 

If you don't see any problems at all in this, I will take pictures, or a video, to demonstrate the ineffectiveness of force field preview in OS X.

- Bob

[watusimoto]

I've tested various force fields, and it seems that they consistently lose their previewability after the level has been saved, once

Is this the same as reported earlier? ::

* Repairables already on the map do not auto snap and show their location.

I'll load the level later and report what I see.

[watusimoto]

I tested the level fragment posted above, and everything behaves as I expect it should.

[watusimoto]

Bitfighter 013 beta 4 is now available for downloads, windows only.

Fixes 2 bugs: imported text items should be correct, and engineered items snap when loaded from level file.

Also makes teleport a wireframe in normal edit mode, full teleport effects visible in <tab> preview mode.

Download here

[C. Bob]

Even if it works fine in Windows, there are some real problems with the editor in OS X, at least, and I've created a slideshow to demonstrate them.
Slideshow

In picture 1, you see me preparing to place a force field. It is not yet snapped to the wall.

In picture 2, observe (what I presume is) the force field, now on the wall, and most assuredly not snapped. It doesn't even show up as a force field in preview.

Picture 3, I attempt to place another force field, which also fails to snap.

Picture 4, same deal.

Picture 5, I create a new barriermaker.

Picture 6, I place three new force fields on the barriermaker, which all miraculously snap to grid and preview without a problem.

Picture 7, I put another force field on the same barriermaker as where they previously worked, but for some reason, *this* force field isn't good enough, and doesn't preview or snap.

Picture 8, I put another force field right next to the spawn, where it inexplicably snaps to grid and previews without a hitch, even though the last one I did on the same barriermaker did not work.

Finally, although I don't have a picture of this, when I load up the map (as if to play it), every force field works fine, regardless if it showed up in preview or not.

I hope and trust that this will demonstrate my problem.

[watusimoto]

It does, perfectly. This looks like the same issues plaguing the early mis-packaged windows versions. In slide 1, notice the blue interior lines being drawn on the walls. Those shouldn't be there, and are a telltale of the other problems you demonstrated.

So... what is the problem? I'm not sure. I had thought it was particular to my compile/packaging process, but now that they've been observed on other platforms, there is obviously something deeper going on.

Needless to say, those things you observed are clearly bugs, and aren't there in the latest Windows releases. I have not yet tried this under Linux, which will be an interesting experiment.

[Unknown]

Much better. However, I still retain my opinion on how repairables should be done.

[watusimoto]

Well, here's another problem with rendering the engineered items in their "wall-snapped" location in preview mode, while rendering them in their "grid-snapped" location in schematic mode -- and that is where you click to grab and manipulate the item will be different, and how it behaves when you move it will be different. Think about it -- the schematic and preview items could be a fair distance apart when you are zoomed in. Where would you go to grab the item? What if you changed between preview and schematic modes while dragging an item? It gets very complex.

However we end up making this work, I think it is very important that the location of the item in preview mode is the same as in schematic mode. The logical conclusion seems to be that we have to wall-snap the item all the time.

[Unknown]

All I truly care about is that the system in the end is that it is backwards-compatible, and that it snaps in some form so that I can make my maps symmetrical. Any ideas that fit both Wat's requirements and my requirements?

[watusimoto]

By backwards-compatible, do you mean old levels behave the same in the new system? If so, 013 will be completely compatible with 012. I'm going to look for a way to make symmetrical snapping possible -- I think that's a reasonable request.

[Unknown]

By backwards compatible all I mean is that I can edit old maps in the new editor without problems.

[watusimoto]

Well, depending on what you mean by "without problems", if there are levels that can't be edited in the editor that would probably be a bug.