![[th]](/mwf/flags/th.png "Thailand")
At least because of #1029 Release includes Experimental.ocf and Issues.ocf (in my opinion) we will want to have another bugfix update soon. So, this is a roll-call for that. Specifically, we will probably need some help for this release from people who were busy during the 4.0 release and couldn't help with that. (See below)All: Please have a look at the bugtracker, also, I created this list of bugs that should IMO at least be resolved for the update on the roadmap page.
I put my patches so far into the stable branch already.
Mortimer: You pushed quite a few mac-specific patches to master, please pick those that are eligible for the stable-5.4.0 branch.
Isilkor: Some build problems popped up, could you have a look into them? If a particular problem falls out of your expertise or you really got no time, could you comment on it that someone else should look into it? I didn't mark the build problems as a must for the update because I have too little knowledge about that to judge how fatal they are, you are free to do that of course, the current roadmap list is just a suggestion.
I agree, and will finally fix the last bug assigned to me, and have a look at other stuff I could fix.
Should we change the background of the ring menues from transparent black to transparent white?
IMO the menu background should be made from transparent black to less transparent black only to keep the current GUI layout consistent where you find white text on black background everywhere. A redesign that includes the mentioned concerns for visibility is something for a redesign of the GUI and thus for a major release.
I hate the library issues that cropped up. Mostly because I'm trying to get the autobuilds to run on default settings as far as possible, so the builds are actually reproducible outside of the build environment (this means no hard-coding library paths). I don't know whether the solution is to update the build environment to something that isn't Debian Stable (which we've used so far as a base-line), or just doing a build each for every distribution.
And people have the gall to complain about Windows library problems.
And people have the gall to complain about Windows library problems.
Yeah, regarding the freetype issue. I already presumed that the patch by pkern would just make the library be found by another set of distributions than it is now since it is working currently for the autobuilds and thus on your system. So, if freetype is not located in the same place on every linux dist (anymore), perhaps the issue can be solved with this freetype-config pkern mentioned?Doing a build for each distribution seems overkill and something that needs far too much effort and maintenance work (for you). You probably had to keep half a dozen VMs with updated Linuxes around ... or what?
Otherwise, I see two solutions to the dependency trouble of the binary builds for linux:
1. Indeed update the build environment, to Debian testing. It makes sense to have a build system that more closely resembles the target build environment. Most people who have a Linux Desktop have something along the line (in terms of age) of Debian Testing or newer since Debian stable is usually used for server systems where the important thing is reliability, not so much for Desktop systems (where one would play games). If the autobuild build environment were more alike to what most desktop users have, there'd be less of these issues in the future.
2. Use more/only statically linked libraries instead of dynamically linked ones for the binary build we provide on our website. So, the Linux build we provide on our website would be compatible with most/all Linux platforms out of the box without the need of any additional dependencies. This'd be great, but goes against the ambition of at least the Debian philosophy to dynamically link as much as possible. So, whether to prefer static or dynamic linking should be an option in Cmake so that we can provide a monolitihic build that runs everywhere(TM) and at the same time packagers for distributions can be happy about dynamically linked binaries for their packages.
> So, whether to prefer static or dynamic linking should be an option in Cmake
Haha, good luck getting CMake to cooperate with that.
I don't know much about CMake, so it is a missing feature there?
It works in certain select Find*.cmake modules (most notably FindBoost), but everything that just calls find_library is basically out of luck. Maybe we can replace CMake's find_library with our own.
Added 1030 as well, this is a nasty and annoying one as well. Don't have time to look into this until the weekend , though.
![[de]](/mwf/flags/de.png "Germany")
Duplicate object creation in Initialize is a very old problem (and nothing new of Objects.c). There's even a warning message if you create objects in Initialize and then start the scenario.I always try to make a delayed initialization triggered by the first player join. That means I can freely edit the scenario in unpaused mode without worrying about startup scripts.
I wonder if it would make sense to even add another Initialize()-like function to the engine that is triggered by the first player join. It would save some boilerplate code from every scenario.
I know the feeling, and that is why I always Initialize my own objects and never use "save scenario" for anything else than saving the map.
But a delayed Initialize() seems also a good thing yes.
But a delayed Initialize() seems also a good thing yes.
![[eu]](/mwf/flags/eu.png "Europe")
Instead of adding a new func I'd change the Initialize function to be what you said for scenarios. To have the old behaviour, one can have Construction or so. (Objects.c and/or? Construction callback being the construction of a scenario, on (just before) first player join, the initialization.
If something like that is made a new engine callback, I'd think that a call after all starting players have been initialized would be more useful.
Both would have its uses and its drawbacks:Before player initialization: can safely place helper objects (spawners, rules, goals) that will care for player joins etc. BUT can not do stuff like looping over all players and starting the rule selection for the first player or something like that.
After player initialization: can do stuff do initialize the players (I usually used Script0 for that in the past) BUT spawning objects here might have weird effects (f.e. you possibly couldn't spawn certain helper objects that you need to use during player initialization)
so, *shrug*
func OnBeforePlayerInitialization()
func OnAfterPlayerInitialization()
I would prefer before the first player initialization. If Initialize happens after player init, people are tempted to push player initialization into Initialize and then their scenario won't handle runtime joins properly.Iiirc, Initialize happened after player joins in Clonk 4 and when the order changed, lots of poorly written scenarios broke.
Um, typical. Well, for the next bugfix update, I won't be available. You gotta take over.I recently updated the release checklist: https://git.openclonk.org/openclonk-release-scripts.git/blob/master:/web/oc-release.cgi#l176
Three bugs added:#1036: Tutorial 3: Occasional block from firestone not exploding
#1035: Boomshire: Door SolidMasks gone
#1034: Dark Castle: Instant win
Severity: Extreme.
Good find!They should be easy enough to fix for anyone who has time to do so.
I'd like to release the bugfix release today. Isilkor finished the important part with the dependency issues already, whats left of issues that were marked as must-be-part-of-bugfixrelease should be quick to fix.This goes to Sven2, Clonkonaut and Maikel of which I expect will be the ones who fix the remaining marked bugs: Will you be able to solve the last bugs today? Cause I think if you don't find time to do it this weekend, will you find time at all in the next weeks to do it? In bit more than a week I will be gone traveling for more than two months, so I won't be able to push a new release then.
Mortimer: You still need to merge the changes you made on master that should be in the stable branch.
I won't be able to fix what is assigned to me, but it is also not that relevant for this bugfix release.
What about this one? This is important to have fixed in my opinion.
What about this one? This is important to have fixed in my opinion.
Fixed another one as well: last one on the Roadmap standing is #1034
I don't want to spend time on that one, since I have no idea how that scenario works. For me it is then fine to do the bugfix release with the current state of the stable=5.4 branch.
I don't want to spend time on that one, since I have no idea how that scenario works. For me it is then fine to do the bugfix release with the current state of the stable=5.4 branch.
Added a note to #1034 (Dark Castle):Scripts hits a null pointer at line 19:
Object(332)->SetNoPowerNeed(true);
After that about 10 lines of "Object(x)->" follow of which I assume will also be null pointers upon fixing line 19. This one's easy to fix in case you know which object is referred to.
I guess this came with the change from Objects.txt to Objects.c and scrambling object creation.Isn't really nice to fix without any idea of the whole scenario, I'll try my best. Testing should be done by someone who has played the scenario before and knows who to do it.
As much as I can do: // Elevators
// Top
Object(190)->SetNoPowerNeed(true);
Object(189)->CreateShaft(470);
// Left
Object(197)->CreateShaft(100);
// Shrooms
Object(15)->AddPoisonEffect(0,0); // floor left
Object(19)->AddPoisonEffect(0,0); // ceiling left
Object(23)->AddPoisonEffect(-20,0); // floor right
Object(27)->AddPoisonEffect(10,-10); // ceiling right
// Message when first player enters shroom area
ScheduleCall(nil, Scenario.ShroomCaveCheck, 21, 0xffffff);
// Scorching village
Object(103)->AddScorch(-20,-10, -45, 50, 1500);
Object(104)->AddScorch(-15,42, 90, 50, 1200);
Object(105)->AddScorch(-12,18, 130, 80, 1300);What I don't know is:
if (goal) goal->SetVictim(Object(3816));
and
DialogueCastle->MessageBoxAll("$MsgIntro1$", Object(2648), true);
Schedule(nil, "DialogueCastle->MessageBoxAll(\"$MsgIntro1$\", Object(2648))", 250, 1);
As I don't know who's the victim and who plays the starting intro. Also, player spawn point seems to be off.
Also, isn't this the kind of stuff that could be well better handled with Objects.c?
Dark Castle fixed. I'll have stuff to do now; will be back later in the evening.
They make this sound as a "warning", when it hit something at almost the speed it would take it to explode. (Explodes on Hit2, casts some sparks and makes the fuse sound on Hit)
We need a slighlty different sound for that later, since it looks like dynamite now, it should also be shorter I guess. More like cracking.
Yeah, would also be fine. But it only sounds like dynamite because you got used to it ;-)
quick freesound.org search:http://freesound.org/people/RutgerMuller/sounds/50907/
http://freesound.org/people/reinsamba/sounds/65420/
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
