[1.8] Editing day lenght - can it be unsafe? (+question)

[Ernio]

Considering there won't be problems with other mods, can changing day lenght from 20min(24000) to 1 hour (72000) create any unwanted stuff? If someone looked into it - please share exp. Also - where (right now it's just idea, didn't look into it) would I edit that value to be sure it will get edited (no glitches).

 

EDIT: Question:

Where does vanilla have utility to calculate ticks into world time? (e.g 24100 would give String "1 day, 5 sec")

I am almost sure there is one somewhere, I just have no idea where is it even used (long time since I really player MC outside modding).

[Failender]

The Best way i could imagine would be to use a tick Handler, count a variable, if the variable is!=3 Set the worldtime to time-1.

If the variable is 3 reset it and Do nothing.

That way your mod should be compatible and the daytime gets three times longer.

This is just an idea so it might not work, I havent testesd it

[Ernio]

No no, that would split tick into 3, I need to extend their real number - I don't care about comatibility here actually.

 

Is there some static field of ticks in day? I know there was some method which in I saw '24000' - question is, is there a getter I can alter or there is no actual place to 100% override it and I have to make tricks like one you proposed? (I don't know/remember where to look for those values).

[coolAlias]

Ernio, I don't think the world time has any bearing at all on ticks. I.e. you can set world time to any value you want, even every tick set it to zero, and the world will keep ticking merrily along.

 

I guess that's part of the problem - ticks don't care about world time, so if I have a solar panel building power by the tick, it will give me 3x the power under your system, whereas if I have another block that is usable once per hour and that uses the current time to determine if an hour has passed, if you followed the previous poster's advice that block would still be usable once per hour, but each hour would be 3x as long.

[Abastro]

This is something that I can explain best.

 

@Failender

That is really bad idea, and that will break tons of mods..

 

@Ernio

There is nothing specifying the length of day and night;

Actually, The only meaning of the length of day(which is 24000 minecraft tick) is the period.

You can change not only the length of day, but also the motion of the sun!

 

Do you know the World#getCelestialAngle(..)? It gives the position angle of the sun for the specific World.

  (In radians I remember)

What it does is just calling WorldProvider#calculateCelestialAngle(..).

So if you can override the method, you can take full control on the sun's movement!

If you want to change the length of day on your custom You can just override the method!

If you want to change the length of day on overworld, then You should change the WorldProvider for dimension Id 0...;;

(That WorldProvider changing mod will be incompatible with mine. Very sad u.u)

 

EDIT: the unit was not Radians. The angle varies from 0.0 to 1.0

[Ernio]

This is exacly why I don't like vanilla.

 

Me: "Hey guys, how about making it possible to speed up/down game?"

Mojang: "Nah, we don't plan on doing it, we'll just HARDCODE shit out of MC!"

Me: "But guys? Maybe getter?"

Mojang: "HARD. CODE."

Me:

 

Problem is that this hardcode is actually in few places. I don't plan on Looking into Void (ASM) - it looks back!

Example:

                if (args[1].equals("day"))
                {
                    i = 1000;
                }
                else if (args[1].equals("night"))
                {
                    i = 13000;
                }

Because it would be so hard to make "day" be scallable value.

 

Ok, so how do I replace WorldProvider of surface?

EDIT

I am not dumb, just waiting for maybe better ideas than I see right now:

public final WorldProvider provider;

I would just reflect shit out of this thing! Safe?

[Abastro]

Oh that is bad, really bad, but you can override that using CommandEvent. So no worries.

(+You can make the only-night dimension, which /time day should not work.

    So I think the 'hard-coding' is reasonable enough)

 

Anyway: You can change it with DimensionManager with #un/#registerProviderType and #un/#registerDimension.

  You can simply unregister the vanilla WorldProvider, and register your own WorldProvider.

    (Which my Stellarium mod does, too)

 

Besides, why do you want to change the length of day?

Maybe I should just make some API with celestial movement management with vanilla dimensions..

[Ernio]

Currently I have about 10min of day and night. RPG games can't go that fast - they simply can't.

 

Imagine going on quest which should can be started only during sunset and you will get one night to complete it - can't do that in few min.

 

I simply need to have more real days. At least 3x lenght.

[coolAlias]

Currently I have about 10min of day and night. RPG games can't go that fast - they simply can't.

 

Imagine going on quest which should can be started only during sunset and you will get one night to complete it - can't do that in few min.

 

I simply need to have more real days. At least 3x lenght.

I feel that way every time I play (I mean playtest my mod) Minecraft - it seems like I barely do anything and it's f-ing night time again. For some reason I thought (hoped!) they had added game rules for the day/night cycle length, in which case it would be trivial for modders to do the same...

[Abastro]

.So there is no way without replacing the Overworld WorldProvider or Base Edits.

 

How to change the length of day, in detailed:

 

1. Replace the WorldProvider on FMLInitializationEvent:

        	DimensionManager.unregisterDimension(0);
        	DimensionManager.unregisterProviderType(0);
        	DimensionManager.registerProviderType(0, StellarWorldProvider.class, true);
        	DimensionManager.registerDimension(0, 0);

(StellarWorldProvider is my custom WorldProvider. You should implement your own WorldProvider)

 

2. Override the #calculateCelestialAngle on your own WorldProvider.

Vanilla implementation of the calculateCelestialAngle is like this:

    public float calculateCelestialAngle(long par1, float par3)
    {
    	        int j = (int)(p_76563_1_ % 24000L);
        float f1 = ((float)j + p_76563_3_) / 24000.0F - 0.25F;

        if (f1 < 0.0F)
        {
            ++f1;
        }

        if (f1 > 1.0F)
        {
            --f1;
        }

        float f2 = f1;
        f1 = 1.0F - (float)((Math.cos((double)f1 * Math.PI) + 1.0D) / 2.0D);
        f1 = f2 + (f1 - f2) / 3.0F;
        return f1;
    }

You can change the length of day by just changing the 24000L and 24000.0F to custom value.

If you want it to be 3 times longer, just use 72000L and 72000.0F

 

So, you changed the length of day!

 

* About the hardcoding issue, using CommandEvent would work.

[SanAndreaP]

Just do what Failender suggested. How will that break mods?

 

Here have some pseudocode:

int ticksUntilDaytimeIncr = 0

onServerTickPostEvent(event)
    if event.world Is Overworld then
        doTimeReset(event.world)
    end
end

onClientTickPostEvent(event)
    if event.world Is Overworld then
        doTimeReset(event.world)
    end
end

doTimeReset(world)
    if ticksUntilDaytimeIncr >= 3 then
        world.worldInfo.setWorldTime(world.worldInfo.getWorldTime - 1)
        ticksUntilDaytimeIncr++
    else
        ticksUntilDaytimeIncr = 0
    end
end

 

By the way: There are 2 fields actually responsible for world time, the

worldInfo.getWorldTime()

and

worldInfo.getTotalWorldTime()

The former is used to calculate the celestial angle, the second one to determine the "real age" of a world / used by the block tick scheduler. You shouldn't mess with the latter.

Also

gamerule doDaylightCycle

actually stops WorldTime from being increased if set to false, whereas TotalWorldTime is always incremented.

[Abastro]

Just do what Failender suggested. How will that break mods?

 

Here have some pseudocode:

int ticksUntilDaytimeIncr = 0

onServerTickPostEvent(event)
    if event.world Is Overworld then
        doTimeReset(event.world)
    end
end

onClientTickPostEvent(event)
    if event.world Is Overworld then
        doTimeReset(event.world)
    end
end

doTimeReset(world)
    if ticksUntilDaytimeIncr >= 3 then
        world.worldInfo.setWorldTime(world.worldInfo.getWorldTime - 1)
        ticksUntilDaytimeIncr++
    else
        ticksUntilDaytimeIncr = 0
    end
end

 

By the way: There are 2 fields actually responsible for world time, the

worldInfo.getWorldTime()

and

worldInfo.getTotalWorldTime()

The former is used to calculate the celestial angle, the second one to determine the "real age" of a world / used by the block tick scheduler. You shouldn't mess with the latter.

Also

gamerule doDaylightCycle

actually stops WorldTime from being increased if set to false, whereas TotalWorldTime is always incremented.

It would break some time checking mods, which should be updated in some duration.

Some could use worldTime for those purpose.

Also it is really bad approach for this issue..

So is there any problem with modifying the calculateCelestialAngle way?

[SanAndreaP]

It would break some time checking mods, which should be updated in some duration.

Some could use worldTime for those purpose.

Then they should use totalWorldTime, as the vanilla gamerule

doDaylightCycle

also messes with worldTime, as it's not incremented when

doDaylightCycle

is true.

 

Also it is really bad approach for this issue..

It's the only approach applicable w/o breaking compatibility with mods OR using ASM.

 

So is there any problem with modifying the calculateCelestialAngle way?

As you've stated yourself:

(That WorldProvider changing mod will be incompatible with mine. Very sad u.u)

Thus introducing incompatibilities.

 

Your approach is not wrong, and actually the right approach when we're talking about custom dimensions, I'm just saying that Failenders suggestion isn't wrong either.

[Abastro]

Then they should use totalWorldTime, as the vanilla gamerule

doDaylightCycle

also messes with worldTime, as it's not incremented when

doDaylightCycle

is true.

Yes. Anyway it is really not good. Also, when you want to change day length from 24000 to 49000, how would you do that? It easily gets complicated when the fraction is complex.

 

It's the only approach applicable w/o breaking compatibility with mods OR using ASM.

I described that there is another way, it is not that incompatible.

 

As you've stated yourself:

(That WorldProvider changing mod will be incompatible with mine. Very sad u.u)

Thus introducing incompatibilities.

 

Your approach is not wrong, and actually the right approach when we're talking about custom dimensions, I'm just saying that Failenders suggestion isn't wrong either.

The cause that my mod is incompatible with the way is that My mod changes the day length, too.

I had not seen any other cases that require replacing WorldProvider; So compatibility is not an issue here.

+ I think it is obvious that day length changing mods should be incompatible together.

[jabelar]

While it is good to consider mod compatibility of course, most compatibility issues are very specific and should just be handled when discovered.

 

The only case of true incompatibility would be if some other mod depends on the day cycle occurring in certain amount of real time. But in most cases, the logic would work out fine -- if something in one mod is supposed to happen after three days and the user also installs Ernio's mod to extend the days longer, then it probably should change the amount of time for the other mod. That would certainly change the gameplay, but changing the gameplay is the point of a mod.

 

The other cases of incompatibility would occur if the other mod improperly uses the world time for anything other than checking where in the daylight cycle the game is (otherwise they should use total world time). For example, I think if you actually decremented the world time that could cause some logic problems in other mods if they happen to check if the time has passed a certain value and you cause the time to hop back and forth over that value.

 

Anyway, my main point is that general compatibility is a worthy goal but most compatibility issues are specific. When they arise you can contact the mod authors to understand how to possibly modify your or their mod for better compatibility.

 

 

[Abastro]

While it is good to consider mod compatibility of course, most compatibility issues are very specific and should just be handled when discovered.

 

The only case of true incompatibility would be if some other mod depends on the day cycle occurring in certain amount of real time. But in most cases, the logic would work out fine -- if something in one mod is supposed to happen after three days and the user also installs Ernio's mod to extend the days longer, then it probably should change the amount of time for the other mod. That would certainly change the gameplay, but changing the gameplay is the point of a mod.

 

The other cases of incompatibility would occur if the other mod improperly uses the world time for anything other than checking where in the daylight cycle the game is (otherwise they should use total world time). For example, I think if you actually decremented the world time that could cause some logic problems in other mods if they happen to check if the time has passed a certain value and you cause the time to hop back and forth over that value.

 

Anyway, my main point is that general compatibility is a worthy goal but most compatibility issues are specific. When they arise you can contact the mod authors to understand how to possibly modify your or their mod for better compatibility.

 

Ill admit that. But aside from compatibility, there are many problems with the 'tick delay method'.

 

First, as I mentioned earlier, it easily gets complicated when the fraction is complex. Yes this issue is specific too, but should be considered in any case because fraction can be needed to get appropriate day length.

 

Second, sky animation would break with the method. As 20TPS is not enough to be shown naturally, minecraft uses partial ticks for the animation. so actually the celestial sphere is calculated on tick+partialTicks.

So when tick is delayed by a mod, the animation jerks from tick to tick-1.

Note that on vanilla doDaylightCycle, partialTicks is always set to 0 so there is no issue with that.

 

[Mortimer Kerman]

I put this here for future visits:

 

If you are under 1.16, you can put this in your WorldProvider:

 

@Override

public float calculateCelestialAngle (long worldTime, float partialTicks) {

return (world.getWorldTime () / (1.0F / 24.0F) - 6000.0F) / 24000.0F;

}

 

(the 1.0F value is the value to change to change the day lenght, normal day lenght is 24.0F)

[Luis_ST]

dude this thread is 6 years old and completely irrelevant

Edited November 26, 2021 by Luis_ST

[Mortimer Kerman]

13 hours ago, Luis_ST said:

dude this thread is 6 years old and completely irrelevant

yes I know, but at least if in the future someone is looking for a clear and concise answer he will easily have what he was looking for, instead of messages with dozens of lines