Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / 14 months, Christmas and the like.
1 2 3 4 Previous Next
- - By Caesar [de] Date 2016-10-27 11:12
Christmas will be over in two months. Are we going to continue our tradition of getting a release ready around that time?
Parent - - By Luchs [de] Date 2016-10-27 14:47
One or two new scenarios would be neat to have something new and exciting for non-developers?

The current major features are basically the editor and the netpuncher.
Parent - By Zapper [de] Date 2016-10-27 15:44
Mh, from my side, the spiders as new animals would be realistic.
But we would also need to fix a lot of bugs, as usual!
Parent - By ala [de] Date 2016-10-27 16:41 Edited 2016-10-27 17:07
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.
Parent - By Marky [de] Date 2016-10-27 20:06
I can release external scenarios maybe, and/or update some old ones.
Parent - - By ala [de] Date 2016-12-10 00:03 Edited 2016-12-10 00:20
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.
Parent - By Newton [de] Date 2016-12-10 22:47
Guys, just release already what you got.
Parent - - By Sven2 [es] Date 2016-12-11 06:53
We don't really need more features, but we do need to do testing. Like play through all tutorials and run each scenario once. It's a bit embarassing if e.g. tutorial 1 fails.

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!)
Parent - - By ala [de] Date 2016-12-11 08:57
I was more concerned about the bug tracker, in comparison to other stable versions we sure have a lot left open.
Parent - By Maikel Date 2016-12-12 15:22
I agree, let's try at least to fix some bugs.
Parent - - By Luchs Date 2016-12-11 20:34
I added a list to the Trello board.
Parent - By Sven2 [de] Date 2016-12-12 13:17
Thanks! I see the first item is already completed :-)
Parent - By ala [de] Date 2017-02-04 23:09

>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.
- By Maikel Date 2016-12-29 09:41
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.
- - By ala [de] Date 2017-08-03 08:31
So, how about this years Christmas then? Somebody willing to put some effort towards the release?
Parent - - By K-Pone [de] Date 2017-08-03 11:41
Yeah, would be quite cool to have 8.0 released soon. Btw what about the Milestones? Milestone 2 seems to be almost finished.
Parent - - By ala [de] Date 2017-08-03 14:38
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.
Parent - By Marky [de] Date 2017-08-04 15:52
Fulgen asked for a pedestal for the idol, probably could make the graphics and script it next week.
Parent - - By Marky Date 2017-08-10 22:23
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...
Parent - - By Sven2 [us] Date 2017-08-11 06:36
Dropping weapons is a cool idea! Especially the golden sword could be used in one of the missions.

Of course even more cool would be if those were animated AI enemies :-)
Parent - - By Marky [de] Date 2017-08-11 13:14
In a later release :p Indeed, would be cool. Any preference for the idol in fight for gidl?
Parent - By Fulgen [at] Date 2017-08-11 13:40
It could lower its weapon when it looses energy hitpoints.
Parent - By Caesar Date 2017-08-13 11:19
Golem pack hello?
Parent - - By Marky Date 2017-08-11 20:43
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):

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).
Parent - - By Sven2 [us] Date 2017-08-12 00:59
For EditorProps, you use SetAction as the setter. If you don't have a property, you need to define a get-function as well:

Idol.EditorProps.IdolPoses.AsyncGet = "GetAction"
Parent - - By Marky [de] Date 2017-08-12 08:22
The getter makes sense, but what do you mean by: If you don't have a property?
Parent - - By Sven2 [us] Date 2017-08-13 17:32
Each EditorProp is either backed by a property of the same name (the default case), or by Set and AsyncGet functions.

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;

* 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,
Parent - - By Marky [de] Date 2017-08-13 19:34
Hmm, it would be more flexible if we could specify the variable to save to:

Object.EditorProps.<property> = { [...] }; // looks up this.<property> for the value
Object.EditorProps.<some name> = { [...], Property = "" }; // looks up 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.
Parent - - By Sven2 [us] Date 2017-08-13 23:16
You can specify the variable (as a string). It's called "Key". See here:

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.
Parent - - By Marky [de] Date 2017-08-14 06:58
Grouping properties of one object in a proplist avoids the problem that the same property may be used by different scripts with different meaning.
Parent - - By Sven2 [us] Date 2017-08-15 02:30
You mean for libraries? Then the same problem exists for functions. I think it can be solved by giving properly specific names (e.g. prefixed or including the library name).
Parent - By Marky [de] Date 2017-08-16 16:36
Yes, but that's what you can use the "Key" property for, so there is no problem?
Parent - - By Maikel Date 2017-08-03 12:16
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.
Parent - - By Zapper [de] Date 2017-08-03 12:46
Hm, we could start by sorting all "real" bugs into a 8.0 milestone. I think it's still pretty chaotic in the bugtracker
Parent - By Maikel Date 2017-08-05 09:54 Edited 2017-08-05 10:14
Moved all 7.X bugs to 8.0, those we don't want to fix we can slowly move to 8.1.

To Admins: the roadmap 7.0, 7.1, 7.2 can be closed.
Parent - - By ala [de] Date 2017-08-03 14:34
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.
Parent - By Maikel Date 2017-08-05 09:53
It would be nice to see at least some of them fixed before an 8.0 release.
Parent - - By Zapper [de] Date 2017-08-03 12:47
From my side, it would be realistic to have CCAN2.0 (larry) integration in the engine by then
Parent - By ala [de] Date 2017-08-03 14:24
That's fantastic news.
Parent - By Marky [de] Date 2017-08-04 15:52
Woot :)
Parent - By Maikel Date 2017-08-05 10:00
I'd like to finish the new cannons and add one or two tutorials before we release.
- - By Maikel Date 2017-08-05 15:02
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.
Parent - By Zapper [de] Date 2017-08-05 15:10
Parent - - By Luchs Date 2017-08-07 18:30
We should probably remove SDL_mixer support or at least disable it in the build system. It's broken and usually not in use. (#1795, #1241)

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)
Parent - - By Maikel Date 2017-08-07 19:20
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.
Parent - By Luchs Date 2017-08-07 19:46
The GPU in #1812 is from the Sandy Bridge generation. Those GPUs don't support OpenGL 3.2 so they already need some workarounds, I believe.
Parent - By Caesar Date 2017-08-13 11:20
To clarify: A Sandy Bridge CPU is not a problem, but you will need a dedicated graphics card.
Parent - - By Clonkonaut Date 2017-10-26 13:31
I'm going through the bugs, fixing what I can and rigorously moving /closing bugs. Especially minor bugs or feature wishes that have been around for years now. I go as far as removing any target version and put them to 'git master'. I don't see the sense in moving them to a new version every major release.
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.
Parent - - By Zapper [de] Date 2017-10-26 13:33

>But major stuff will not happen.

Parent - By Clonkonaut Date 2017-10-26 13:36
Up Topic Development / Developer's Corner / 14 months, Christmas and the like.
1 2 3 4 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill