Questions

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Games, Version 1.9.</i>

I've got two issues at the moment. With SVN 4697, when I try to start a new game on Doom II, I get the following fatal error:
<pre>Missing partner for miniseg #1!</pre>
DaniJ, does this fail similarly on your system?

Also, for some time now none of the player controls have been working for me. Should they be working at the moment? Or has something been changed?

DaniJ

I've just tried starting a new game on DOOM II with SVN 4697 and I have no problems. Have you rebuilt doomsday.pk3 as there have been changes to the binary lump format definitions (specifically, we now read the partner seg property from the GL_SEGS lump).

You are correct, the player controls are not working correctly and are not expected to given the current (unfinished) state of the input code.

In order to get the controls working again we first need to cover how the ticcmd generation is going to work (including deciding the format of the packet) and think about the movement command syntax (i.e. why "++/--/+/- walk").

Then we need to update the control register code to include all of the controls used for each game. Once that is done, we can then think about implementing replacements for the player control and input device setup menus, in the Doomsday control planel.

Once the controls are sorted out, we should think about releasing beta6.

skyjake

<blockquote>Have you rebuilt doomsday.pk3 as there have been changes to the binary lump format definitions (specifically, we now read the partner seg property from the GL_SEGS lump).</blockquote> I had not, and rebuilding the PK3s fixed the issue. Thanks for the tip.

<blockquote>In order to get the controls working again we first need to cover how the ticcmd generation is going to work</blockquote> I'm not familiar with the details of the ticcmd refactoring (or I've forgotten...). Can you walk me through the reasons for doing the changes? What is lacking in the old ticcmd system? Is this related to having multiple local players?

DaniJ

The primary reasons to refactor the ticcmd design are:
1) Expansion by game plugins and mod authors.
The current format makes implementing new controls very difficult due to encoding the controls into a finite number of bytes. For example, it is not possible for a game/mod to implement additional weapons, inventory items.
2) Use of ticcmd values as absolute values.
For example, player movement deltas are handled as absolute values and when received server-side they are currently used as is. Movement speed modifiers are currently handled game-side (e.g. walk/run and the -turbo option) and applied to the value written to the ticcmd. Instead, a normalized value describing the player's applied range should be in the ticcmd and any additional modifiers should be applied server side. E.g:

float run; // [-1...1]
float sidestep; // [-1...1]
int modifierFlags; // WALK | TURBO etc...

EDIT: There was another far more pressing problem but I can't recall what it was. No doubt we'll come across it sooner rather than later.

DaniJ

Can I get a status update on your situation skyjake? Any idea when you'll have spare time for deng?

skyjake

I have time right now.

I think we need to get the controls operational and up and running in the way they've done in the past (default bindings, controls menu/panel, slow/fast accelerated turning). After that it's much easier to resume development of the other stuff.

DaniJ

Great

Absolutely, the state of the controls is holding back development. Lets resume discussion in the controls thread.

skyjake

When it comes to the data sent in the ticcmds, we must let the client decide what is the appropriate speed. On server-side, the best we can do is do some sanity checking whether the player positions and speeds are within legal bounds.