Simple Parts Pack for Flan's Mod

Simple Parts Pack for Flan's Mod

903k Downloads

Mod is cancelled forever?

mgdgfbhevdyeh opened this issue · 81 comments

commented

uc 20160821181345

commented

is cancelled forever?

commented

We are working on a port to the newest version of Minecraft. There is some progress but it has slowed down recently. The mod might be dead, but open source license will always give it a chance to reborn like phoenix from the ashes!

commented

Possibly

commented

So,flans mod is dead?

commented

You can contribute to this fork:
https://github.com/gitgud-software/FlansMod

commented

if possible,the next update is 1.10.2?
(my english is no good)

commented

The mod is not cancelled.

I have spent the last 6-7 months working on new features for it. The title of that video was a joke that should have become apparent upon watching the video.

commented

Once said features are implemented I will think about porting to the newer version. If you've already made some headway with that I would be glad to hear about it.

commented

I and gitgud spent quite a lot of time updating the mod to new Minecraft. Only rendering is left and it seems impossible to get it done. Also I don't know much about new rendering API. I'm stuck.

commented

Ouch, I had a go at updating to 1.9 a while back and got stuck there myself. Can't find any useful information about said API but I haven't exactly tried that hard. I'd rather focus on getting everything working on the current version for now, then port it in one go.

commented

I guess we're expecting our fork to be merged to master?

commented

Could be tricky. You won't have access to most of the stuff I've been doing and that might complicate things..

commented

You mean push access or git conflicts?

commented

Conflicts in the code itself as you'll have been updating an outdated version.

commented

I don't mind not having access to the main repository.

commented

Well for GitHub perms I can't do anything. I don't have access either.

commented

I don't care. What's the problem?

commented

The problem is we could end up with multiple different forks all doing different things. Ideally the 1.8 version would be completely finished before it is ported. But if you've already make headway we could end up just bolting those changes onto your version. Which may not even be a problem, just could get a little messy.

commented

I don't have much experience with working on multiple forks, but I'm aware it's gonna get messy as hell. I've put hours of work to that update and I'd appreciate it merged. I would help obviously.

commented

If you've already got it working there's no need to do it twice.

I'm already maintaining a 1.7.10 version of the mod as it is so I'm having to port all this between versions already. Doing one more couldn't hurt right?

commented

We'll sort it out. wtorek, 23 sierpnia 2016, 02:49PM +02:00 od PrototypeTheta [email protected] :

If you've already got it working there's no need to do it twice.
I'm already maintaining a 1.7.10 version of the mod as it is so I'm having to port all this between versions already. Doing one more couldn't hurt right?

You are receiving this because you commented.
Reply to this email directly, view it on GitHub , or mute the thread .

commented

Alright, let me know when you're ready to start accepting new features. If you need to get a hold of me I am normally active here:

http://minecraft-smp.de/index.php

commented

Ok, we can discuss this outside github.
Send me an email or an im on XMPP wtorek, 23 sierpnia 2016, 02:54PM +02:00 od PrototypeTheta [email protected] :

Alright, let me know when you're ready to start accepting new features. If you need to get a hold of me I am normally active here:
http://minecraft-smp.de/index.php

You are receiving this because you commented.
Reply to this email directly, view it on GitHub , or mute the thread .

commented

Hi. I am also currently working on updating the mod. I sent you an email with more details.

commented

Heya, a bit late to the conversation but I'll be frank and say PrototypeTheta may have a point, we may have things out of order trying to jump directly to 1.10.2 instead of incremental updates. I'm going to try and first see if we can make the jump from 1.8 to 1.8.9, and see how things go from there.

I'm going to leave the stuff that was done towards 1.10.2 in the repository, but just work towards a port independent of it.

commented

@TypicalDarkness said he managed to run the mod, but he never replied to my email.

commented

Uhm.. so well.. a while ago I updated an private copy of the mod to 1.10.2

I know how to update most things to 1.10.2 and it seems to work fine.
Except gun rendering (some classes are missing), and a few smaller bugs.
(I sincerly don't care about guns currently anyways, I just like vehicles)
*also vehicle guns do work.

So if there would be some official 1.10+ branch I'll help probably (after I figure out how github works ... >.>)

Edit: No, I can't send the mod to test it cause it will crash cause it's bound to other of my mods.
(wrote cause ppl might ask)

commented

@gitgud-software is that 'fork' working? (launching). Also the gun render quite much died in 1.8.9 as far I remember.

If it's about dependency... a part of the code is put into one of my mods, another into a (private) server mod (packethandler, cause the default one didn't work for some weird reason on my server, while it did in eclipse).
I could probably put it into an seperate jar..

Edit: currently re-updating.
Edit2: I'll put the utils into a seperate jar.

commented

@Fexcraft We've been working on the fork at https://github.com/gitgud-software/FlansMod on the 1.10.2 thing if you want to check it out. I don't know if you're going to get an "official" branch unless we manage a complete port; right now @PrototypeTheta seems to want to work out the problems in the 1.8.9 version.

I don't honestly mind a dependency if it means the mod works though, but you may want to spin the relevant code into an API/library like some of the other projects do. At least post the repository or merge some of the stuff into ours? What can be done would be greatly appreciated.

commented

Our work fork doesn't work.

commented

@MarcinWieczorek work doesn't work?

commented

fork* that was a missclick ;P

commented

Mine did till I wrecked it, and reupdating now again..
Edit: non wrecked version http://prntscr.com/cgdoau
Edit2: done re-updating common part
Edit3: done re-updating client (render issues skipped/commented out)
no clue how to do the github stuff tho.., on bug-hunt till then..
Edit4: I broke something... yay
Edit5: It seems to work, but gotta fix up the packethandler like last time -.-

I hope I didn't messup stuffs, I made dis. https://github.com/Fexcraft/FlansMod

commented

@Fexcraft Hey, make sure to open up Issues so we can track what is and isn't working from your repo. It'd also be solid if you wrapped up some of the fexcraft imports into a library mod if possible. Right now the setup doesn't pull in the Fexcraft dependency/mappings either, so please update the build process when you get the chance.

commented

@gitgud-software Enabled the Issues thing.
About the fexcraft imports, I prepared a .jar file, I forgot though how to do the import/dependency stuff in eclipse.
(I'll put it into the /run/mods folder nvm, I did already but github isn't probably configured to upload that too.. Edit: found out how to.)
Or alternatively I could add all the classes to the src (after I add a signature and comments), if that would be better?

Edit: wrecked something in my git client.. Fixed.

Edit: About the library, read this https://github.com/Fexcraft/FlansMod/issues/2.
edit ftw

commented

Hey, I'm still working on the project. I was gone for over a month because I didn't have a lot of time.

I removed big parts of the mod and started to from almost zero and then re-added the things I needed bit-by-bit.
The rendering system I made uses .obj files and so far I have converted the gun models and implemented the gun-animations.
I also switched to .json instead of .txt for typeFiles. The txt-based system still works more or less but I think we should use json.

https://github.com/TypicalDarkness/FlansMod

commented

Ye, I thought also that json would simplify some stuff...

commented

I wrote some code to convert txt to json and so far I have converted bullets, guns and parts.

commented

@TypicalDarkness When I downloaded the code from your fork to try it,
the "FlansUtils" class seems to be missing? (eclipse does complain about)

commented

Sorry, I seem to have unticked the file when I comitted in Github Desktop for some reason. Should work now.

commented

Your rendering system uses only obj?

commented

Yes. I could add support other formats though

commented

The mod lives from the community, and all packages are using java models. not one is using obj till now.

commented

I wrote a code to convert ModelRenderTurbo to .obj. I already converted most/all of the gun files

commented

then you have to publish the converter too. Most modelers have their own files and don't share.

commented

Yep, I can do that. I just have to clear up the code a bit

commented

I might just know someone who is up to the job of updating TMT. Can't say when it'll happen but I do feel preserving it should be a priority, as well as the current system to read configs from .txt files. As Manus pointed out, the mod survives on the community, so it is best to keep things as straightforward for them as possible. When we change things people tend to throw poo at me.

But any ways, I'm sure you know that I have been working on enhancing the current versions. Most
of this new content has been made available here (even if I haven't got control of this either)

https://github.com/Demitto/Flan-s-Mod-Plus/tree/master/src/main

Now most of the changes should be straightforward to port provided the mods general structure remains the same. Though do bear in mind that some of this will not be making its way into any official versions (map writer based content will be left out, but stuff like handling improvements, new effects and the new vehicles collision systems will be ported).

I should be returning to the UK in a few weeks time so I'll be around more to help with this.

commented

The rendering is deprecated and Forge will remove support for it even more in the future. Storing models as actual files instead of java classes has many advantages, including that resource packs can change them.

We can have support for txt and json at the same time or we provide easy to use tools to convert the packs. If the content pack creators don't want to do it, I can do it for them.

commented

I believe Flan hit a similar problem converting to 1.8. I didn't really understand back them but I remember him working on a system so that content creators would not have to deal with .jsons to get their models working.

commented

Do you mean the vanilla json models for items that were introduced in 1.8? Yes it's really annoying that we now need to add extra files even when just adding a simple item. I don't think there is a lot we can do about it, mojang seems to remove more and more things from the game to external resources (maybe to make the game more modular or easier to modify)
But I was more talking about the json support that I added for typefiles.

commented

Ah, I was under the impression that it would be difficult to preserve reading everything from txt. But if it's just something additional you've added then there literally isn't a problem.

As for the rendering stuff. Well, I do feel like cocking around with OpenGL.

commented

Ok, but I still think using external files and the rendering forge suggests us to use would make the mod more future-proof and maintainable.

commented

Fair point. It's enough of a white elephant already.

commented

Well Toolbox is the closest we have to that in regards to it's abilities to generate the configs to go along with the models. Though I think with some proper up-to-date documentation messing around with the different files would hardly be a chore. But admittedly my PoV is perhaps skewed, having started on the old 1.2.5 system.

But hell, I must say I like the idea, it could potentially help with standardisation.

commented

Ah. Just noticed something. Do any of the vehicles work when converted to .obj? Because I know model parts like tank barrels rely on the structure of TurboModelThingy parts, which may throw a spanner in the works with regards to converting everything to .obj.

commented

Maybe this is slightly off-topic, but what I'm dreaming of is having something like a "FlansCreator" in the future, a program that allows people to easily manage their content-pack without having do deal with all the different files.

commented

In the meantime there is me not understanding why some people talk about TMT as if it would be irriparably broken..

http://prntscr.com/cky3sn that's about vehicles.
Turrent, Gun and wheels move just fine.

Only "broken" vehicle model found: https://github.com/Fexcraft/FlansMod/issues/4
(didn't check all yet though)

If it's about deprecated methods, http://prntscr.com/cky5s3
in theory it would be possible to get vehicles with current rendering till 1.11;

Nvm, this resulted to be easy fixable... now just gotta get rid of a white cube inside the vehicles.
http://prntscr.com/cky9sm http://prntscr.com/ckya5a

Or is there something I understood completly wrong... ? .-.

commented

Ah. I see. If it is just for guns then using .obj is no problem at all as the structuring is slightly different. It may potentially complicate my efforts to implement muzzle flash but it's nothing that can't be sorted out.

Sure, we'll have to lose that fancy effect where the vehicle model renders in your hand, but it's a feature I think we can live without.

commented

I think fixing the old rendering IS possible but we would have to use a lot of hacky stuff. This is what I just did using @Fexcraft 's repo:
http://i.imgur.com/F07TZrl.png

We have to change the vanilla jsons to something like this to prevent normal rendering and then render the gun using GL:

{ "parent": "builtin/generated", "textures": { "layer0": "flansmod:items/RPD" }, "display": { "thirdperson_righthand": { "scale": [ 0, 0, 0 ] }, "thirdperson_lefthand": { "scale": [ 0, 0, 0 ] }, "firstperson_lefthand": { "scale": [ 0, 0, 0 ] }, "firstperson_righthand": { "scale": [ 0, 0, 0 ] } } }

Maybe there is another way to prevent the vanilla rendering, but I think Forge removed or plans to remove all other possibilities (apart from first person rendering maybe). Another problem is that I haven't found out how we can render the ItemEntities (items on the ground) ourselves.
Edit: It's also possible to make a CustomModelLoader that "pretends" to load the model even if the .json model doesn't exist.

Note, that this is not the way forge wants us to do things and that we might run into some problems in the future but it would be relativeley easy to fix rendering for now and we wouldn't have to change anything in the contentpacks beside the vanilla .json files. (Also it would be easier to render vehicles in the players hand) We could even make the main mod save the .json files if they don't exist already so contentpack creators wouldn't have to convert anything.
I can still add support for .obj in the future so we would have both systems without losing compatibility with older versions.

Btw, I made a fix for the arm rotations on my repo which I could implement aswell.

commented

The vehicles seem to work fine. I was talking about item/gun rendering. Sadly Forge decided to remove IItemRenderer and other useful classes for some reason and kind of forced us to use their system...

commented

@Fexcraft The white cubes are gone if you move ClientProx::registerRenderers() to pre-init. (at least I haven't seen the cubes since I did that)

commented

Technically speaking TurboModelThingy can already load .obj models. It's just a really rubbish way to do it. If you can add a way to do it properly on top of what is already there then go for it, more options is always more better.

commented

@TypicalDarkness true, I forgot in the comment of the deprecated method was written it should go to preinit.

About about "hacky" and "not how forge wants it",
as I saw, and thinking about it currently...
The mod already had wrong name registry and other small things which aren't fml/forge norms as far I remember.
And hacky stuff isn't bad as long it it doesn't cause laggs/crashes/curruption and also doesn't cause incompabilities with other mods.
#ownOpinionWhichMightChange

Regarding Json:
If json files would be used to store all the data of vehicles/guns/whatever,
another advantage (which I didn't saw mentioned?) is that it would be easly possible to auto-complete missing data from a file and save it "fixed". (that's what I commonly do with my mod-files)

commented

Now that there is dual-wielding in minecraft, I think it would be better to remove the off-hand feature and simply allow certain guns to be dual-wielded. What do you think?

commented

I'm currently writing a custom ModelLoader that creates the models based on InfoType#iconPath so we would not need vanilla .json model-files at all.

commented

I agree with you on duel wielding. Now that there is a proper system we may as well use it.

commented

@TypicalDarkness
remove the off-hand feature and simply allow certain guns to be dual-wielded

commented

Hey Guys, You probably know me from before.
{I'm the guy who made a retarded python program that never really worked properly, and was never really released well....eh}

The progress seems to be good here,

Anyway, I am here to pledge my support in a 1.10.2 modelling program manager thingy do da, ofc written in....

Python

Anyway.... ehm, whoever is making the new systems, i would like to speak to nearer the time its slightly more completed, maybe[lel]

Anyway, progress report from the program is:

  • render code sorta done...
  • array's are mostly setup
  • functions: newBox()

To do:

Reading .java and .obj stuff (Heard someone already done .obj so maybe sooner than you think)
Exporting to .java and .obj (probably gonna take a while....)
make a gui
user controls
shapebox maker
other stuff i forgotten...

This will probably be uploaded to github, so if you wish to help, please do.

This is the support i pledge for 1.10 flans, as java aint my thing.

Thank You.

commented

Gimme dem sourcez of your program, I need to study it!

commented

Ehm, its rather.... Well in infancy much.

It doesnt do anything at the moment.

commented
commented

OK. I don't know anything about puthon and I've got no idea what to do with it. Maybe some other time.

commented

Its hilariously broken...

commented

python <3
I could work on the obj stuff.

commented

Imho only pistols should allowed to be shot with ond hand. I would not let players shoot heavier guns with one hand if it would be not possible in real life. Multiplayer servers with Flan's mod are pretty cool and people usually know a lot about the mod. Then I would suggest a big recoil in that case

commented

Yes, the problem is that it's probably not possible/easy to prevent the player from equipping a certain item, but I will try to find a way.
My question was about when it should be possible to use the offHand gun (pistol) and override the vanilla action (breaking blocks/attacking) by left-clicking.

commented

Another question about dual wielding:
When should it be possible to shoot the gun in the offHand?

  • Only when there is a gun in the mainHand aswell?
  • Only when there is a gun in the mainHand or the mainHand is empty (prevent vanilla clicking in that case)?
  • Always, no mather what is held in the other hand? (prevent vanilla clicking)
  • {Something else}
commented

@MarcinWieczorek But Minecraft is very unscientific

commented

Hello everyone, I have a small problem, When released 1.10.2?

commented

Unknown, theoretically you can just take the code from the repo/fork and compile it,
and get a "experimental - use on own responsability" version of the mod.

commented

Is the project dead or not? ;(