019d preparation - a call for 019c bugs

[raptor]

Hi,

I'm thinking about putting together bitfighter 019d. It's been a while since we've done a release and our 020 code base won't be ready any time soon. This would be mostly a bugfix-only release, with maybe a few other rough edges rounded off.

So in preparation for it, I would like to ask the community at large:

• What 019c bugs or crashes do you have?
• What are any other minor annoyances or weirdness you'd like to see changed?

Please report them here. If you have a bug or annoyance, please give us specific directions on how we can see it, too, on 019c.

Thanks!
- Your friendly bitfighter devs

VERY RARELY!

It crashes when using a teleporter during engineering

[raptor]

Hi Zapgamer,

How exactly would that happen? Do I start to engineer a teleporter then enter in a normal teleporter before placing the endpoint?

Certain INI settings cause crashes when trying to host.

[raptor]

amgine,

We need to know exactly how to create the problem. If you can narrow it down to a specific setting, then that will help.

I'll see if I can find a cause Probably a result of turning all the settings "on" at once.

Can we use this update as an excuse to update s_bot?

no cause he must always remain a stupid_bot

[sam686]

On 019c:
There is a crash when hosting with game recording on when "record" folder have file names that don't start with a number or have a number too big.

Also a crash in editor: select an item and press # (shift+3), then press enter without entering a number.

Both is caused by a difference of "stoi" (string to int) and the old atoi (char to int) conversion. "stoi" throws on bad number or number too big, crashing if exception are not caught. "atoi" just goes zero on bad number or the maximum integer if too big. Visual c++ 2013 have "stoi" but visual C++ 2008 and old compilers does not. Saw a poor way of only using our own "stoi" for some compilers.

"stoi" are used only in a few places, others like in-game commands and level loading use "atoi" which aren't affected by this problem.

I don't know if this counts as a bug but I've been having trouble with the in-game /map command. From what I can tell, entries are case-sensitive, which means if I input /map airlock, it will return an error, when I need to input /map Airlock. This first and foremost is quite a bother, especially when some maps start their names with a lowercase letter or have varying caps throughout.

Fortunately the tab-complete function addresses that issue nicely... unless the map has two words in its title. Then for /map to understand the command, it must be inputted as /map "Honeycomb Breakout" with the enclosing quotes. If I input /map Honeycomb Breakout without enclosing quotes it fails to work.

If I type /map Honeycomb and tab-complete, this issue is addressed, but if I type /map Honeycomb Bre for example and THEN tab-complete, it doesn't work. Tab-complete always fails with two or more words.

As long as I remember to tab-complete with one word, there are no issues. But sometimes tab-complete isn't optimal when there are a bunch of maps starting with the same prefix, like "Space" or "Race." Then I have to tab through a dozen levels to find the one I'm looking for, and if I go too fast I have to restart the cycle.

And finally, this IS a bug (I think): /map struggles with two maps of the same name. Imagine "Airlock" as it is currently and "Airlock" as a hunters map. /map Airlock would play one of the two maps but not the other, even after pressing tab-complete in an attempt to cycle through.

So to summarize:

1. Have /map be case-insensitive
2. Have /map accept entries two or more words in length typed without enclosing quotes (ex. allow /map Honeycomb Breakout)
3. Have /map tab-complete entries two or more words in length if the second word is partially entered (ex. allow /map Honeycomb Br)
4. Have /map cycle through two or more maps of the same name via tab-complete

Thanks!

[raptor]

Hi sky_lark, can you please clarify your #4?

Bouncers can still go through walls if you use shield though, probably a bug

EDIT: This is not a bug, don't remove it

It's detailed in my last paragraph. Basically, if two separate maps are given the same name, /map mapname will only go to one of the maps, no matter how many times the command is inputted. My request to fix this is to press tab when this situation arises and have it silently cycle to the other map with the same name. Does that make sense?

Also shhhhh fordy

[raptor]

I just did #1 with the /map command, and I think I may be able to do #2 and #3 with some thought. But doing #4 is out of the question for 019d, and maybe not even be feasible for 020 without significant (and possible cumbersome) code changes. There's not really a good way to guarantee that any particular one of two maps with the same name will be loaded, especially with our current architecture. For now, I suggest not having 2 maps with the same name.

Ok! I'll keep that in mind.

I can hear seekers being launched by my own team in cmap, even if I am far away

[Little_Apple]

If a chat message is sent right as the map changes, it will not be sent.

[raptor]

sky_lark's #2 and #3 are done. I will look at seeker sounds next.

[raptor]

OK. Seeker problem solved.

Little_Apple, that chat bug has been around forever. Does it only happen when on the loading screen? Or, can it happen before/after that point, too?

I'm trying to narrow it down...

Any messages I send during the time which the screen goes black and the level finishes loading are not sent.

Any messages I send during the time which the screen goes black and the level finishes loading are not sent.

Yep

[sam686]

That chat not showing up when pressing enter 0.01 seconds before loading the new level, is probably because of lag and client sending data to the old GameType, then some time later when server received that chat/command, the server already deleted that old GameType and loaded the new GameType, then throws away that chat/command due to mismatched GameType.

The more lag, the bigger the chance of this happening. Moving chat commands out of GameType and into GameConnection may fix this, but might have to wait until 020.

[raptor]

I put in a workaround that should reduce the chat-disappearing issue by about 50% or so (I hope). It's probably the best we can do for 019d.

When you add bots to teams that don't have spawns, the bot's simply don't show up in-game, but do show up on scoreboard. Normal players can join those teams just fine (puts them at 0,0)

hmm No luck on the INI crash.

Using a LoadoutZone or GoalZone constructor fails to set the team properly. It just sets it to neutral:

  Code:

zone = GoalZone.new(geomArray, 1) -- Doesn't set the team to 1, but to neutral

zone = GoalZone.new(geomArray) -- Fails, missing argument

zone = GoalZone.new(geomArray, 1)
zone:setTeam(1) -- Works!


EDIT: Bitfighter crashes when using the arguments in the TextItem constructor:

  Code:

textItem = TextItem.new(geom, "Text") -- Bitfighter crashes, nothing in log

Also, maybe there should be a third argument in the constructor for team index?

EDIT 2: Using getRandomNumber with a negative number as the minimum, it will always return either the minimum, or the minimum + 1:

  Code:

getRandomNumber(-100, 10) -- returns -99
getRandomNumber(-100, 10) -- returns -100
getRandomNumber(-100, 10) -- returns -100
getRandomNumber(-100, 10) -- returns -99
...

[raptor]

@fordcars

I fixed the GoalZone and TextItem constructors, as well as several others that suffered from the same bug.

The 'getRandomNumber' bug you found is because it doesn't support numbers less than 0. The internal number generator only works with unsigned numbers. You'd have to do something like:

  Code:

getRandomNumber(0, 110) - 100

I have updated the luadoc to reflect this.

[raptor]

Another Lua bug find in 019d: A c++ exception thrown from Lua doesn't spit out the exception string.

@fordcars

I fixed the GoalZone and TextItem constructors, as well as several others that suffered from the same bug.

The 'getRandomNumber' bug you found is because it doesn't support numbers less than 0. The internal number generator only works with unsigned numbers. You'd have to do something like:

  Code:

getRandomNumber(0, 110) - 100

I have update the luadoc to reflect this.

Thanks!

It's awesome you took these bugs down so fast

[sam686]

Z-shaped barriers fails to rotate correctly in editor, like this barrier:
BarrierMaker 50 -255 -255 255 -255 -255 255 255 255
Trying to rotate makes it disappear, press Z zooms out to infinity.

[raptor]

c++ exception messages in Lua is fixed

sam686 it looks like the problem is the centroid-finding algorithm we use is for non-self-intersecting groups of points only... I'll have to think about this - maybe do a quicksort on the points first?

minor bug [ if it was actully the 19d beta I apologize.]

On some game modes setting time to 0 results in the game ending instead of having infinite time. [ did this with somone in the room with me cant remember who.]

in retrospect maybe have 0 be 0 and have -1 be infinity?

also a tad annoying is having to put fractions of minutes i.e 1.5 time added can there be a [second] parameter so its [minutes] [seconds] ? [or just 1.5 minutes]

@Amgine I think that was a bug in a previous version fixed in the current version. Setting time to 0 used to cause it to last forever, now it seems to always end the game immediately. I like your suggestions though -- you should make a new thread for the "-1 for infinity" and "minutes vs seconds" parameters.

@Raptor: 2 editor bugs, both shown in this image.



The first regards laserbeams, which appear to interact strangely with a dotted wall. A dotted wall is just a barrier with both endpoints on top of each other. If I give this barrier a width of 1 it results in a slightly visible dot that should still stop beams, players etc. I'm sure you know this.

In the image above, only vertical and diagonal lasers seem to stop at the dotted barrier, while the horizontal laser continues through. In-game, all three lasers actually do stop at the dotted barrier, it's just the editor that suggests otherwise. This occurs consistently with other positions -- horizontal lasers from left or right appear to go through, vertical lasers from up or down as well as diagonal lasers from any direction do not appear to go through.

The second bug concerns turrets. When I place a neutral turret, it appears like the one on the left: full health, colored white. However when I exit and reenter the editor it appears like the turret on the right: no health, still colored white. Interestingly, team turrets are in opposite. Team turrets appear empty at first, then after exiting the editor they appear full. I'm not sure which graphic is intended.

Other then displaying wrong does it have any effect in game.

[watusimoto]

@skylark -- could you post your two errors into the google code project (as two separate items)? They are both minor, but I'm doing a lot of editor work, so could take a look.

@amgine: Nope, fortunately. @raptor Consider it done.

btw the crash i got when hosting was the bug that sam found about recording thanks for finding it!

Asteroid spawn symbols don't show up on polywalls barriers and zones (loadout normal and goal.)