Last call for small featurelets for 0.2.8

[Phytotron]

Yeah, I just noticed the topic on the experimental cycle width in fortress. I never play there or read that forum, but just happened to. I'm about to post to it.

By the way, when I said "mass" I didn't necessarily mean that in the terms you're suggesting. (I might even object to that on conceptual grounds.) I just meant an actual object in the game that is subject to collision detection (like a car in a racing game), as opposed to a phantom model that has no interaction with the environment, and serves no other purpose than the aesthetic.


Do you guys understand what I mean when I say I'd like custom glance to be independent of the custom camera? I would like to have, e.g....

GLANCE_RISE
GLANCE_BACK
GLANCE_PITCH

...in addition to the custom cam settings. Maybe I want CAMERA_CUSTOM_BACK 4, but when I glance I want GLANCE_BACK 20. See?

This isn't essential for 0.2.8. I just digressed.

[Z-Man]

It may be too late for this, but have you put any (more?) thought into changing CYCLE_ACCEL_SLINGSHOT so that it applies when between any two cycle walls (that is, it wouldn't be required that one be your own as it is now)?

No big problem to add another setting for that case. CYCLE_ACCEL_TUNNEL?

The mass thing you describe seems to be what you *should* get with the current 0.2.8 branch code with CYCLE_WIDTH .5, CYCLE_RUBBER_MINDISTANCE .4 or similar. The problem here is of course that different moviepacks have different cycle models; what looks right for one is wrong for another. And there is something to be considered a bug here: even though MINDISTANCE stops the logical cycle position way before the wall, prediction code moves it through the wall again. This is an easy fix, but it's clientside. Also note that it would still be far from true collision detection, we're still only casting rays.

Is it really very difficult to separate custom glance from the custom camera, so that a player can have a different, independent set of values for each?

No, the settings get selected at one well localized spot in the code. It's just a small pain to add new sets of custom camera settings for different situations. Could you specify the exact logic you want them to follow? It seems we'd need four sets: normal custom, custom glance, server custom and server custom glance. The selection between normal custom and server custom sets goes over the camera mode setting, that much is clear. But how do we decide which of the glancing sets get used?

Would something like the following be possible: "/admin msg ______"

You mean, send an admin message to one player? Sounds doable. Who wants to implement it it?

And one last thing. Can the developers be wary of developing a one-track mind toward fortress mode, and remember that the "classic" game mode still has appeal to a lot of players and can still use attention?

Umm, which of the stuff discussed here is fortress specific?

[Lucifer]

Ah, no I want actual mass to use in acceleration calculations, determining the size of holes in walls, stuff like that. It doesn't matter a whole lot until we have physical objects of different sizes, then we'll need a way to determine whether or not a tank or a recognizer knocks the same size hole in a wall as a cycle, and a reason for doing it however we do it. Mass is convenient for that...

Sounds like you want volume instead. The best you're likely to get is going to be a rectangular box, since it doesn't make sense to do pixel-perfect collision detection (it's very performance intensive in two dimensions, I can't think of any reason to even try in three dimensions). Still, one of the problems is going to be dealing with the network. That always screws up collision detection.

[joda.bot]

How about the customizable teamname support ?
The changes should be pretty isolated, but it probably would be wise to keep the "new team menu" out, because I'm not yet sure if it might cause sideeffects. (Had not enough time to test all cases yet.)

[Luke-Jr]

If we just backport the map and not the whole cockpit, we should actually tell people they can configure their hud further anyway. Maybe some menu items for them?

This is not a feature release. Bugfixes only, and maybe some minor improvements.
The HUD map is not a minor feature, leave it out of 0.2.8... unless you're just going to go suggest we simply make the revision number our only versioning (since people don't seem to want to save features for feature version number bumps)
Where's the incentive to test 0.3 if there's no benefit over 0.2.8.3?

[Phytotron]

Could you specify the exact logic you want them to follow?

Look up. We seemed to be posting at the same time.

You mean, send an admin message to one player?

Yes, just as you do with regular /msg, only the recipient would see it as coming from the admin. It would also be fun if /me would work for the admin as well.

[wrtlprnft]

It would also be fun if /me would work for the admin as well.

Code: Select all

/admin say /me blah

becomes:

Code: Select all

/admin CONSOLE_MESSAGE * 0xff0000Admin 0xffff88blah 0xffffff*

Make an instant chat key for it if you like

[Phytotron]

Oh yeah, this may not qualify as a feature, but nemo, could you have the Finder display the version of the game? You know:

Name
Kind
Size
Created
Modified
Version

[dlh]

Oh yeah, this may not qualify as a feature, but nemo, could you have the Finder display the version of the game? You know:

Name
Kind
Size
Created
Modified
Version

It does already. Most OS X applications keep it in Info.plist, but I store it in a localized version at English.lproj/InfoPlist.strings (and Info.plist contains a key, CFBundleDevelopmentRegion, that points Info.plist to look in the English.lpoj bundle). I'll try moving all that data there, although I don't know why 10.2.8 isn't picking it up. I only have control over the Version, Finder.app deals with all those other things.

[Z-Man]

Where's the incentive to test 0.3 if there's no benefit over 0.2.8.3?

You get 0.3 earlier But I partially agree (have I said that before?), backporting everything does not make sense.

Joda: as a /teamname chat command, sure. I'd advise against putting the team name in the sync functions; the whole player data gets synced in regular intervals to update the ping value.

Phytotron: Yes, I read what you posted before me, but I still can't figure out the logic Do you want three settings, custom, glance, and server custom, and the server can force you to use the server custom settings instead of the custom settings and, separately, force you to use the server custom settings instead of the glance settings?

[Luke-Jr]

I suggest we define backportable features to be things only which are at the very least necessary to use some new ability, or are very unlikely to have any bugs. For example, the HUD map is entirely unnecessary for gameplay or any other aspect of the game. It's similar to a car radio-- nice to have, but you can get a car without one because it's not needed. And the HUD map certainly has room to cause problems, even if its own code were bug-free-- perhaps FPS issues, at least.
Other major new features, such as the cockpit, fonts, and music are at least as potentially problematic.

Please keep the new, untested, and experimental features in the experimental versions. If you want them in a stable version, do something to accelerate the next stable release, don't infect the current one with untested code.

[Z-Man]

I can agree with the definition, and backporting the whole cockpit and font system has already been ruled out for technical reasons.

But the HUD map is in active testing now for many months by a limited circle. Has it ever crashed once in a version committed to our SCM? I don't think so. And before 0.2.8.3 gets out, we'll have it tested by many more people that try out 0.3.0, so all possible hardware incompatibilities should be found. I'd say that by the "no user visible change in the default configuration" rule, the HUD map should be disabled by default if it gets backported. A test for a flag is very hard to get buggy

[Phytotron]

Phytotron: Yes, I read what you posted before me, but I still can't figure out the logic Do you want three settings, custom, glance, and server custom, and the server can force you to use the server custom settings instead of the custom settings and, separately, force you to use the server custom settings instead of the glance settings?

OK, sorry, let me try again. First, let's forget about server custom. If you're playing a local game (or a server without a server custom cam), then you would have two sets of values. One would be your Custom Cam and the second would be your Custom Glance. So you'd have the CAMERA_CUSTOM_ settings as we have now, as well as an additional set that might be something like GLANCE_CUSTOM_. Default would be for both sets to be equivalent.

Now, let's say you entered a server that had a server custom cam. That would work just as it does now: If you go to your camera setup and choose Server Custom, then those server-side settings would be your camera. It wouldn't affect your personal Custom Glance settings, though, because those are now independent of the custom cam, right.

Unless, the server admin doesn't want you to use your own personal glances in conjunction with the Server Custom cam. In that case, there might be a setting called CAMERA_FORBID_CUSTOM_GLANCE.

This setting would only affect the client if he has his camera set to Server Custom, however—you wouldn't want to forbid people from using their personal glances when using their own personal cam. (Or maybe you would. A server can forbid any other cam, why not glance as well?)

But anyway, if a) that CAMERA_FORBID_CUSTOM_GLANCE is set to 1, and b) the client has his camera set to Server Custom, then well, there are two options with respect to what happens to glancing. Either the server custom cam settings take over the glancing just as they do now, or the server needs to also have its own separate set of GLANCE_SERVER_CUSTOM_ settings. The latter might be preferred, actually, but I'll leave it up to you which is better.

Does that all make better sense? I think it admittedly sounds more complicated than it actually is, heh.

[Z-Man]

Makes sense. It always sounds more complicated if you break it down to clear, programmer friendly instructions

[2020]

since i approach armagetron from the strategy game perspective
such as the japanese/chinese game go
where pieces as abstracted forms
i like the level of abstraction
where a lightcycle has no weight
it turns at 90? angles

i believe
this is why the game is so beautiful

it captures something of labyrinths and reaction times
with the fortress bonus of team-play

oh
as a purist
i love the incam mode
and would gratefully appreciate voice-chat capabilities
to be included in your planning