MFMods

no, because most blocks don't have that. if you make a plant block, your model will likely consist of two parts: fixed color part (part that is not green: berries of flowers) and tinted part (texture will be gray but the game will make it match biome's shade of green). so, no.

isRemote condition is wrong.

yes. scalar product of two vectors is "length" (magnitude) of first one, multiplied by "length" (magnitude) of second one, multiplied by cosine of angle between them. in this case first two are equal to 1 and d1 is cosine of angle between players exact line of sight and the line between player and enderman. then you basically say "if angle is small enough (and has line of sight), return true".

that sounds a lot like looking at enderman to piss if off. look at vanilla code.

no.

try updating worldedit to a 1.18.2 version

not sure but it smells that radium mod wants older or newer forge. try only radium, then, when you get it to work, add other mods.

get blockstate from level and position verify that it's a kind of block you need (for example furnace) get block entity from level and position (do not make new, get from level) cast to its specific type and access fields directly (burntime = 0 for example)

there is no task called "setworkspace". there were some similarly named tasks in 1.12 era; no more. you unpacked the MDK for 1.18.2, i hope? after that, open your IDE. i use intellij idea; if you use eclipse, this part will be similar but a bit different. activate the "open project" command (from the welcome screen or the file menu); find the build.gradle file in the mod directory (where you unpacked the example mod from MDK zip) and open it as a project file. confirm that you are using java 17 (in case you have multiple versions installed. next, open "view" menu -> "tool windows" submenu -> "gradle" menu item. you will see tasks you can execute. find "genIntellijRuns" and double click it (at this point if you are using eclipse, just run another task). give it a moment and a few run configurations will appear. open configuration for runClient and confirm that it is set to use java 17. run it. that is it for a first setup. after you can run the example mod, edit build.gradle, src/main/resources/META-INF/mods.toml and the main class because you don't want the mod id to be "examplemod" and name to be "example mod". as you do that, for every edit make a line in the shell script that will do it for you next time automatically (you can use the sed command to edit text files from command terminal).

i suggest giving up and moving to 1.16/1.18.

assuming you want to use world saved data and that you want to attach it to overworld only (single save for all dimensions), it would be something like this: entity death event: if client then return; if not enty type we are trying to handle then return verify saved data initialized(parameter: world from event); savedData.summonId = empty; savedData.dirty = true; verify saved data initialized function if savedData not null then return; // not local savedData = ((ServerWorld)currentWorld).getServer().overworld().getDataStorage().computeIfAbsent(OurWorldSavedData::new, OurMod.MODID); do read the manual: https://forge.gemwire.uk/wiki/Saved_Data https://mcforge.readthedocs.io/en/1.18.x/datastorage/saveddata/

it's likely just a ton of copy and paste... if that mod is not good enough for you to remake it, it is surely and without doubt not good enough that even a single person would enjoy it..

they forced users of the Player class to access inventory through getter. so, you can write player.getInventory().whatsInSlot15() or player.getInventory().putIntoSomeSlot(something), but you can not write player.inventory = myInventoryThatIJustCreated and break everything. Actually, you can. just use access transformers.

please, stop. do not use access transformers. (and, i managed to say that in nice small lowercase letters) only use access transformers if you satisfy two conditions: 1) you understand why original developers made the field private and/or final. 2) you reasonably expect that changing that will not break anything. can you tell us that you understand why inventory field was made private and final?

i think you are. e.player.tickCount % 20 == tickRem will always be true. it's simple - every 50ms, tick events are fired for every dimension/world and for every entity and for every block entity (tile entity). there's more to it, but let's keep it simple. your handler executes within a single tick. tickCount is player's age in ticks. worlds have age too and in tick event you almost always check age modulo and do your thing every second or every five seconds. people mostly write age % 20 == 0 but i never put zero in those checks; 5 or 13 gives the same effect (frequency of 1 per sec) but doesn't clump a bunch of actions in the same tick. do not check for player being null in PlayerTickEvent that makes no sense. you need to check the event phase. usually you need to check whether player is not in client world but not for this purpose.

either mismatched versions of create and flywheel (see that you download them on the same day) or of flywheel and forge.

impressive, every row in that class is wrong. this thing Minecraft.getInstance().player - it returns a current player in a client window. it will crash the server. just never use it. never, ever. any damage happens on the server. client is only for showing things to humans. first of all, pick a better event. try BlockEvent.FarmlandTrampleEvent. next how to get a player? this is a multiplayer game, you can't say "game, give me the player". the player is in the event (if you are using FarmlandTrampleEvent or LivingUpdateEvent); you will always take player and world/level from event. next, before hurting a player or spawning a duck or whatever, you need to check whether the world (get it from the player) is client world (player.getLevel().isClientSide()). only if it is not, proceed. void damage is an odd choice and will give a weird message, but whatever. finally, consider a cooldown. these tick events fire 20x per second (even after you check client side and in some cases event phase). there is no need to do things 20x per secon, humans can not follow that. try adding if player.tickCount % 20 == 13. tick count is player's age (sort of); the check i wrote will see that you do damage once per second.

yeah. look - let's say you and me are playing minecraft together now. there are three game instances running: client game on my machine, client game (window with blocky world) on your machine and a server game (doesn't matter on which machine). and in all three game "programs", there is a sword in fire; you ask if (entity.isOnFire()) and entity.spawnAtLocation executes three times (although two out of three fire swords are ghosts and you can't pick them up). you need to ask ( not event.getWorld().isClientSide() and entity.isOnFire() ). also, if you are handling entity update, ask whether the entity is removed already. if it is, do nothing. i'm not sure if that's still an issue.

how can you have a mod with items and blocks and entities and structure features and then with all that you come to an idea to run the game and it doesn't work? did the game work at any point before? if yes, remove the last thing that you added and try again. if no, start from the beginning (mdk zip). console output tells nothing; it shouldn't have stopped there. look inside the log directory (under run directory specified in build.gradle) and look inside last modified files.

first of all a block takes up one block on the world. no discussion. even if it appears larger (sure, the model can overflow outside of "one block size boundary"), it is still one block. take for example crops (which is a reasonable scenario). you can make a model that is 16px across x and z axis (base) and 24 in height (y axis). you can. no argument there, even though blocks are 16x16x16 pixels in size. (*kinda-pixels) but you need to handle the block above the base, because it is a separate block as far as the game is concerned. in a crop example, you would need to override method neighborChanged in the block class, and if somebody places a cobblestone block above the base of your crop block, you destroy your block. shape functions that you override in the post above are something else. collision shape controls what happens when player tries to pass through your block or jump on top of it. in the case of my first example (crop), i would put an empty bounding box - meaning, allow player to pass through the block. visual shape is a set of boxes that control where you need to aim to interact with the block; you should set this shape to match what the player sees in-game. second example, you want to make a bush (like sweetberries), but wider than one block area. fine. make a model that goes from -8 to 16+8 on x and z axes. set shapes as you please. but the important part is - you need to set behavior manually. override neighborChanged because you can't have players putting something in block spaces that your block kind-of-occupies. override setPlacedBy and mayPlaceOn to react to player attempting to place your block down. one more thing (again me and my long unreadable posts) - things above have maximums, separate maximums. while a (visually) 2-block-big "block" is not a big problem, you will find that a 3-block-big block is a serious challenge for your hair. know when to give up and rethink the plan.

@tal124 what is it that you are trying to do? because it it's something that can be done in tick handler (update handler), you need none of that above. none.

setBlockAndUpdate

i strongly recommend against replacing blocks fully when all you want is to add functionality to it. yes it would work, but only one block can replace oak log. if two mods try that, user will need to pick which one to cut. here is what i would do - of the top of my head / not a thorough plan: 1) detect that a supported (replaceable with ash) block is burning (actually that it is adjacent to a fire) 1b) check in a list of burning block whether it's already there; it it is, skip 1c 1c) store it in a list as a structure {block state, position, ticks (zero) } 2) every X world ticks (20 maybe) loop through the list... 2a) check what's in the world at current position... 2a1) if it's air or fire, make an ash block; use stored blockstate to ensure proper orientation; delete from list. 2a2) if it's not air/fire, but also not stored block (i'd ignore blockstate), delete from list. 2b) increase tick count. if it's there for more than Y seconds, give up and delete from list (maybe check if there is still fire around?) far from a finished mod, but should work. minor note: you shouldn't destroy existing blocks because you don't want drops. just do a setBlock.

i think this "server receiving things" is confusing you. server knows the stuff you see in the world - blocks, sheep, zombies. the only time you send information to server is when you receive a mod-specific keypress or you open a gui window and interpret clicks into something the server would know about. even things like immersive engineering cables - player sets two endpoints, client will have to draw a "cable" all the time, but server should know about endpoints of each cable all the time - no need to send anything manually. and before you tackle this, look into more dynamic algorithms. do not calculate unchanged distances multiple times - store them somehow, and when another cable piece is added (i assume you are using blocky cables), see if any of the distances might be improved thanks to the new block; and if i destroy a block, recheck distances. do not do any non-trivial calculations when worlds "tick" and when block entities "tick".

do you know what the distance (in pixels) is between (mouseX, mouseY) and (somethingX, somethingY)?