Jump to content

mickkay

Members
  • Posts

    7
  • Joined

  • Last visited

mickkay's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. PS: It looks like MC 1.12.2 has no problem with missing entity ids that are "server-only". I already tested this in code. I just disabled the relevant part in FMLHandshakeClientState (line 156 ff) that issued the error: Multimap<ResourceLocation, ResourceLocation> locallyMissing = GameData.injectSnapshot(snap, false, false); // if (!locallyMissing.isEmpty()) // { // cons.accept(ERROR); // NetworkDispatcher dispatcher = ctx.channel().attr(NetworkDispatcher.FML_DISPATCHER).get(); // dispatcher.rejectHandshake("Fatally missing registry entries"); // FMLLog.log.fatal("Failed to connect to server: there are {} missing registry items", locallyMissing.size()); // locallyMissing.asMap().forEach((key, value) -> FMLLog.log.debug("Missing {} Entries: {}", key, value)); // return; //} cons.accept(PENDINGCOMPLETE); ctx.writeAndFlush(new FMLHandshakeMessage.HandshakeAck(ordinal())).addListener(ChannelFutureListener.FIRE_EXCEPTION_ON_FAILURE); Then I started the client. I could connect to the modded server without problems and also play with it long enough to see that MC had no problems with any missing entity ids. Of course the code above is not the patch that is needed. But it shows that it would be very easy to support server-only entities in Forge. The only thing we would have to do is to prevent the transmission of the server-only entity ids to the client during the handshake. Then the handshake would succeed without error and the client could connect to the server. To implement this, I would suggest to add an (optional) boolean flag, or an enum property if you prefer, to the EntityEntryBuilder, that marks the entity as server-only. This flag should be used by the server to filter the entity ids that are sent to the client during the handshake. What you you think? Are there any chances that the Forge team would like to support "server-only entities"? Cheers MickKay
  2. Anyway, I can give you an idea about why this works in MC 1.11.2 but not in MC 1.12.2. I debugged the Forge client code for both versions and found the difference. In Forge for MC 1.11.2 only missing blocks and items were interpreted as fatal error, while in Forge for MC 1.12.2 all registries are checked for missing entries, which includes entities. Here is the relevant code: In Forge for 1.11.2 the PresistentRegistryManager has the following statements at line 319: // If we have missed data, fire the missing mapping event List<String> missedMappings = Loader.instance().fireMissingMappingEvent(missing.get(BLOCKS), missing.get(ITEMS), isLocalWorld, remaps.get(BLOCKS), remaps.get(ITEMS)); // If there's still missed mappings, we return, because that's an error if (!missedMappings.isEmpty()) { return missedMappings; } Since only "ITEMS" and "BLOCKS" are searched, the "missedMappings" does not contain my spell entity and instead stays empty. So no error is issued. The respective code segment in Forge for 1.12.2 is in GameData, beginning at line 570: missing.entrySet().stream().filter(e -> e.getValue().size() > 0).forEach(m -> { ResourceLocation name = m.getKey(); ForgeRegistry<?> reg = STAGING.getRegistry(name); RegistryEvent.MissingMappings<?> event = reg.getMissingEvent(name, m.getValue()); MinecraftForge.EVENT_BUS.post(event); List<MissingMappings.Mapping<?>> lst = event.getAllMappings().stream().filter(e -> e.getAction() == MissingMappings.Action.DEFAULT).sorted((a, b) -> a.toString().compareTo(b.toString())).collect(Collectors.toList()); if (!lst.isEmpty()) { FMLLog.log.error("Unidentified mapping from registry {}", name); lst.forEach(map -> FMLLog.log.error(" {}: {}", map.key, map.id)); } event.getAllMappings().stream().filter(e -> e.getAction() == MissingMappings.Action.FAIL).forEach(fail -> failed.put(name, fail.key)); final Class<? extends IForgeRegistryEntry> clazz = RegistryManager.ACTIVE.getSuperType(name); processMissing(clazz, name, STAGING, event, m.getValue(), remaps.get(name), defaulted.get(name), failed.get(name), !isLocalWorld); }); if (!defaulted.isEmpty() && !isLocalWorld) return defaulted; Here is every ForgeRegistry searched for missing entries, including the registry for entities. This is why the "defaulted" map is not empty and returned to the caller, which in turn issues the error message "Fatally missing registry entries".
  3. Oh, I see. This would mean to rewrite the mod's core. I guess we stay at MC 1.11.2 for now. Too bad. Just a desperate idea - provided that we could add this in far less time to Forge than to rewrite our SpellEntity into something like a tick handler that can simulate an entity, would the Forge team be interested into code contributions that add support for the "server-only entities" feature for MC 1.12.2? Cheers MickKay
  4. Alright, I'll try to elaborate. Out server-only entities are invisible spells. A spell can be casted by the player by issuing the mod-specific "/lua" command, followed by a short Lua program. This works from the chat line and from within command blocks. When a spell is casted, a SpellEntity is created exactly at the position the player is looking at (or at the command block's location). Then the spell is performing whatever task has been assigned to it, for example, running some while-loop and replacing some blocks. This is done inside the entity's update method. Since the spell entity is completely invisible, nothing needs to be transferred to the client. All actions are executed on the server only. However, if the spell changes some blocks or issues a Minecraft command, the effects of this action is synchronized to the player. For example, when the player wants to see the spell, he can add some statement to the spell's program that issues a "/particle" command. In this case the command is executed on the server, particles are created at the spell's position, and transferred from the server to the client, which is no problem, since this is vanilla Minecraft behavior. Same is true for block updates. Here is a video that shows a Lua spell performing Conways Game of Life: I am using this approach since the first prototype that has been created in early 2017 with Minecraft 1.10, and later 1.11, and it works like a charm. If you are curious, you can play with the latest alpha version which is available at Curse: https://minecraft.curseforge.com/projects/wizards-of-lua/files, and some documentation can be found at http://www.wizards-of-lua.net I like the idea that a spell is actually an entity that lives inside the world like all other entities. It belongs to a specific dimension, it has a location, it can move around like Logo turtle, it can modify the block at its location, it can be a command sender, and the like. Additionally it can listen for any Forge event and react to it. For example, it can wait for a specific action of the player and then cast another spell that does something special in reaction to this event. Since spells are real entities they run completely independent and "parallel". Long programs do not "eat up" big amounts of time during the game tick, since they use an internal scheduler that suspends the spell's program after a specific amount of "lua ticks", and resumes it not before the next game tick. When a spell has finished its task, it terminates, which means it actually calls "setDead(true)" on itself. We were planning to release the first "non-alpha" version for Minecraft 1.12.2 in the next weeks, since upgrading to 1.12 is the last ticket we have in our backlog. But it turned out that our beta testers could only log into the server if they use a vanilla client. Anybody who uses a Forge modded client, for example, in order to use some client-side Minimap mod, could not log in. As a work around they installed the Wizards of Lua mod also on their client. That works, but is, of course, completely senseless, because nothing is done client-side. Again, if you have any idea how this could be solved, I really appreciate it!!! Cheers MickKay
  5. Hello Forge Team! I have recently upgraded my self-made mod from MC 1.11.2 to 1.12.2. Since then all forge clients that try to connect to the modded server get this error message "Fatally missing registry entries". Here is the relevant part from the client's fml-junk-earlystartup.log: [08:06:26] [Netty Client IO #13/TRACE] [FML]: Registry: 103 minecraft:llama net.minecraftforge.fml.common.registry.EntityEntry@280d5a82 [08:06:26] [Netty Client IO #13/TRACE] [FML]: Registry: 104 minecraft:llama_spit net.minecraftforge.fml.common.registry.EntityEntry@1a34a51e [08:06:26] [Netty Client IO #13/TRACE] [FML]: Registry: 105 minecraft:parrot net.minecraftforge.fml.common.registry.EntityEntry@3bf5911d [08:06:26] [Netty Client IO #13/TRACE] [FML]: Registry: 120 minecraft:villager net.minecraftforge.fml.common.registry.EntityEntry@17136390 [08:06:26] [Netty Client IO #13/TRACE] [FML]: Registry: 200 minecraft:ender_crystal net.minecraftforge.fml.common.registry.EntityEntry@273293c8 [08:06:26] [Netty Client IO #13/INFO] [FML]: Registry EntityEntry: Found a missing id from the world wol:spell [08:06:27] [Netty Client IO #13/DEBUG] [FML]: There are 1 mappings missing - attempting a mod remap [08:06:27] [Netty Client IO #13/ERROR] [FML]: Unidentified mapping from registry minecraft:entities [08:06:27] [Netty Client IO #13/ERROR] [FML]: wol:spell: 0 [08:06:27] [Netty Client IO #13/DEBUG] [FML]: Processing missing event for minecraft:entities: [08:06:27] [Netty Client IO #13/DEBUG] [FML]: Next: ERROR [08:06:27] [Netty Client IO #13/ERROR] [FML]: Network Disconnect: Fatally missing registry entries [08:06:27] [Netty Client IO #13/FATAL] [FML]: Failed to connect to server: there are 1 missing registry items [08:06:27] [Netty Client IO #13/DEBUG] [FML]: Missing minecraft:entities Entries: [wol:spell] [08:06:27] [Netty Client IO #13/DEBUG] [FML]: FMLHandshakeClientState: $HandshakeAck:{2}->FMLHandshakeClientState$8:ERROR However, plain vanilla clients have no problems to connect. I know this has to do with entity IDs missing on the client side. The entity IDs are missing because the clients haven't installed my mod at all. However, this "should" be fine, since my mod is supposed to be a "server-side only" mod. My question is now: can I somehow get rid of this error message, so that forge clients can log into the server, like the vanilla clients already can? Is there, for example, a way to skip this ID test on the client, or some setting, that prevents the sending of the mod-specific entity IDs from the server to client? For example, I found out that I just could skip the entity registration (done with the EntityEntryBuilder), which makes the my entity class unknown to the server and client, but I am not sure if that is the correct approach to this. It works, but I guess this has bad side effects, hasn't it? My setup is the following: 1) I have Forge 1.12.2-14.23.2.2651 on the server 2) I have Wizards of Lua Mod (that's my mod, version is some alpha for MC 1.12.2, not yet released because of this issue) on the server 3) The client has Forge 1.12.2-14.23.1.2555 installed 4) No other mod are installed on the client. Please note that the respective entity I have on the server does not need to by synced to the client. It is really server-only. And well, it worked in MC 1.11.2, just not in MC 1.12.2. I really would like to support not only vanilla clients to connect to my server mod but also forge clients. If you know how to do it, I appreciate any hit. Thank you very much for any feedback. Cheers MickKay
  6. Hello Forge Team! I have recently upgraded my self-made mod from MC 1.11.2 to 1.12.2. Since then all forge clients that try to connect to the modded server get this error message "Fatally missing registry entries". However, plain vanilla clients have no problems to connect. I know this has to do with entity IDs missing on the client side. The reason is, that the clients haven't installed by mod at all, which should be find, since it is supposed to be a "server-side only" mod. My question is now: can I somehow get rid of this error message, so that forge clients can log into the server, like the vanilla clients already can? Is there, for example, a way to skip this test on the client, or some setting, that prevents the sending of the mod-specific entity IDs from the server to client? My setup is the following: 1) I have Forge 1.12.2-14.23.2.2651 on the server 2) I have Wizards of Lua Mod (that's my mod, version is some alpha for MC 1.12.2, not yet released because of this issue) on the server 3) The client has Forge 1.12.2-14.23.1.2555 installed 4) No other mod are installed on the client. Please note that the respective entity I have on the server does not need to by synced to the client. It is really server-only. And well, it worked in MC 1.11.2, just not in MC 1.12.2. Thank you very much for any feedback. Cheers MickKay EDIT: Don't mind, you can ignore this post. I just found the modder support forum. Please note that the link to the Modder Support Forum at page: is broken.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.