Christmas will be over in two months. Are we going to continue our tradition of getting a release ready around that time?

The current major features are basically the editor and the netpuncher.

But we would also need to fix a lot of bugs, as usual!
I have 5 additional music tracks, of which 3 are finished - and two are half finished. They can also be included, will finish writing them for the release.
[Edit] Oh, seems I only wrote 4, well maybe there is enough time for a fifth, will see.
[Edit] Oh, seems I only wrote 4, well maybe there is enough time for a fifth, will see.
I can release external scenarios maybe, and/or update some old ones.
Doesn't look like it, does it?
How about we focus on the end of the next semester break (March?), maybe that is more realistic. We should use the Christmas break to really start working though :)
[Edit] Also if the mining contest creates interesting objects we would have enough time to incorporate them.
How about we focus on the end of the next semester break (March?), maybe that is more realistic. We should use the Christmas break to really start working though :)
[Edit] Also if the mining contest creates interesting objects we would have enough time to incorporate them.

What about a trello checklist for all scenarios and then we release once everything has a checkmark? Is anyone willing to make the list?
(Hi from Barcelona!)
I was more concerned about the bug tracker, in comparison to other stable versions we sure have a lot left open.
>How about we focus on the end of the next semester break
That time is drawing near, right?
For me exams are finished next week. I'll start working on the promised music directly after it. I'll post an update every Sunday starting on the 11th.
Maybe we can motivate each other? That might produce some extra music for every 5-Bugfixes or something.
I think we should move this to the public board. During the Christmas break I managed to fix a few bugs, but the bugtracker still contains some simple things we should be able to fix before a release.
Then notably the new editor and the new liquid system need a bit more testing ideally.
Then notably the new editor and the new liquid system need a bit more testing ideally.
So, how about this years Christmas then? Somebody willing to put some effort towards the release?

Man, do we still have a graphic guy for that wicked gold idol? I feel so bad, the request from Zapper is like 6 years old.
Fulgen asked for a pedestal for the idol, probably could make the graphics and script it next week.
Done :) The three images just show different ambience brightness settings. The object is on my branch on github, can merge back soon. The scripts for the attached objects are not implemented yet - the main problem here is that the weapons are Clonk sized, but the statue needs 120% scaling or 100% scaling. My original idea of having destructible stone statues that can drop actual weapons may thus not be that good. On the other hand, those stone statues could be smaller, and have a sort of "cracked" look, to indicate that they can be destroyed...

Of course even more cool would be if those were animated AI enemies :-)
In a later release :p Indeed, would be cool. Any preference for the idol in fight for gidl?
Could someone please have a look at the implementation? The editor actions do not quite behave as I want them to (current choice is not displayed after choosing an item/pose): https://github.com/gitMarky/openclonk/tree/gidl
Also, read the commit messages please, because they contain some outlooks for the future - for example the item choice code might be replaced by choosing actual items (also, the sword looks strange).
Also, read the commit messages please, because they contain some outlooks for the future - for example the item choice code might be replaced by choosing actual items (also, the sword looks strange).

Idol.EditorProps.IdolPoses.AsyncGet = "GetAction"
The getter makes sense, but what do you mean by: If you don't have a property?

But you can also mix it. You can have a Set function that also sets the property. I would actually recommend this way, because it makes sense to have a public interface and it can also handle scenario saving:
local pose;
Idol.EditorProps.pose = { [...] Set = "SetPose", Save="Pose" };
public func SetPose(new_pose)
{
this.pose = new_pose;
SetAction(new_pose);
}
* The "Save"-field automatically handles scenario saving, so you don't need to define SaveScenarioObject.
* You have a public interface (idol->SetPose) that scenario designers can use in their regular scripts.
The "cleanest" way may be to also define a GetPose function and use that in the editor property. However, the editor has to work in network mode and scripts have to run the queue, so I decided to make getters asynchronous (AsyncGet) and require them to not change synchronous state. It would be OK in this case, but asynchronous functions are always dangerous.
I chose "AsyncGet" and left the name "Get" free for now, because I may also implement proper "Get" functions in the future. However, that's pretty tricky to implement without making the editor laggy,
Hmm, it would be more flexible if we could specify the variable to save to:
Also, it would be really cool if the Set-Property worked with function pointers (at least in the latest version it did not work):
I like function pointers a lot more, but it is probably just a false feeling of security: After all, even if I rename the function, the engine will not complain that the pointer points to nothing now. Maybe the advantage is that it tells the scripter that the property is about a function.
Object.EditorProps.<property> = { [...] }; // looks up this.<property> for the value
Object.EditorProps.<some name> = { [...], Property = "my_settings.property" }; // looks up this.my_settings.property for the value
Also, it would be really cool if the Set-Property worked with function pointers (at least in the latest version it did not work):
Idol.EditorProps.pose = { [...] Set = this.SetPose };
I like function pointers a lot more, but it is probably just a false feeling of security: After all, even if I rename the function, the engine will not complain that the pointer points to nothing now. Maybe the advantage is that it tells the scripter that the property is about a function.

It's probably not very well tested because I never actually used it. I don't see a good reason to use it, except maybe to allow two ways to set the same property.
Grouping properties of one object in a proplist avoids the problem that the same property may be used by different scripts with different meaning.

I am happy to help with fixing and finding bugs. But there is quite a bit of them remaining in the bugtracker that need some attention from engine developers.

Are those engine-categorized bugs really mandatory? I mean, of course we can dream, but I doubt we will fix a good deal of all the reported bugs soon, the number has gone quite up. So a more realistic approach is probably necessary.
I'm also available for testing.
I'm also available for testing.

For those who work with the bugtracker, there is the 8.0 roadmap which has all non-feature open bugs. Please move them to 8.1 or 9.0 if you find them to be not important.

Regarding Intel GPU issues: I feel like we should decide on some minimum processor version and explicitly not support anything below that. We really don't have the resources for working around these issues that pop up all the time. Looking at the Wikipedia list, the minimum supported processor generation is probably Ivy Bridge, which can be conveniently detected by trying to request an OpenGL 4.0 context. (e.g. #1812, #1771, related: #1890)
I don't fully understand. Does OC not work on Sandy Bridge at the moment? Loosing support for that platform seems a bit early to me.


Almost every core engine developer is inactive now, so no reason to keep useless feature wishes around.
I feel that we might pull off simple things in the feature, like finally developing keyboard controls for menus, to reenable splitscreen / gamepad support. But major stuff will not happen.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill