Depends what the features are. I think yes, for most things; but there's a catch. You will have to resort to "tricks" to make your mod have effect of dynamically loading and unloading.
I assume you're using Forge. If you're using another loader/API, no idea. If you're doing raw code hacking via MCP, no idea.
If you want your blocks and items to only be craft-able in your world for example, that's probably a little involved. You need to register your blocks/items and crafting recipe's on initialisation which comes much sooner than world gen / login, and you can't "unregister" an item or recipe as far as I know (too niche a feature for an API to care about). What you *might* be able to do however is to hook a world load event, get the world type from the event, and if it matches your mod, then manually walk the CraftingManager list and null-out/delete/invalidate the recipe's for your mod.
That's just an example for items and blocks though, and this has a few points of note:
1) I don't know if world load event is the right place, but it seems most suitable. At the very least, you could save your world type here to a public static class field in your mod so it's in-world code can reference the world type.
2) I don't know if world load event or *any* event gives access to the world type, you/someone would have to check this. There might even be a a field/method in the World object itself.
3) I don't know how "dynamic" the CraftingManager is. It wasn't designed to have things pulled-out of it mid game as far as I know. You may have to use Reflection and/or a coremod.
4) There are several "Recipe" types, at least five that I remember. Shaped, Shapeless, ShapedOre, ShapelessOre, and Fireworks. Vanilla items use all these classes but I'm not sure how Forge does it, it could use it's own class entirely... no idea.
5) The item will still technically exist in your mod, it just won't be craftable. If your blocks/items appear in loot tables or drop from mobs/passives, then that's a different thing altogether obviously.
That's basically the idea. Another example for something like mobs, it'd be a lot easier - you can just hook the relevant spawn/entityconstruct event and check if the current world is your mod's world type, and check if the mob is one of your mod's mobs; if both true then deny/cancel the spawn/entityconstruct event.
In summary, basic logic is this:
1) Register everything as normal, since any mod content has to be registered before a world can even generate
2) On world generation, save the world generator type to a public static class field, if required
3) Add a load of runtime checks. Basically everywhere your mod needs to do something, you'll need to conditionally run it only if the current world type equals your mod world type.
The obvious problem with all this though is that all your mod content has an additional overhead of checking the world type every time your mod needs to decide to do something or not. But I wouldn't worry about that too much, Java's JIT will cache the field lookup over time so it won't shouldn't bog down your system.
EDIT: Of course I could be completely wrong, and Forge provides "unregister" methods for a lot of things. Browse the method tree of the relevant classes that registered your stuff (GameRegistry?); they'd be in the same place if they existed.
Depends what the features are. I think yes, for most things; but there's a catch. You will have to resort to "tricks" to make your mod have effect of dynamically loading and unloading.
I assume you're using Forge. If you're using another loader/API, no idea. If you're doing raw code hacking via MCP, no idea.
If you want your blocks and items to only be craft-able in your world for example, that's probably a little involved. You need to register your blocks/items and crafting recipe's on initialisation which comes much sooner than world gen / login, and you can't "unregister" an item or recipe as far as I know (too niche a feature for an API to care about). What you *might* be able to do however is to hook a world load event, get the world type from the event, and if it matches your mod, then manually walk the CraftingManager list and null-out/delete/invalidate the recipe's for your mod.
That's just an example for items and blocks though, and this has a few points of note:
1) I don't know if world load event is the right place, but it seems most suitable. At the very least, you could save your world type here to a public static class field in your mod so it's in-world code can reference the world type.
2) I don't know if world load event or *any* event gives access to the world type, you/someone would have to check this. There might even be a a field/method in the World object itself.
3) I don't know how "dynamic" the CraftingManager is. It wasn't designed to have things pulled-out of it mid game as far as I know. You may have to use Reflection and/or a coremod.
4) There are several "Recipe" types, at least five that I remember. Shaped, Shapeless, ShapedOre, ShapelessOre, and Fireworks. Vanilla items use all these classes but I'm not sure how Forge does it, it could use it's own class entirely... no idea.
5) The item will still technically exist in your mod, it just won't be craftable. If your blocks/items appear in loot tables or drop from mobs/passives, then that's a different thing altogether obviously.
That's basically the idea. Another example for something like mobs, it'd be a lot easier - you can just hook the relevant spawn/entityconstruct event and check if the current world is your mod's world type, and check if the mob is one of your mod's mobs; if both true then deny/cancel the spawn/entityconstruct event.
In summary, basic logic is this:
1) Register everything as normal, since any mod content has to be registered before a world can even generate
2) On world generation, save the world generator type to a public static class field, if required
3) Add a load of runtime checks. Basically everywhere your mod needs to do something, you'll need to conditionally run it only if the current world type equals your mod world type.
The obvious problem with all this though is that all your mod content has an additional overhead of checking the world type every time your mod needs to decide to do something or not. But I wouldn't worry about that too much, Java's JIT will cache the field lookup over time so it won't shouldn't bog down your system.
EDIT: Of course I could be completely wrong, and Forge provides "unregister" methods for a lot of things. Browse the method tree of the relevant classes that registered your stuff (GameRegistry?); they'd be in the same place if they existed.
I'm so confused. How do i create a worldtype?
I'm just sitting here with nothing besides my main class.
Oh, I assumed you already wrote your World Generator. Or wrote something, not sitting there with nothing. Have you ever modded before? If not, I agree - you should give us more details of your goal. Forge can be very nifty. Don't worry, we're developers doing our own passion - we have no interest in stealing your ideas
I have no idea how to create a WorldType though. But even if I did, I don't make a habit of writing mods for other people sorry. Though I did do a quick google search, might be some promising results. You might have to dive into an opensource mod though.
EDIT: This forum is getting on my nerves. Search term is:
Minecraft Forge 1.7.10 "new WorldType"
I'd like to limit all of my mod features so they are only enabled when a player
created a world with a world type of 'Omega World'.
How would I go about doing so?
Thanks,
Ethan
I assume you're using Forge. If you're using another loader/API, no idea. If you're doing raw code hacking via MCP, no idea.
If you want your blocks and items to only be craft-able in your world for example, that's probably a little involved. You need to register your blocks/items and crafting recipe's on initialisation which comes much sooner than world gen / login, and you can't "unregister" an item or recipe as far as I know (too niche a feature for an API to care about). What you *might* be able to do however is to hook a world load event, get the world type from the event, and if it matches your mod, then manually walk the CraftingManager list and null-out/delete/invalidate the recipe's for your mod.
That's just an example for items and blocks though, and this has a few points of note:
1) I don't know if world load event is the right place, but it seems most suitable. At the very least, you could save your world type here to a public static class field in your mod so it's in-world code can reference the world type.
2) I don't know if world load event or *any* event gives access to the world type, you/someone would have to check this. There might even be a a field/method in the World object itself.
3) I don't know how "dynamic" the CraftingManager is. It wasn't designed to have things pulled-out of it mid game as far as I know. You may have to use Reflection and/or a coremod.
4) There are several "Recipe" types, at least five that I remember. Shaped, Shapeless, ShapedOre, ShapelessOre, and Fireworks. Vanilla items use all these classes but I'm not sure how Forge does it, it could use it's own class entirely... no idea.
5) The item will still technically exist in your mod, it just won't be craftable. If your blocks/items appear in loot tables or drop from mobs/passives, then that's a different thing altogether obviously.
That's basically the idea. Another example for something like mobs, it'd be a lot easier - you can just hook the relevant spawn/entityconstruct event and check if the current world is your mod's world type, and check if the mob is one of your mod's mobs; if both true then deny/cancel the spawn/entityconstruct event.
In summary, basic logic is this:
1) Register everything as normal, since any mod content has to be registered before a world can even generate
2) On world generation, save the world generator type to a public static class field, if required
3) Add a load of runtime checks. Basically everywhere your mod needs to do something, you'll need to conditionally run it only if the current world type equals your mod world type.
The obvious problem with all this though is that all your mod content has an additional overhead of checking the world type every time your mod needs to decide to do something or not. But I wouldn't worry about that too much, Java's JIT will cache the field lookup over time so it
won'tshouldn't bog down your system.EDIT: Of course I could be completely wrong, and Forge provides "unregister" methods for a lot of things. Browse the method tree of the relevant classes that registered your stuff (GameRegistry?); they'd be in the same place if they existed.
I did find this tutorial, but it is pretty old: http://www.minecraftforum.net/forums/archive/tutorials/930870-how-to-create-a-simple-worldtype-updated-to-1-4-7
[url=2482915-wip-arkcraft-survival-evolved-dinos-taming]
Not sure, that didn't work.
I also need help with botht he world type and putting my mod only in this 'type'.
I'm so confused. How do i create a worldtype?
I'm just sitting here with nothing besides my main class.
Maybe you should start off explaining what you are trying to accomplish, and then ask how it could be done.
There are lots of ways to generate items that don't involve having a new world type.
[url=2482915-wip-arkcraft-survival-evolved-dinos-taming]
I have no idea how to create a WorldType though. But even if I did, I don't make a habit of writing mods for other people sorry. Though I did do a quick google search, might be some promising results. You might have to dive into an opensource mod though.
EDIT: This forum is getting on my nerves. Search term is:
Minecraft Forge 1.7.10 "new WorldType"