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
relatively high effort
* better path finding (possibly in script)
* better text rendering interface
* tweak asynchronous network mode (->ala, Peter?)
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 :) )
As Sven mentioned, those lists tend to get outdated fast. I basically take responsibility and force myself to care for it that way :)
>* 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.
>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
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).
>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
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.
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.
> * 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?
>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.
I'll include the hint
>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...
When rewriting the control stuff in script for OC, someone simply forgot that :)
I fixed it with the following script for Caedes:
/* Main control function */
public func ObjectControl(int plr, int ctrl, int x, int y, int strength, bool repeat, bool release)
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?
>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.
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)
>I fixed it with the following script for Caedes:
Why didn't you fix it for OpenClonk then?
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).
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.
CreateParticleAtBone("hand1", ...)would suffice. That's easily possible at the moment and does not need the huge framework for asynchronous scripts around it :)
PS: What does the
MeshTransformationproperty). 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
dirto have particles moving away from the rifle in the direction in which it is oriented.
>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?
> 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.
Zooming with mousewheel should be possible.
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!
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill