Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Feature Wishlist
1 2 Previous Next
- - By Zapper [de] Date 2012-12-03 21:30 Edited 2015-11-15 16:45
This is a list of features that are wanted by many but not on a high-priority and thus will probably not come soon if noone volunteers for them.
They are of different difficulties and some might be a good start if you want to start getting into Clonk programming and need some inspiration :)

Note that the effort can not be estimated with 100% accuracy - and even "low effort" is more than "no effort".

relatively low effort


* automatically load scenario version from Version.txt and display everywhere&always(?) behind the scenario title
* lobby icons to show whether a player is still loading
* "ready" button for the lobby
* ping network games in masterserver view
* team-options configurable by command-line for dedicated servers
* display scenario descriptions when loading a game
* better spectator GUI (free camera mode f.e.)
* record mouse movement & zoom for (local?) player in record-files
* have at least always also international (english) titles in masterserver view
* chatting while waiting for others (network game, after loading)

relatively medium effort!


* be able to create an attachable model from a texture at runtime
* some sort of votekick system for dedicated servers
* optimize rendering of static meshes
* little (optional) flag icons for the lobby
* scenario options that can be set in the lobby (or via command-line for DS) - major part of work already done
* player & clonk names should not zoom
* being able to use current bone position for (asynchronous) effects [particles..?]
* implement a faster particle system (straightforward)

relatively high effort


* better path finding (possibly in script)
* better text rendering interface
* tweak asynchronous network mode (->ala, Peter?)
* a proper menu system and script interface <thread>
* solid masks that can be passed through in one direction (think of mario-style plattforms)

PS: there might be bugtracker entries for some of those points. Feel free to ask.

PPS: This list is open, of course, so new entries are welcome. They should however have a clear boundary (stuff that cannot be described in one sentence is probably not fitting :)  )
Parent - By Zapper [de] Date 2012-12-03 21:31
One note to why this is in the forum and not in the wiki:
As Sven mentioned, those lists tend to get outdated fast. I basically take responsibility and force myself to care for it that way :)
Parent - - By Caesar [de] Date 2012-12-03 22:05
Ah, pleas add a "Display scenario description while loading" to low effort.

>* some sort of votekick system for dedicated servers


Is probably low effort, since it's already implemented, just bound to league.

>* render static meshes to 2d sprite once to speed up drawing


That one's doubtable. The problem is, that you'll end up with a lot of different images that have to be hold in graphics memory. If that isn't taken care of in a sensible manner, it's possible to do more damage than good.
Parent - - By Zapper [de] Date 2012-12-03 22:14

>That one's doubtable. The problem is, that you'll end up with a lot of different images that have to be hold in graphics memory. If that isn't taken care of in a sensible manner, it's possible to do more damage than good.


I am not sure about that. I would assume that the texture memory the GPU has is far bigger than what we use right now.
And currently for every tree that you can see, the model is send to the graphics card every frame (including a lot of set up etc.) - and that is pretty slow
Parent - By Caesar [de] Date 2012-12-03 22:35
I've only heard that when making that proposal myself, so I bet someone else will enlighten us in that point.
Parent - - By Clonk-Karl [de] Date 2012-12-04 10:33
There are better ways to handle this, though. You would need to store one image for every tree since it can be rotated around the Y axis. Instead, you could store the vertex data in video memory. This works nicely for non-animated objects. For animated objects, you could do the same and run the animation in a vertex shader. Then you would only need to upload the bone transformation matrices to the GPU every frame.

Also, the vertex data throughput (for trees) is not a bottleneck at the moment. Before doing any rendering optimization work I strongly suggest to do some profiling first or you might end up optimizing something that does not gain us anything (or even make it worse without noticing).
Reply
Parent - - By Zapper [de] Date 2012-12-04 12:54

>Also, the vertex data throughput (for trees) is not a bottleneck at the moment


But from the bit of profiling I did, I'd say at least the high amount of state changes per rendered mesh are. But you know the matter better than me. I'll rename the point to be more general
Parent - By Clonk-Karl [de] Date 2012-12-04 13:06

> But from the bit of profiling I did, I'd say at least the high amount of state changes per rendered mesh are.


Could well be, but that's a completely different story.
Reply
Parent - - By Sven2 [de] Date 2012-12-03 23:06
Scenario options are probably harder than "medium effort", because of all the pitfalls they offer. First, they'd need to be known in the lobby to all clients, preferably even while they're still loading. So both selected options and option definitions would need to be part of the initial join info. Then they'd need to be synchronized similar to player infos. Then you have all the trouble of savegames, records, runtime join, savegame resume in network, etc.

Then, there's the localization issue. Unless you're fine with just displaying the option to all clients in the host language, the selected options would need to be paired with the localized version of the option definitions. Localization was actually the reason why I skipped the thing last time someone came up with it.
Parent - By Zapper [de] Date 2012-12-04 07:59
okay, moved!
Parent - By Randrian [de] Date 2012-12-04 22:43
Perhaps I think of this issue a bit different, but I would do something like the Teams.txt and specify there some options.

[Options]

  [Option]
  id=1
  Name=$SelectRelaunches$
  Type=Number
  Min=0
  Max=10
  Default=5

  [Option]
  id=2
  Name=$SelectFriendlyFire$
  Type=Toogle
  Default=False

And on the scenario start a function is called: SetOptions(ValueOption1, ValueOption2)
If you start without Lobby a menu is displaced instead to select the options.
This should be very analouge to the team selection in the Lobby. Every client has to know about the team information bevorehand and changes have to be synchronised if someone changes the team settings in the lobby.
Perhaps this can be even specified in the same file.
I have to admit, that I don't know much about this code, but perhaps my ideas can help.
Reply
Parent - By Newton [de] Date 2012-12-03 23:27
Nice ideas. Stickied.
Parent - - By IchUndNichtDu [de] Date 2012-12-03 23:32
i would change the line ""ready" button for the lobby" to ""ready" and "afk" buttons in the lobby"
Reply
Parent - - By Isilkor Date 2012-12-04 00:22
I don't really see the point in an afk button. If you aren't there then you aren't ready.
Reply
Parent - By IchUndNichtDu [de] Date 2012-12-04 16:43
just for example: some people spam "go" while the host is afk. some people maked already players like "host is afk /alert is your friend" and add them to the lobby when they're afk.
Reply
Parent - By Caesar [de] Date 2012-12-06 22:26
seconded
Parent - - By PeterW [gb] Date 2012-12-04 13:02

> * better path finding


As I noted in the bug tracker, this might actually something that could be moved into Script. You'd just have to implement a "GetPath" function that replaces the much older (and rarely used) GetPathLength function with something that returns the path as an array.

> * tweak asynchronous network mode (->ala, Peter?)


Uh, what exactly is the idea here?
Parent - By Zapper [de] Date 2012-12-04 13:18

>Uh, what exactly is the idea here?


I am not 100% sure. I included that point because I remembered ala mentioning about how it worked well at some point in CR but didn't work as well later.

>@pathfinding


I'll include the hint
Parent - Date 2012-12-04 14:59
Parent - - By Caesar [de] Date 2012-12-06 22:28

>As I noted in the bug tracker, this might actually something that could be moved into Script. You'd just have to implement a "GetPath" function that replaces the much older (and rarely used) GetPathLength function with something that returns the path as an array.


Not that the pathfinder isn't a problem alread if you have more than a few things using it...
Parent - By PeterW [gb] Date 2012-12-07 11:59
The pathfinder is quite expensive, yes - but the most hefty part is probably finding the path in the first place. As long as script is smart about not calling it too often, it should work out. I think the way that it worked so far was that after the pathfinder was run all nodes were converted into separate MoveTo commands, so from that point onwards you'd only use the path-finder to the first node of the last search. Something along these lines.
Parent - - By Pyrit Date 2012-12-19 19:20
A function to deactivate the control of a clonk would be cool.
Parent - - By Caesar [de] Date 2012-12-19 20:21
That should be SetCrewEnabled, right? Just that it doesn't work.
Parent - - By Pyrit Date 2012-12-19 20:59
Would SetCrewEnabled mean that GetCursor() returns nil? You should still have a clonk selected, just not being able to control him.
Parent - - By Zapper [de] Date 2012-12-19 21:19
The problem is that the control was caught in the engine in CR when the crew was not enabled.
When rewriting the control stuff in script for OC, someone simply forgot that :)

I fixed it with the following script for Caedes:
#appendto Clonk
/* Main control function */
public func ObjectControl(int plr, int ctrl, int x, int y, int strength, bool repeat, bool release)
{
  if (!this)
    return false;
   
  if(!GetCrewEnabled()) return true;
  return inherited(plr, ctrl, x, y, strength, repeat, release, ...);
}


PS: I  might have misunderstood you.
You want GetCursor to return nil? So you want to remove a Clonk from a player's crew?
Parent - - By Pyrit Date 2012-12-19 21:38

>You want GetCursor to return nil? So you want to remove a Clonk from a player's crew?


No, GetCursor should still return the selected clonk. You should just not be able to control him.
Parent - By Zapper [de] Date 2012-12-19 22:44
Okay, then see my script-snippet. :)

That might even count as a bug that needs fixing in the original pack. I am just not too sure whether that belongs into script or the engine (just so that there is not another script<->engine transition necessary for every control)
Parent - - By Newton [de] Date 2012-12-20 00:11

>I fixed it with the following script for Caedes:


Why didn't you fix it for OpenClonk then?
Parent - - By Zapper [de] Date 2012-12-20 07:41
"I am just not too sure whether that belongs into script or the engine (just so that there is not another script<->engine transition necessary for every control)"
It seemed like a bit of a hack to me, but I had no better idea at that point. And frankly, I needed a quick fix and forgot about that later ;)
I can commit it into the repository later (after at least asking Sven about whether that's the right place to catch controls, once).
Parent - By Sven2 [de] Date 2012-12-20 11:04
It has to be in script with the current design. The engine cannot know what is a Clonk control to be passed to the cursor (like CON_Left) and what is a player control (like CON_ZoomIn/ZoomOut, select cursor, etc.). So just addding that line should be fine.
Parent - - By Dragonclonk [de] Date 2012-12-23 11:35
The melee goal needs also an easy to use relaunch function, like in Deathmatch.
Reply
Parent - - By Sven2 [de] Date 2012-12-23 12:32
Relaunch is almost always scenario-dependent. I'd say there should be a relaunch rule that just does the callback to RelaunchPlayer (instead of the Clonk doing it directly at the moment).
Parent - By Dragonclonk [de] Date 2012-12-23 12:55
Yes a relaunch rule would be more useful.
Reply
Parent - - By Pyrit Date 2012-12-24 23:02
It would be cool, if it would be possible to get the position of a certain bone in the game. You could then e.g. cast particles very exactly or attach non 3d graphics to a bone.
Parent - - By Zapper [de] Date 2012-12-25 00:50
That doesn't work like that, because the bone coordinates are not calculated synchronously. It doesn't make a difference for gameplay if the bones on two computers are displayed slightly off.
But as soon as you would use the coordinates for something important, the whole calculation would have to be synchronised to prevent desyncs. That's why I put only particles in the list - those do not need to be synchronized.
Parent - - By Caesar [de] Date 2012-12-27 19:03
That leads to the feature wish of safely executable asynchronous scripts.
Parent - - By Zapper [de] Date 2012-12-27 19:55
No, this is a lot easier (because it's simpler). For asynchronous "effects" something like CreateParticleAtBone("hand1", ...) would suffice. That's easily possible at the moment and does not need the huge framework for asynchronous scripts around it :)
Parent - - By Clonk-Karl [de] Date 2012-12-29 00:13
Reply
Parent - - By Zapper [de] Date 2012-12-29 12:29
cool :D

CaedesMuzzleFireEffect++

PS: What does the Z parameter of dir do?
Parent - By Clonk-Karl [de] Date 2012-12-29 12:50 Edited 2012-12-29 13:00
The final Z component in world coordinates is ignored, but the one that you give to the function is in bone coordinates, and it can make a difference when the bone is rotated with respect to the mesh coordinate system (or the mesh itself is rotated with the MeshTransformation property). Consider a bone at the end of a rifle oriented such that the Z axis of the bone orientation points outward of the rifle. Then you could specify [0, 0, 10] as dir to have particles moving away from the rifle in the direction in which it is oriented.
Reply
Parent - - By Pyrit Date 2013-01-08 21:39
Cool! Does this work with items that are contained in a clonk, but held in his hand?
Parent - - By Clonk-Karl [de] Date 2013-01-08 21:48
You mean with attached meshes? No, but I guess I could add another parameter to the function for that, which indicates an attached mesh.
Reply
Parent - - By Zapper [de] Date 2013-01-08 22:02
:)!
Parent - - By Newton [de] Date 2013-01-08 22:47
.oO(Club)
Parent - By Zapper [de] Date 2013-01-08 22:52
No particles for the club!
Parent - - By Pyrit Date 2013-01-08 23:31

>You mean with attached meshes?


Yes, that would be cool. :) Is that possible?

What happens actually, when there's no bone at wich the particle could be created at? For example, the object is attached to a clonk's hand, but he does a certain animation (e.g. pickaxing, wich occupies both hands) and the object vanishes for a short time? Will it return an error, or will the particle created somewhere in the clonk, or will ther just be no particle?
Parent - By Clonk-Karl [de] Date 2013-01-08 23:50
Yes, it should be easily possible. I'll have a look.

> For example, the object is attached to a clonk's hand, but he does a certain animation (e.g. pickaxing, wich occupies both hands) and the object vanishes for a short time?


In that case, the mesh is not attached to the clonk for that period of time, so the CreateParticleAtBone function would fail and return false because it doesn't find the attached mesh.
Reply
Parent - By Pyrit Date 2013-01-01 15:46
If you record, the zoom of a player should be recorded, too. At the moment you can zoom how you want in recordings. It should correspont to wich zoom the player had while it was recorded. Or maybe an option to turn the automatic zoom in recordings on and off?
Zooming with mousewheel should be possible.
Parent - - By Pyrit Date 2013-01-27 02:12
I don't know if it's already possible, but what about having multiple overlays for objects?

Or being able to use SetClrModulation() for every terture unit individually.

If an object belongs to two players, it could have the colors of both players on it.
Or butterflies could be colored randomly in all colors of the rainbow!
Parent - - By Newton [de] Date 2013-01-27 02:33
It is possible. Have a look into the documentation.
Up Topic Development / Developer's Corner / Feature Wishlist
1 2 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill